1Comme le montrent, dans leur diversité, les articles du présent numéro, les systèmes d’information numériques (SIN) sont omniprésents, voire envahissent tous les types d’organisations. Du fait de leurs caractéristiques spécifiques, ils influencent en profondeur, et sur le long terme, le fonctionnement des organisations et la vie de leurs membres, selon des configurations diverses.
2Du pouvoir direct des plateformes de travail digital (Abel & Dieuaide, 2023), à l’utilisation du numérique pour accompagner des restructurations, les SIN apparaissent souvent comme des outils privilégiés de gouvernementalité (Brotcorne, 2023). Mais les interactions entre SIN et membres des organisations ne sauraient se limiter à une action à sens unique des premiers sur les seconds.
3On peut ainsi rencontrer des situations de reconfigurations des rôles des différents acteurs, des adaptations ou des formes d’appropriation (Benedetto-Meyer, 2023 ; Gras-Gentiletti, 2023 ; Moalic-Minnaert, 2023), la préservation d’une certaine autonomie (Tuffery, 2023), des résistances ou des détournements (Leclercq-Vandelannoitte, 2017 et 2023 ; Munduteguy, 2023), voire des conflits exacerbés entre logique métier et logique gestionnaire (Langeard et Cordier, 2023 ; Linhart, 2022). Mais il existe aussi, parfois, un réel dialogue entre les salariés et les prescripteurs et concepteurs de systèmes numériques (Plegat, 2023).
4L’objectif de la recherche présentée dans cette contribution est de susciter ou d’accompagner un tel dialogue, depuis le soutien à la prise de conscience des enjeux liés aux SIN, jusqu’à l’aide à la construction de voies de progrès. Il s’agit d’aider à identifier les points critiques dans le choix d’un SIN, sa gestion et ses usages par des individus ou des collectifs. Plusieurs formes peuvent être imaginées pour assurer ce soutien, celle qui a été choisie ici est une méthode permettant d’analyser et de mesurer le plus précisément possible l’influence qu’un SIN peut exercer sur le fonctionnement démocratique d’une organisation.
5Le travail de recherche exposé dans ce texte se situe au confluent de plusieurs disciplines (dont la pluridisciplinarité de l’équipe de recherche elle-même se veut un miroir1) et s’inscrit dans le cadre d’un projet soutenu par l’ANACT2, présenté en réponse à son appel « Développer le dialogue social technologique au travail3 ».
- 4 Neuman décrit ainsi l’approche critique : « [a] critical process of inquiry that goes beyond surfa (...)
6On peut qualifier cette recherche, selon la classification de Neuman (2013), de « critique4 », en ce sens qu’elle cherche aider les membres des organisations à acquérir les capacités de compréhension nécessaires pour améliorer leur vie au travail dans un contexte d’utilisation d’outils numériques.
- 5 Impact des Systèmes d’Information sur la Démocratie des ORganisations.
7La première section du texte expose brièvement notre point de vue sur les SIN comme dispositifs politiques, ainsi que la voie choisie pour tenter d’apporter une aide aux acteurs du dialogue autour du numérique. Cette voie est celle d’une ingénierie, concrétisée par la conception d’une méthode qui permet d’évaluer l’impact d’un SIN donné sur la démocratie organisationnelle. La méthode développée, ISIDOR5, est décrite dans la deuxième section. Les principaux présupposés d’ISIDOR y sont présentés (en particulier les points de vue développés par la méthode sur la démocratie d’une organisation et sur les SIN), puis le processus de mise en œuvre de la méthode est exposé, ainsi que les outils qu’elle propose. La troisième section est consacrée à une première expérimentation d’ISIDOR en situation réelle. Une dernière et brève section propose un premier bilan sur la méthode elle-même. Enfin, la conclusion s’attache à évaluer le travail restant à accomplir pour qu’ISIDOR remplisse les objectifs que nous lui avons assignés.
8Les travaux décrits ici se fondent sur une vision de ce que sont les systèmes d'information numériques des organisations, mais aussi sur l’appréhension de ce qu’est une méthode, qui est le vecteur par lequel nous avons choisi d’aider le dialogue social autour du numérique dans les organisations.
9Bien qu’ils soient le plus souvent présentés comme de simples outils, techniques, neutres, nous défendons l’idée que les SIN des organisations sont bien des systèmes sociotechniques, au sens d’Elayne Coakes (2002), pour qui la technologie doit être considérée non en tant que simple artefact technique, mais à la lumière de l'environnement social de l'organisation dans lequel elle opère.
10La perspective dans laquelle se situe notre recherche est que les SIN des organisations sont des dispositifs politiques, qui font exister les visions du monde de ceux qui les conçoivent (Akrich, 2010), et, le plus souvent, les renforcent puissamment par les rétroactions qu’ils opèrent sur le réel. Cette dimension politique est appréhendée ici sous l’angle de la démocratie organisationnelle : les SIN, en tant que systèmes normatifs, jouent, selon nous, un rôle déterminant dans le développement (ou l’empêchement) de la démocratie dans une organisation (Salles et al., 2020).
11Dans le contexte des organisations, les définitions courantes voient les méthodes comme des manières de faire, des démarches organisées pour parvenir à un résultat. Une méthode est ainsi en général réputée neutre, sa rationalité n’est pas interrogée. Les valeurs, voire les idéologies, qui sous-tendent ces méthodes ne sont pas explicitées. Or ces méthodes portent clairement des visions du monde : par exemple de ce qu’est la mission d’une entreprise ou d’un service public, de ce qu’est la qualité d’un produit ou d’un service, de ce qu’est la performance, ou encore de la nature de la technologie numérique.
12Pour notre part, nous considérons qu’une méthode se doit d’être transparente sur ses présupposés, les valeurs qu’elle porte, sa façon de procéder etc., afin que les résultats auxquels elle aboutit soient compréhensibles et susceptibles d’être débattus par tous les acteurs concernés.
13Un domaine de recherche à part entière, né il y a plus de trente ans, a pour objet même la conception de méthodes (pour les systèmes d'information). C’est le domaine de l’ingénierie de méthodes (Van Slooten & Brinkkemper 1993 ; Heym & Osterle, 1993). Nous nous sommes appuyés sur des travaux issus de ce domaine et avons, en particulier, adopté le référentiel de Seligmann et al. (1989) sur les éléments constitutifs d’une méthode.
14Seligmann et ses co-auteurs considèrent qu’une méthode doit obligatoirement comprendre quatre types d’éléments (Bour et Salles, 2021) :
- la manière de penser, qui présente explicitement les visions du monde et les grandes valeurs portée par la méthode, les grands objets qu’elle considère pertinents, ainsi que l’intentionnalité qui la sous-tend ;
- la manière de modéliser, qui traite des descriptions précises, structurées, des objets produits ou utilisés par la méthode ;
- la manière de travailler, qui correspond aux définitions courantes de ce qu’est une méthode, et décrit le déroulement de la méthode (contenu et enchaînement des étapes) ;
- enfin, la manière d’aider, qui concerne tous les outils d’aide à la mise en œuvre de la méthode : formations, documents types, cas complets, etc.
15La description de la méthode ISIDOR qui suit est organisée selon ces quatre types d’éléments.
16La manière de penser pose nos paradigmes, les grandes valeurs que nous défendons, ainsi que les apports théoriques utilisés pour la construction d’ISIDOR (SI2D, 2020). Notons que l’explicitation de ces points est cohérente avec la posture de recherche « critique », qui suppose la nécessité pour les chercheurs de préciser sur quels postulats ils se fondent (Stahl, 2008).
17La manière de penser expose l’intentionnalité de la méthode : il s’agit pour nous avant tout d’analyser et évaluer le plus précisément possible l’impact d’un SIN sur le niveau de démocratie d’une organisation, dans le but d’aider les acteurs à prendre conscience des enjeux liés à ces systèmes, de faciliter leur empowerment quant à ces outils, et de contribuer à rendre possible leur participation éclairée aux décisions liées aux SIN.
18La construction d’ISIDOR répond en outre à deux objectifs concernant la méthode elle-même. Le premier est que tous les résultats produits soient parfaitement explicitables, ce qui demande d’être à même de décrire le processus qui mène d’un ensemble d’observations à une conclusion donnée. Cette exigence de transparence se traduit par le caractère structuré de la méthode et l’explicitation des outils qu’elle comporte. Le second objectif, en partie lié au précédent, est que la méthode soit transmissible, c’est-à-dire que des acteurs extérieurs à notre groupe de recherche soient à même de l’utiliser.
19Les différents acteurs ciblés par cette méthode sont potentiellement tous les acteurs impliqués dans les SIN. Les décideurs de l’organisation pourraient, par exemple, souhaiter se conformer à l’accord-cadre européen sur la transformation numérique des entreprises6. La méthode peut accompagner l’entreprise dans l’identification des points clés de cette transformation, au regard des conditions de travail des salariés et de la participation de ces derniers à la marche de l’organisation. ISIDOR peut également aider les utilisateurs des SIN et leurs représentants à constituer et hiérarchiser des demandes d’adaptation ou de transformation des SIN. À l’extérieur de l’organisation, la méthode a été pensée pour participer à améliorer les pratiques des entreprises de services numériques (ESN) dans leur rôle d’assistance à la maîtrise d’ouvrage, de paramétrages de logiciels sur étagères ou de développement de solutions sur mesure. Notons qu'un des partenaires du projet ANACT est une ESN.
20Nous souscrivons à la question que pose Jardat (2012) quand il écrit :
- 7 Jardat R. (2012), « De la démocratie en entreprise. Quelques résultats empiriques et propositions (...)
(…) à partir du moment où ceux qui travaillent dans l’entreprise sont en même temps les citoyens (ou les sujets) d’un régime politique, comment peut-on imaginer un seul instant que l’idée qu’ils se font des rapports de pouvoir dans la société politique n’ait pas d’influence sur leur perception des rapports de pouvoir en entreprise ?7
21La littérature sur la démocratie dans les organisations étant cependant très limitée, nous avons été amenés à travailler sur la transposition du concept de démocratie dans la société à celui de démocratie dans l’organisation.
- 8 Castoriadis C. (1975), Figures du pensable, Paris, Seuil, p. 182.
- 9 Ricœur P. (1986), Du texte à l’action, Paris, Seuil, p. 404.
22Nous nous sommes appuyé, notamment, sur la définition de Castoriadis, pour qui la démocratie est « le régime de l’autolimitation, autrement dit le régime de l’autonomie, ou de l’auto-institution8 », et sur les définitions de Ricœur qui mettent en avant le consensus conflictuel et décrivent la démocratie comme « le régime dans lequel la participation à la décision est assurée à un nombre toujours plus grand de citoyens9 ».
23Autonomie, participation, citoyenneté, consensus conflictuel sont autant de concepts que nous avons essayé de garder intacts, tout en nous projetant dans le monde de l’organisation, en respectant deux contraintes : d'une part, ne pas réduire notre définition de la démocratie dans l’organisation à l’horizontalité ou à l’absence de hiérarchie, d'autre part, ne pas circonscrire les buts de la méthode au seul bien-être des salariés pour promouvoir une démocratie au service d'un large ensemble de parties prenantes de l'organisation, et de l'organisation elle-même considérée comme une entité globale.
24Notre définition de la démocratie dans l’organisation repose aujourd’hui sur cinq dimensions, complémentaires et interdépendantes :
- la citoyenneté, qui, selon nous, doit être accordée à toutes les parties constituantes de l’organisation (Richer, 2018), c’est-à-dire ceux sans qui l’organisation n’existe pas, et dont les salariés doivent par conséquent, selon nous, faire pleinement partie ;
- l’organisation de la dispute démocratique, à laquelle doit participer tout citoyen de l’organisation, aussi bien pour la définition de problèmes que pour leur résolution ;
- l’expression au sein de l’organisation de visions du monde plurielles et la garantie de l’accès à ces visions dans l’organisation ;
- l’autonomie des personnes, des collectifs, de l’organisation elle-même sur différents périmètres (tâches, organisation du travail, objectifs et finalité de l’organisation) ;
- les processus de décision et la répartition des pouvoirs de décision.
25Notre approche des systèmes d’information numériques s’appuie sur une analyse détaillée de leur genèse (Salles et al., 2020) et une description précise de leurs composants. Un SIN n’est donc pas appréhendé comme une boîte noire que nous ne connaîtrions qu’au travers du seul recueil des vécus et points de vue de ses utilisateurs, aussi essentiels et précieux ceux-ci puissent-ils être.
26Le système d’information (SI), duquel découlent les SIN, est considéré ici comme le langage de l’organisation (Salles, 2015). Comme tout langage, il ne code pas de façon neutre une réalité « exogène », mais participe à construire la réalité dans laquelle fonctionnera l’organisation (lexique, nomenclatures, structures de processus, indicateurs, etc.) (Klinkenberg, 2015). Le SI est performatif, au sens où il définit ce qui existe pour l’organisation, et où, à l’inverse, il crée un système d’invisibilité : ce qui n’existe pas dans le SI n’existe pas pour l’organisation.
27Le SIN est la sous-partie informatisée du SI, porteuse de ses propres caractéristiques techniques, qui conduisent à une normativité et une performativité accrues.
28Si un SIN exprime le niveau de démocratie d’une organisation, ce qui nous intéresse ici est la façon dont, au travers de ses caractéristiques propres, il va rétroagir sur la démocratie. La limitant ou au contraire l’aidant à se développer.
29La manière de travailler formalise le déroulement de la méthode, son processus. Dans ISIDOR, chaque étape fait l’objet d’une fiche la décrivant au travers d’un ensemble de rubriques : tâches, acteur principal, objectifs, acteurs impliqués, risques, etc.
30Le processus général de mise en œuvre d’ISIDOR dans le cadre d’une expérimentation dans une organisation peut être synthétisé comme suit :
- Étape 1. Lancement de l’expérimentation dans l’organisation : cadrage de l’expérimentation avec la direction pour fixer les objectifs pour l’organisation, choisir le ou les SIN à analyser, les participants à impliquer, etc. Présentation de la méthode et de l’expérimentation aux membres de l’organisation ;
- Étape 2. Recueil de documents sur les composants du SIN à analyser : tableaux de bord, documentation projet, captures d’écran, manuel utilisateur du logiciel métier analysé, etc. ;
- Étape 3. Préparation et réalisation des entretiens : spécification des guides d’entretien, organisation et réalisation des entretiens, rédaction des comptes rendus ;
- Étape 4. Analyse et évaluation des composants du SIN au regard des cinq dimensions de la démocratie (voir supra). Rédaction d’une première version du rapport ;
- Étape 5. Clôture de l’expérimentation : présentation orale des résultats à l’organisation (direction, membres de l’organisation), co-construction à la fois du bilan et des voies de progrès, puis rédaction de la version finale du rapport. Capitalisation des connaissances (par l’équipe qui met en œuvre la méthode), pour améliorer la méthode et son utilisabilité.
31La manière de modéliser nous permet d’expliciter la vision concrète et détaillée de chaque objet de la méthode en définissant des représentations formalisées de nos objets d’études (composants du SIN) et de nos moyens d’évaluation (grilles d’analyse, tableaux d’évaluation).
32Tous les objets nous permettant de décrire les composantes du SIN choisi (tableaux de bord, projet informatique et logiciel métier) sont formalisés au travers de structures types. Ainsi, les objectifs et indicateurs du tableau de bord, les documents et instances des projets informatiques, les interfaces homme-machine (IHM) ou encore les tâches réalisées avec le logiciel métier sont décrites selon des structures types (voir Tableau 1).
Tableau 1 : Exemple de structure type de description d’une IHM
| Apparence et clarté |
| Apparence |
Menu(s), lexique |
| Disposition des zones de saisie, d’affichage, de notification |
| Ordre des différents écrans/pages |
| Clarté |
Zones d’affichage |
Structures cohérentes/similaires sur toutes les pages ? Ex. : information importante toujours en haut à droite |
| Couleurs |
Agréables ? Codes couleur pertinents, stables ? |
| Affichage des données |
Taille, police de caractères, etc. |
| Aides |
Compréhensibles ? Pertinentes ? |
| Messages d’erreur |
Compréhensibles, pertinents ? Aident à corriger l’erreur ? |
| Niveaux d’autonomie permis par l’interface |
| Zones de saisie |
Type |
Fixe, numérique, alphanumérique… ou libre ? |
| Longueur |
Fixe ou libre ? |
| Ordre saisie des zones |
Imposé ou libre ? |
| Retours en arrière |
Quelles possibilités ? Faut-il tout remonter ou peut-on corriger directement une zone amont ? |
| Opérations disponibles |
Étendue des opérations disponibles |
Saisie uniquement ? Fonctions de recherche ? Programmation d’opérations spécifiques ? |
| Niveau d’interactivité |
Ex. : à partir d’une réponse du système, peut-on lancer une nouvelle opération ? |
| Droits |
Droits |
Quelles catégories d’utilisateurs, quels niveaux de droits ? => qui peut faire quoi (saisie, affichage, fonctions, extractions…) ? |
33La mesure de l’impact du SIN sur la démocratie dans l’organisation repose sur deux outils : les grilles d’analyse et les tableaux d’évaluation. Chacun de ces outils est construit autour d’un couple composante du SIN analysée/dimension de la démocratie impactée.
34Les grilles d’analyse sont renseignées lors de l’étape 4 (voir Tableau 2).
Tableau 2 : Exemple de grille d’analyse de l’impact d’une IHM sur l’autonomie
| Utilisation du logiciel |
| Quel est le sentiment/ressenti général par rapport au logiciel ? |
| Les utilisateurs ont-ils bénéficié de formations, de manuel d’utilisation… ? |
| Est-ce que le logiciel guide entièrement la procédure de travail de l’utilisateur ? |
| Une partie du travail peut-elle être faite sans le logiciel ? |
| L’utilisateur doit-il faire appel à un supérieur pour utiliser/débloquer certaines parties du logiciel ? |
| L’utilisateur a-t-il la possibilité de saisir du texte libre (commentaires, explications…) ? |
| Existe-t-il un droit à l’erreur avec le logiciel ? Les messages d’erreur favorisent-ils l’apprentissage ? |
| L’outil de travail est-il également un outil de contrôle (chronométrage, pointage, contenu, temps passé, interruptions, erreurs) ? |
| Le logiciel soutient-il ou entrave-t-il la coopération, l’intelligence collective dans l’organisation ? |
| Quel apprentissage dans l’utilisation du logiciel ? Quel apprentissage dans l’acte de travail grâce à l’IHM ? |
| L’usage du logiciel est-il détourné ? Contourné ? Étendu à des usages non prévus à l’origine ? |
| Évolution du logiciel |
| L’utilisateur peut-il proposer des modifications du logiciel ? Peut-il effectuer des modifications lui-même ? |
35Le tableau d’évaluation est le dernier maillon de la chaîne pour l’évaluation. Chaque tableau synthétise l’analyse pour livrer une mesure d’impact d’une composante du SIN sur une dimension de la démocratie (voir Tableau 3).
Tableau 3 : Exemple de tableau d’évaluation de l’impact d’une IHM sur l’autonomie
| 1 |
L’IHM fait de l’opérateur un simple appendice, exécutant et isolé. |
| 2 |
L’IHM permet une autonomie restreinte : quelques zones de saisie libres, retours arrière, droit à l’erreur, etc. |
| 3 |
L’IHM donne à l’opérateur une autonomie dans l’organisation de ses tâches. |
| 4 |
L’IHM donne à l’opérateur une autonomie dans l’organisation de ses tâches. Elle permet la coopération. Une procédure existe pour faire remonter des besoins de modifications de l’IHM. |
| 5 |
L’IHM favorise l’autonomie de l’opérateur dans l’organisation de ses tâches. Elle est un support à la coopération. L’opérateur peut modifier lui-même l’IHM. |
36Conscients que les méthodes d’évaluation de systèmes complexes (dont les SIN) posent des problèmes de mise en pratique, nous accordons une grande importance à la manière d’aider d’ISIDOR. Les aides représentent une forme de connaissance experte incarnée dans des « objets » accessibles (récits d’expériences, exemples/cas types, outils de facilitation de l’expression…), explicites, et donc discutables.
37Par exemple, ISIDOR inclut des guides d’entretien génériques par composante du SIN. Ces guides peuvent bien entendu être ensuite spécifiés pour une organisation particulière.
38Le but de cette partie est de donner quelques illustrations d’une mise en œuvre d’ISIDOR pour les étapes 1 à 4, sans recherche d’exhaustivité.
39Une première expérimentation de la méthode ISIDOR a été menée au sein du département des ressources humaines (RH) d’une importante faculté (12 000 étudiants) d’une grande université de la région Occitanie.
40L’expérimentation a porté sur les cinq dimensions de la démocratie évoquées plus haut. La version actuelle d’ISIDOR analyse ces cinq dimensions au travers de trois composantes du SIN, selon nous très représentatives : une ou un ensemble d’IHM d’un logiciel métier, des tableaux de bord, et la gestion du projet qui a mené à l’implantation du SIN et/ou qui permet d’en gérer l’évolution tout au long de sa vie.
- 10 Le développé de ce nom fictif serait « logiciel de gestion des heures d’enseignement ».
41Une première réunion a eu lieu avec la direction du département RH, pendant laquelle le logiciel métier qui serait l’objet de l’analyse a été choisi. Ce SIN, que nous nommerons ici LOGHE10, gère les charges d’enseignement. Nous comprendrons par la suite que ce logiciel est le favori des agents du département, et qu’ils ont souhaité nous montrer ce qu’ils considéraient comme le meilleur SIN parmi ceux qu’ils utilisent.
42Le logiciel étudié a une histoire longue qui commence en 2002 par un outil développé par un enseignant-chercheur (EC) au sein d’un département particulier. Le but de cette première version est de permettre à tous les EC du département de voir les enseignements existants et les collègues qui les assurent, ou, à l’inverse, de voir pour un collègue donné, quels sont les enseignements qu’il effectue. La logique est celle d’une transparence maximale. Le logiciel est repris quelques années plus tard par un autre EC (que nous désignerons par les initiales AB), qui lui donne, petit à petit, une tout autre dimension. LOGHE est ainsi ouvert à d’autres départements de la faculté, puis de l’université, enrichi de nouvelles fonctions ainsi que de passerelles avec d’autres logiciels, et complété d’un module destiné aux agents de l’administration pour la préparation de la paye des heures complémentaires.
43C’est ce module de gestion de la paye qui sera le premier objet de notre étude, laquelle sera étendue par la suite à d’autres modules (voir ci-dessous).
44La réunion a également permis de déterminer un premier ensemble de dix personnes à interviewer, essentiellement des gestionnaires du département RH, ainsi que les conditions des entretiens (en général près du poste de travail, individuels ou collectifs selon les cas). Étant donné que les EC, et en particulier ceux chargés d’une responsabilité (de département, de formation, ou de mention, élus…), utilisent beaucoup ce logiciel (pour attribuer les enseignements, préparer les demandes de postes, ou encore préparer les dossiers d’accréditation de nouvelles formations), il nous a paru intéressant d’analyser également cette utilisation de LOGHE. La liste des personnes à rencontrer a évolué en conséquence, de même que les modules du logiciel étudiés. Une dizaine d’EC, principalement des responsables, ont ainsi également été interviewés.
45À notre demande, un premier ensemble de documents nous a été transmis : guide utilisateur (pour la partie RH), exemples de tableaux de bord, copies d’écran.
46Quinze entretiens au total, d’une durée moyenne d’une heure et demie, ont permis d’échanger avec un total de 19 personnes (à peu près également réparties entre personnels administratifs et EC).
47Il s’est agi d’entretiens semi-directifs, réalisés à l’aide de guides, et menés par un groupe de deux (parfois trois) membres de l’atelier SI2D. Les guides d’entretiens génériques de la méthode ont été spécifiés pour être adaptés à l’organisation, au logiciel étudié, ainsi qu’au type d’utilisation du logiciel pour les deux principales catégories de personnes rencontrées (agents et responsables administratifs, EC en responsabilité).
48Cette section présente des extraits de l’analyse des entretiens menés, à titre d’illustration d’une application d’ISIDOR. Seules deux dimensions de la démocratie sont considérées et seuls certains modules de LOGHE sont évoqués.
49Cette dimension est déclinée en plusieurs items dont nous ne reproduisons ici qu’une partie, en résumant les constats.
50Le ressenti général des gestionnaires du département RH par rapport à LOGHE est très positif : « la vie a changé [avec LOGHE] », « il facilite notre travail », « ça nous a enlevé beaucoup de saisies répétitives [des mêmes données sur différents logiciels] », « lui [LOGHE] il fait ce qu’on lui demande ».
51Ils ont pu bénéficier de formations, et disposent d’un manuel d’utilisation très complet. Pour concevoir la partie « Paye » de LOGHE, le concepteur du logiciel, AB (rappelons qu’il s’agit d’un EC de la faculté), est venu dans le département RH. Il a passé beaucoup de temps avec les agents pour comprendre très précisément comment ils travaillaient, et reste très accessible en cas de problème.
52Les EC de leur côté ont un avis nettement plus mitigé. Ils ne bénéficient d’aucune formation, ne disposent pas d’un manuel. Pendant l’entretien que nous avons eu avec lui, AB nous a clairement dit que « les EC de base doivent pouvoir utiliser [LOGHE] sans formation ». Les EC rencontrés n’ont pas le même ressenti, et considèrent que le logiciel s’est beaucoup complexifié et que « l’outil [LOGHE] devient difficile à utiliser ». « C’est un logiciel dont l’administration s’est emparée ».
53S’agissant de la coopération entre utilisateurs de LOGHE, on constate que le logiciel soutient la substituabilité entre agents, ce qui permet une continuité des traitements, même en cas d’absence d’un gestionnaire.
54À l’origine, comme nous l’avons signalé, LOGHE a été conçu pour que les EC puissent consulter les enseignements et les services des collègues avant de demander l’attribution de tel ou tel enseignement. Cela permet de limiter les conflits, et, pour les EC responsables, réduit la nécessité d’arbitrer. Mais aujourd’hui, à la suite de modifications du logiciel, « il n’y a plus de façon simple de voir les cours qui seraient disponibles ».
55Pour ce qui est des droits accordés aux utilisateurs, si les droits accordés aux gestionnaires RH sont tout à fait cohérents avec leurs fonctions et leur niveau de responsabilité, les droits accordés aux EC peuvent parfois paraître un peu curieux. Les EC « de base », de même que certains EC responsables peuvent consulter des tableaux de synthèse (« statistiques ») à l’écran, mais ne peuvent pas les télécharger pour les retravailler sur Excel. Certains de ces EC contournent la difficulté en s’adressant à un collègue disposant des « bons » droits pour lui demander de récupérer les tableaux à leur place.
56Finalement, le bilan qui peut être tiré de la dimension « autonomie » différencie nettement la situation des gestionnaires de celle des EC.
57Dans l’évaluation du niveau d’autonomie des utilisateurs du département RH, LOGHE se positionne très bien, au niveau 4 du tableau (voir Tableau 3).
58En ce qui concerne les EC, les réorientations successives de LOGHE, qui marquent son objectif aujourd’hui devenu financier et comptable, ont sérieusement dégradé leur niveau d’autonomie.
59À nouveau, nous résumons ici les principaux constats.
60Pour apprécier la vitalité de la dispute démocratique autour d’un SIN, nous nous intéressons à la gestion de projet de son cycle de vie global, qui inclut donc, pour les logiciels déjà en place comme LOGHE, la gestion de leur évolution.
61Pour cette dimension, nous avons à nouveau observé des différences majeures entre utilisateurs gestionnaires RH et utilisateurs enseignants-chercheurs.
62Malgré un emploi du temps très chargé, AB se rend très disponible pour les gestionnaires RH, il est très à l’écoute de leurs besoins, et ceux-ci expriment à son égard une grande confiance et une réelle reconnaissance. Les gestionnaires « discutent [avec leur responsable d’équipe] des demandes d’amélioration à faire remonter » à AB. La responsable organise les demandes, les saisit dans un fichier Excel sous une forme semi-formalisée qu’elle a définie elle-même, et les envoie à AB (« Je fais ma liste au père Noël »), en mettant en copie les deux ingénieurs qui forment, avec AB, « l’équipe LOGHE ». AB est ainsi destinataire de toutes les demandes de modifications de LOGHE. La responsable envoie une seule liste de demandes par an, mais il y a des contacts tout au long de l’année : « en fait, c’est souple, du côté de l’équipe d’AB, ils acceptent tous les modes pour les contacter », « je suis un peu la machine à persécuter, j’en profite, parfois quand je l’ai [AB] au téléphone, je lui demande ça et ça et ça ».
63La situation est à nouveau très différente pour les utilisateurs EC.
64LOGHE a connu une évolution majeure quand il est devenu un outil pour l’administration sur un sujet très réglementé, le paiement des heures complémentaires. Cette évolution a été décidée au niveau de la présidence de l’université et du CAC (principal conseil de l’université), sur proposition d’AB. Plusieurs EC nous ont exprimé leur insatisfaction d’être alors devenus « des utilisateurs non prioritaires » (« les évolutions du logiciel n’ont pas été faites pour les besoins des EC »), sans avoir été préalablement consultés. Les évolutions suivantes ont confirmé une orientation comptable, voire financière, mais aussi l’absence de consultation des EC. Par ailleurs, le mode de calcul des projections qui ont mené à l’évaluation de la charge d’enseignements pour la nouvelle accréditation n’a pas fait l’objet de débats.
65Si l’orientation globale de LOGHE et son évolution ne font pas l’objet d’une dispute démocratique, des discussions ont en revanche eu lieu sur les indicateurs calculés dans LOGHE. C’est le cas en particulier pour ceux qui servent de base aux travaux des conseils pour déterminer le nombre de postes d’EC qui sera demandé pour chaque département. Mais notons que beaucoup d’EC « de base » ignorent comment ces indicateurs sont calculés.
66Le bilan qui peut être tiré de la dimension « dispute démocratique » fait apparaître qu’il n’y a pas véritablement de gestion de projet pour l’évolution de LOGHE : pas d’instances représentant les utilisateurs, pas de procédure formalisée de recueil des besoins et de leur hiérarchisation, pas de procédure collective de prise de décision, pas d’outil de gestion des conflits… Le très fort investissement d’AB envers les gestionnaires RH a jusque-là permis que ceux-ci travaillent efficacement et dans de bonnes conditions. Ce qui n’est pas le cas pour les EC, qui ont vu leurs besoins progressivement ne plus être pris en compte et leurs conditions d’utilisation du logiciel se dégrader très sensiblement, jusqu’à empêcher l’usage pour lequel il avait été à l’origine conçu.
67Cette absence de gestion de projet, même dans une forme simplifiée, ainsi que le passage obligé par une personne unique (AB) pour toute demande, a pour conséquence un très faible niveau de démocratie sur la dimension « dispute démocratique ».
68La conclusion générale que nous tirons de l’impact de LOGHE sur la démocratie dans l’organisation étudiée est à mettre en rapport avec la définition de Ricœur proposée plus haut : « un régime dans lequel la participation à la décision est assurée à un nombre toujours plus grand de citoyens ». De ce point de vue, il apparaît nettement que LOGHE n’a pas évolué en soutenant la démocratie. Les réorientations successives du logiciel ont ainsi sensiblement infléchi son objectif principal, pour le rendre prioritairement financier et comptable, sans qu’il ait été démontré que cette réorientation ait été largement débattue et a fortiori approuvée.
69Si plusieurs aspects de la méthode s’avèrent bien adaptés, celle-ci nécessite encore un travail conséquent pour répondre aux objectifs fixés (en particulier sa transmissibilité).
70Les outils de la méthode ont été aisés d’utilisation, et ont pu être facilement adaptés à l’organisation étudiée. À titre d’exemple, les questions des grilles d’entretiens (semi-directifs) ont paru pertinentes à nos interlocuteurs, qui les ont comprises sans effort. Par ailleurs, ces questions ne semblent pas les avoir restreints dans leur expression.
71L’expérimentation a confirmé l’intérêt de la méthode et de ses finalités (toutes n’ont pas encore pu être testées), par exemple celle de faire prendre conscience aux acteurs des enjeux liés aux SIN. Un EC (responsable de mention) nous disait ainsi à propos de graves dysfonctionnements d’un logiciel d’inscriptions des étudiants : « Là j’ai vu vraiment ce qui peut se passer chez un être humain quand un logiciel dysfonctionne. J’ai reçu des étudiants véritablement en larmes venir à mon bureau parce qu’ils n’étaient pas inscrits… », puis, en fin d’entretien : « En parlant avec vous, je prends conscience de choses. Je me disais [par rapport aux problèmes de logiciel] : “C’est la vie”. Mais non… ».
72Parmi les trois composants analysés, un résultat de l’expérimentation est la confirmation de la place centrale du composant « Gestion du projet informatique » quant à l’impact du SIN sur la démocratie de l’organisation. Les outils d’analyse de ce composant devront être complétés et affinés.
73Plusieurs points d’ISIDOR doivent être sensiblement améliorés, en particulier le processus de traitement et d’analyse des entretiens, qui est actuellement trop long, trop lourd, et requiert encore une expertise relevant de la recherche. ISIDOR reste ainsi encore par trop une production de recherche, ce qui est contraire à l’objectif de transmissibilité de la méthode. Notons que l’évolution de la méthode est un objectif majeur du projet de recherche soutenu par l’ANACT.
74La méthode présentée dans ce texte a pour ambition d’aider les acteurs des organisations à mener un dialogue fécond autour du numérique. Si la première expérimentation a montré des résultats encourageants, elle a aussi révélé des points qui doivent être retravaillés ou développés.
75Au-delà du perfectionnement de tel ou tel outil de la méthode, la réflexion doit se poursuivre sur les bases qui la fondent (la « manière de penser »). Deux thèmes vont ainsi faire l’objet d’un travail spécifique : la transposition de caractéristiques de la démocratie dans la société vers la démocratie dans les organisations d’une part, la question du temps dans la vie de l’organisation d’autre part.
76Le premier point a déjà fait l’objet d’un travail conséquent dans notre équipe. Cependant, les premières expérimentations ainsi que les contacts menés pour trouver de nouveaux terrains, ont montré qu’il était nécessaire de le poursuivre. Il convient notamment d’établir une typologie des types d’organisations en rapport aux types de démocratie organisationnelle susceptibles de s’y déployer. Une société de capitaux, une coopérative, une association ou encore une université, ne considèrent ni ne vivent la possibilité d’un fonctionnement démocratique dans des termes semblables. La méthode doit en tenir compte.
- 11 Caye P. (2020), Durer. Éléments pour la transformation du système productif, Paris, Les Belles Let (...)
77Le travail sur le terrain a également révélé l’importance de la question du temps. Le fonctionnement démocratique semble étroitement lié à une prise en compte d’un temps long, d’un souci de pérennité de l’organisation. Un certain nombre de problèmes dans la gestion des projets informatiques sont ainsi liés à une sous-évaluation manifeste du temps nécessaire à l’intégration d’un système complexe dans une organisation humaine. Comme l’écrit Pierre Caye (2020), « La souveraineté du temps propose la réouverture de la question démocratique11 ».