Le système d’information (SI), qu’il ne faut pas confondre avec les systèmes d’exploitation (Linux, Windows, Android, macOS…), est un territoire partagé entre les informaticiens, chargés de le faire fonctionner, et les gens des « métiers » (finance, budget, comptabilité, ressources humaines, etc.), qui l’utilisent dans leur travail. Toute la difficulté de la réalisation d’un SI d’entreprise réside dans l’effort que ces acteurs aux métiers et aux cultures différentes doivent faire pour comprendre leurs objectifs et leurs contraintes respectifs.
Mythe n° 1 : le Système d’information c’est fini
Le Système d’information et ses agents (pour ne pas dire ses soutiers) sont rarement populaires dans les entreprises et autres organisations, tout le monde aimerait bien s’en débarrasser, et souvent il ne leur est possible d’échapper à ce sort cruel qu’en veillant à conserver un certain pouvoir de nuisance.
Jusqu’à tout récemment, l’arme fatale pour la destruction du SI et surtout de ses séides était l’externalisation, mais les dernières années ont enrichi l’arsenal : Software as a service, Cloud, micro-services, sans oublier l’« informatique des utilisateurs » et les « logiciels de gestion intégrée », déjà anciens. On pourra bien sûr mobiliser tout ce vocabulaire pour rédiger les lettres de licenciement des informaticiens, mais cela ne suffira pas à produire les documents budgétaires et comptables, ni les bases de données RH, clients, fournisseurs, ni l’annuaire du personnel, objets certes désuets et fastidieux, mais dont il est à craindre qu’ils ne soient encore indispensables pour les années à venir.
Il m’a été donné l’honneur d’être le premier directeur du système d’information (DSI) d’une prestigieuse université parisienne. J’avais postulé à ce poste en partie parce que mes expériences antérieures m’avaient inspiré une certaine aversion pour le SI, et que je voulais en faire l’expérience. Je dus venir à résipiscence : sans SI, impossible d’administrer les dossiers et les parcours d’une dizaine de milliers d’étudiants et d’un millier d’enseignants de statuts divers et variés, ni de répondre aux exigences de plus en plus tatillonnes au fil des ans de la bureaucratie ministérielle, non plus que de maintenir à jour un annuaire de tous ces gens, ce qui permet de leur faire parvenir du courrier électronique, de leur délivrer des diplômes, de leur ouvrir un accès à l’espace numérique de travail qui contient les textes de leurs cours et de leurs travaux pratiques, ainsi qu’au système d’examens en ligne, en évitant toutefois que les étudiants n’aient un accès trop facile à la base de données de scolarité, qui contient les résultats d’examens.
Comme un de mes fidèles lieutenants lors de cette expédition dans la jungle me l’a fait remarquer, la propriété première et primordiale d’un SI, c’est l’unicité, et elle n’est pas facile à obtenir. Si l’on n’y prend garde, de petits SI dissidents naissent à tout moment et dans les endroits les plus bizarres, et si, par défaut de vigilance, on ne les élimine pas immédiatement, une fois qu’ils ont poussé quelques tentacules ici ou là, on aura le plus grand mal à s’en débarrasser. Et ils seront des vecteurs d’incohérences irréductibles. Bien sûr, il y a des endroits où la cohérence n’est pas utile, et où il ne faut donc pas l’imposer, les activités de recherche par exemple, ou plutôt, les chercheurs ont leurs propres impératifs de cohérence, sans lien avec le SI, sauf pour les contrats et le financement. Mais pour la rémunération des personnels et le règlement des factures, la cohérence est de mise, parce qu’incohérence signifie malversation, détournement.
Mythe n° 2 : les applications de gestion c’est très simple
Combien de fois n’ai-je pas entendu cette assertion de la bouche de brillants chercheurs, éventuellement issus des meilleures écoles de la République : « Un logiciel de comptabilité, je vous écris ça en une après-midi » (sic, et de quelqu’un de vraiment très bien par ailleurs, qui passait huit heures par jour à écrire des programmes statistiques assez subtils).
Les praticiens des sciences à taux élevé de mathématiques, ou les ingénieurs qui appliquent ces sciences à des questions pratiques, ont souvent tendance à penser que leurs problèmes sont bien plus difficiles que ceux des comptables et autres gestionnaires, ils ont sans doute raison, mais de cela ne découle pas que l’informatisation de leurs problèmes soit plus difficile. Michel Volle m’a fait remarquer un jour que ce qui était difficile dans un problème de physique, par exemple, c’étaient les aspects physique et mathématique, mais justement la programmation informatique de la solution pouvait tirer profit du formalisme mathématique rigoureux élaboré à cet effet.
L’ingénieur qui conçoit un objet matériel dispose d’un ensemble d’outils conceptuels bien établis, notamment les lois de la physique et de la chimie, sur lesquels il peut s’appuyer pour élaborer son projet, l’expliquer à ses collègues et à son employeur, éventuellement par des dessins ou des maquettes, etc.
L’architecte de système d’information ne dispose de rien de tel, la matière dont il doit tirer la substance de son projet est mouvante, floue, variable. La complexité du processus d’informatisation est sous-estimée par les responsables à la formation insuffisante. Une cause récurrente d’échec de l’informatisation réside dans la difficulté éprouvée par beaucoup de dirigeants à se faire une idée raisonnable de ce qu’ils peuvent attendre de l’informatique, de ce que cela va coûter, et surtout de l’implication personnelle exigible de chacun pour que cela réussisse.
La difficulté principale pour construire un SI de gestion, c’est de savoir ce que l’on veut faire (question en général assez facile pour un logiciel de calcul pour la physique ou les statistiques). Cette difficulté se décompose en sous-problèmes : trouver un interlocuteur ; faire le tri entre plusieurs interlocuteurs divergents ; s’adapter à la versatilité des interlocuteurs ; s’adapter à la versatilité du législateur, dont les décisions doivent être prises en considération même si elles remettent en cause des choix antérieurs. Ensuite on peut s’attaquer aux problèmes techniques, qui ne sont pas forcément simples, mais dont la solution ne mènera sans doute pas au Turing Award.
Mythe n° 3 : les systèmes intégrés c’est fini, vivent les micro-services !
Les SI de gestion, comme les autres applications informatiques, suivent les modes : bases de données, SQL (Structured Query Language), progiciels, ERP (Enterprise Resource Planning, ou Progiciel de Gestion Intégré), UML (Unified Modeling Language), méthodes agiles, et maintenant micro-services, sans oublier que tout va se faire avec des smartphones. Toutes ces techniques peuvent mener à un bon résultat, ou à un mauvais résultat, ou à l’absence de résultat, cela ne dépend pas de la technique choisie, ni d’ailleurs de la quantité d’argent consacrée au projet, mais bien plutôt de la compétence et de l’implication des acteurs.
J’ai eu l’expérience d’un projet de SI ressources humaines (RH : cette locution m’écorche la bouche autant que le clavier mais il faut s’exprimer ainsi pour être compris) où le DRH n’était pas persuadé de l’utilité d’une base de données unique et cohérente, puisque, disait-il, chacun de ses agents avait dans son PC les feuilles Excel qui allaient bien, et que c’était bien suffisant. Inutile de dire que les feuilles Excel étaient incohérentes, peu à jour, souvent fausses mais fausses différemment d’un poste à l’autre, et que le projet SIRH était ainsi voué à un échec inéluctable. Sans SIRH, pas d’annuaire du personnel, donc pas de système d’identification et d’authentification unique, pas de gestion des habilitations, bref pas de SI du tout. Il a fallu que je convainque le DG de donner l’ordre au DRH d’agir dans le sens requis, ce qui a été possible grâce à un adjoint du DRH compréhensif et diligent (mais je crains que ce résultat n’ait été que temporaire et que l’on ne soit revenu à Excel, c’est-à-dire à la négation de tout SI).
À quel point est-ce grave de ne pas avoir de SI ? Il faut un SI sobre, pour ne pas dire minimum, mais pour certaines fonctions c’est indispensable. Toujours dans la prestigieuse université évoquée ci-dessus, j’ai eu à piloter la mise en application de la loi « Libertés et responsabilités des universités » (LRU, dite « loi Valérie Pécresse ») et des « responsabilités et compétences élargies » (RCE) qui en découlent. Cette application est essentiellement une question de SI. Parmi les RCE en question figure la rémunération des personnels, qui auparavant relevait pour l’essentiel de l’administration centrale du ministère. Il allait donc falloir que l’université sache quels étaient ses salariés, et combien elle les payait : aussi bizarre que cela puisse paraître, personne n’en avait la moindre idée. La recherche de cette information m’a permis de découvrir plusieurs canaux de rémunération, dont tout avait été fait pour qu’il soit impossible de les réunir, afin que plusieurs rémunérations versées à la même personne, sur des comptes bancaires différents (à sa demande), ne puissent pas être rapprochées afin de connaître sa rémunération totale. Le rétablissement d’une vue d’ensemble a fait accuser la DSI de « flicage », puisqu’aussi bien la connaissance par l’employeur de la somme qu’il verse à un de ses salariés serait un empiètement inadmissible sur les libertés individuelles. Mais ce travail de mise en cohérence exigea plusieurs mois d’ingénieur.
Mythe n° 4 : il suffit d’acheter le bon logiciel
Toujours à l’université, la DSI fit l’emplette d’un logiciel de gestion financière et comptable basé sur un célèbre ERP du commerce ; nous disposions déjà d’un logiciel de gestion de la scolarité. Puisqu’ERP signifie en français « Progiciel de gestion intégré » (PGI), beaucoup croyaient (dont certains enseignants de Système d’information) que la gestion de l’université serait « intégrée » ipso facto.
En fait, une fois les logiciels installés, le plus dur reste à faire, parce que ces logiciels sont bien incapables d’inventer par eux-mêmes la liste des cours et des diplômes délivrés par l’université, ni les comptes fournisseurs, ni encore moins les règles de gestion qui s’appliquent à chacun de ces objets.
Les règles de gestion : dans un autre établissement, j’ai eu à piloter le passage à l’Euro. Lorsque l’on convertit des comptes de francs en euros, il y a un problème d’arrondi dans les calculs, cela s’appelle chez les comptables le problème des « rompus ». Trois solutions sont possibles : convertir les lignes détails et rétablir le bon total à la fin, ne convertir que le total, ouvrir pour chaque ligne détail une ligne supplémentaire pour y inscrire la différence. Les comptables responsables, dont le chef était la personne la mieux payée de toute l’entreprise, n’ont jamais su répondre à la question du choix parmi ces trois possibilités. Finalement, entre informaticiens, nous avons choisi la solution 2, la plus paresseuse, mais ce genre de situation est ce qu’il y a de plus difficile pour un architecte de SI : trouver un interlocuteur qui comprend de quoi il s’agit, alors que c’est censé être son travail. Autrement, les logiciels, on arrive toujours à les faire marcher, à condition de ne pas avoir été submergé par les demandes d’adaptations spécifiques idiotes issues de la consultation des utilisateurs.
Mythe n° 5 : il n’y a qu’à externaliser les développements !
De nos jours la construction d’un SI de gestion ne demande généralement pas le développement d’un logiciel spécifique à partir d’une feuille blanche, on part généralement de systèmes de gestion de bases de données (SGBD) et d’ERP existants, mais ce n’est pas pour cela qu’il ne reste pas beaucoup de travail à faire : paramétrage, définition des règles de gestion, description des entités de l’entreprise dans son vocabulaire propre (comme nous l’a appris Michel Volle), création d’interfaces avec les autres systèmes de l’entreprise. Tous ces travaux sont des développements, généralement lourds et complexes. Pourquoi ne pas s’en débarrasser en sous-traitant le tout à des prestataires extérieurs ? Beaucoup d’entreprises, surtout françaises, cèdent à cette tentation. Voici ci-dessous quelque raisons d’être prudent.
Pour que cela se passe bien, il faut avoir au sein de l’entreprise de vraies compétences informatiques, c’est-à-dire des ingénieurs capables de comprendre et de critiquer tous les aspects du développement même s’ils ne le font pas eux-mêmes. Ce qui signifie bien entendu que leur activité n’est pas limitée à la rédaction de cahiers des charges et à l’administration de contrats, mais qu’il leur arrive de développer réellement, et pas tous les dix ans. Incidemment, et contrairement à la doxa répandue par les SSII et la presse spécialisée, il n’y a pas de honte à entreprendre des développements avec ses propres personnels.
Un bon équilibre doit être trouvé entre les compétences internes et externes. Si les effectifs de développeurs internes descendent en dessous d’un seuil de 40% sur l’ensemble des projets, la situation devient dangereuse. Il s’agit bien sûr ici de vraies compétences en informatique, pas en chefferie de projet ou en comptabilité. Ce ratio de 40% doit être adapté aux circonstances : en situation de croissance d’activité il convient d’augmenter la part des effectifs internes pour ne pas être pris de court devant des besoins nouveaux, par exemple jusqu’à 60%, alors que si l’on prévoit une baisse d’activité il peut être judicieux d’accroître le recours à l’externalisation pour éviter d’avoir plus tard à organiser des plans sociaux. Mais l’idée est de maintenir une situation où l’entreprise garde le contrôle de son SI.
Il faut mettre en pratique au moins une idée : la spécification du logiciel évoluera et s’affinera au fur et à mesure du développement, il est inutile, voire nuisible, de fixer trop de choses au départ. La rédaction de l’appel à concurrence et le choix d’un éventuel prestataire dépendent fortement de ce principe.
Le client réel, celui qui sera le bénéficiaire du système à réaliser, doit s’impliquer fortement et concrètement dans le projet. S’il ne le fait pas, il doit renoncer à son droit de parole au profit d’une maîtrise d’ouvrage déléguée qui, elle, devra prendre part activement au développement. Si ni l’une ni l’autre de ces conditions ne peut être remplie, le projet sera un échec, inéluctablement.
Mythe n° 6 : confier le SI aux métiers !
Pourquoi y aurait-il une DSI (ou DN pour être à la mode) qui régnerait sur le SI ? Les gens des métiers (finances, RH, communication, etc.) savent mieux que personne ce qu’il leur faut, et comme de toute façon tout le travail sera confié à des prestataires extérieurs, inutile de s’encombrer de ces informaticiens caractériels.
J’ai eu l’occasion d’observer la mise en œuvre de cette politique chez un de mes employeurs. La direction financière et la DRH avaient obtenu d’avoir leur propre équipe SI, qui traitait directement avec ses prestataires. Bien sûr, les équipes SI avaient été recrutées sur un critère simple : ne rien connaître à l’informatique, parce que c’est toujours très pénible de discuter avec des gens compétents, ils soulèvent toujours des tas de problèmes ennuyeux auxquels on ne comprend rien, tandis qu’entre incompétents on s’entend toujours bien mieux.
Les prestataires ne tardent pas à repérer, parmi leurs clients, ceux qui sont incompétents : c’est avec eux qu’ils vont faire leur marge, parce qu’avec les compétents ils couvrent à peine les frais. Alors avec ceux qui ne voient rien ils chargent la barque au maximum : effectifs pléthoriques de soi-disant ingénieurs qu’ils envoient se former aux frais du client et dans ses locaux, par exemple.
Dans ce cas précis nous avions pu estimer le surcoût de projets confiés aux « métiers », par comparaison avec des projets comparables gérés par la DSI : le facteur multiplicatif était 4 (quatre). Mais bon, quand on aime on ne compte pas.
Mythe n° 7 : l’analyse de l’existant
Comment le maître d’ouvrage, angoissé à juste titre par l’idée d’avoir à rédiger des spécifications pour un système destiné à être mis en place plusieurs années plus tard, va-t-il essayer de rédiger un cahier des charges à l’épreuve de tous les événements prévisibles ou imprévisibles ? C’est là qu’il tombe le plus souvent dans l’ornière que lui conseillent d’ailleurs tous les bons auteurs : l’« analyse de l’existant ». Cette activité en apparence innocente rassure les chefs de projet angoissés devant les incertitudes de l’avenir et les subtilités de technologies qu’ils ne connaissent souvent pas suffisamment. Or l’existant c’est l’organisation issue du passé que l’on veut justement remplacer. Il serait idiot de l’ignorer totalement, mais lui consacrer trop de temps peut avoir une influence néfaste. Pire : la rédaction des spécifications est souvent confiée à des personnes issues du terrain, ancrées dans les pratiques du passé sur lesquelles elles n’ont pas un regard suffisamment critique. Dans ce cas, et il est courant, le cahier des charges va consister en l’énumération de ces procédures, qu’il faudrait justement réformer. La démarche du projet, loin de déboucher sur une rénovation du système d’information, va durcir et ossifier des pratiques qui n’étaient jusque là que de mauvaises habitudes et dont l’énoncé va désormais être gravé dans le marbre du cahier des charges. Le projet aura débouché sur un renforcement de la bureaucratie et des dispositifs paralysants.
Mythe n° 8 : l’expression des besoins
Une autre mauvaise pratique prend généralement son essor à peu près au même moment dans la chronologie du projet : le « recensement (ou l’expression) des besoins ». Le lecteur pourrait croire à un paradoxe : il est évident que l’on ne construit pas un système d’information juste pour le plaisir, et qu’il est préférable d’avoir une idée de l’objectif poursuivi. Cela dit, trop souvent, la pratique qui se donne cours sous ce prétexte ne sert en rien à éclairer la cible visée, mais plutôt à recueillir les opinions et desiderata hétéroclites de personnes plus ou moins reliées à l’activité concernée, et à embrouiller la marche à suivre dans un galimatias de motivations privées ou collectives plus ou moins incohérentes. De toute façon, lorsque viendra le jour de la recette, ces motivations auront complètement changé et les personnes consultées (si elles n’ont pas de toute façon changé d’affectation dans l’entreprise) ne seront pas satisfaites. Bien sûr ce tableau peut varier selon le contexte : dans une entreprise de taille moyenne dirigée par son propriétaire, la personne habilitée à énoncer le besoin est bien identifiée et, surtout, il y a de bonnes chances pour qu’elle agisse de façon conséquente par rapport aux décisions qu’elle aura prises, puisque c’est son argent qui sera engagé — et s’il n’en est pas ainsi, la conséquence sera en quelque sorte morale, parce que celui qui aura commis l’erreur en sera la victime. À l’autre bout du spectre, dans une administration publique en proie à la concertation compulsive, savoir ce que l’on veut vraiment faire est à peu près impossible, et il faut reconnaître que certaines commissions de fonctionnaires risquent d’être prêtes à ne pas reculer devant des décisions incohérentes, d’autant plus que leurs membres n’encourent aucun risque personnel pour les inconvénients qui pourraient en découler. Il est d’ailleurs reconnu depuis longtemps par les spécialistes des organisations que la prise de décision collégiale, loin d’engendrer la modération des décisions, suscite la montée aux extrêmes par un emballement rhétorique que ne vient contrebalancer aucune angoisse devant des responsabilités futures qui seront de toute façon assumées par d’autres ; les deux attitudes en jeu dans ce phénomène sont l’illusion d’unanimité ou au contraire la polarisation conflictuelle, on en trouvera une analyse bien documentée sous la plume de Christian Morel. Et pour des exemples récents, qu’il suffise de prononcer les mots, chers au contribuable, Louvois ou SIRHEN…
La démarche d’expression des besoins peut être fautive de façon encore plus patente : considérons un établissement de recherche de taille moyenne, composé d’une direction générale qui regroupe quelques centaines de personnes et des unités de recherche qui regroupent quelques milliers de chercheurs. Les départements de la direction générale, pour accomplir leur mission d’administration de la recherche, désirent, et c’est peut-être légitime, se doter d’un système d’information pour savoir ce que font tous ces chercheurs. Si on les interroge pour qu’ils expriment leurs besoins, nul doute que l’on obtienne une longue liste d’informations, sûrement pertinentes d’ailleurs. Mais qui va devoir fournir ces informations ? Les chercheurs, déjà submergés de tâches administratives dont l’utilité leur semble obscure, et qui risquent de mal accueillir ces nouveaux formulaires à remplir à propos de tout et du reste. L’expression des besoins sera ici franchement nuisible.
Mythe n° 9 : l’exhaustivité de l’analyse
Les deux erreurs ci-dessus, conjuguées entre elles, peuvent être utilement complétées par une attitude intellectuelle qui semble de prime abord assez saine, mais qui va se révéler comme une nouvelle erreur : le souci d’exhaustivité. Prenons comme exemple un projet de sécurité informatique destiné à évaluer et à améliorer la disponibilité d’un système d’information. Le responsable du projet pourra par exemple s’inspirer de la méthode EBIOS élaborée en France par la Direction centrale de la sécurité des systèmes d’information (DCSSI, devenue ANSSI). Une telle méthode le conduira à dresser une liste des risques, à associer chacun de ces risques à des vulnérabilités, et à envisager les contre-mesures qu’il peut élaborer pour s’en prémunir, selon une formule pleine de bon sens et d’utilité :
risque = menace × vulnérabilité × sensibilité / contre-mesure
Cette conceptualisation est intéressante, mais elle peut engendrer la tentation de dresser une liste de risques ou une liste de vulnérabilités que l’on placera dans la colonne de gauche d’un tableau, afin d’en remplir la colonne de droite avec les contre-mesures appropriées.
Pourquoi cette démarche est-elle maladroite ? Parce que les risques et les menaces sont nombreux et souvent inconnus, alors que le répertoire des contre-mesures possibles est beaucoup plus réduit ; souvent, cela peut se résumer à cinq ou six grands thèmes : plan de sauvegarde des données, plan de reprise d’activité (PRA), amélioration du stockage, aménagement d’un site de secours avec duplication des données à distance, administration correcte des serveurs (fermeture des services inutiles, séparation des privilèges, application des correctifs de sécurité, surveillance des journaux), sécurisation du réseau (pare-feu, authentification forte, fermeture des services inutiles), sécurisation physique des locaux. Il est donc plus simple et plus efficace de partir de la table inverse de la précédente : mettre les contre-mesures dans la colonne de gauche, et énumérer dans la colonne de droite les risques éliminés par elles, ce qui évitera de payer un consultant pendant des mois pour élaborer la liste des centaines de risques plus ou moins réels que l’on peut envisager.
Cette démarche prétendue exhaustive qui consiste à examiner de longues listes d’items pour cocher des cases dans la colonne d’en face, c’est la façon de travailler des ordinateurs, rapides, systématiques et mécaniques ; l’intérêt du travail d’un professionnel compétent par rapport à l’ordinateur, c’est que l’homme réfléchit, a des idées et des connaissances, il est capable d’en tirer parti pour éliminer les cas non pertinents et regrouper les cas similaires de façon à leur appliquer le même traitement, bref il est capable d’avoir une vue synthétique des choses. Réduire le travail humain à des procédures de type informatique est tout à fait contre-productif.
Mythe n° 10 : le schéma directeur
Les trois erreurs ci-dessus peuvent se combiner avec d’autres pour engendrer une méta-erreur encore plus stérilisante : la rédaction d’un Schéma Directeur du Système d’Information. Dans les administrations publiques, commettre cette erreur est une obligation réglementaire. Que le lecteur ne se méprenne pas : mener une réflexion sur les objectifs à moyen terme qu’il semble raisonnable de fixer au Système d’Information ne peut être qu’une bonne pratique, et le faire régulièrement une saine discipline. Mais ce n’est pas de cette oreille que l’entendent les instances de contrôle de l’administration, pour qui l’édification d’un Système d’Information ne saurait être qu’une charge. D’ailleurs le système de comptabilité publique n’offre aucun moyen de prendre en considération la valeur du capital dont la puissance publique se sera dotée en contrepartie de cette dépense. Dans ces conditions, le Schéma Directeur a surtout le rôle de digue destinée à fixer des limites durables aux projets informatiques, et par là à limiter la dépense. Le contribuable qui lit ces lignes pourra penser que limiter les dépenses des administrations n’est peut-être pas une mauvaise chose. Sans doute, mais dans un domaine où l’innovation technique est non seulement foisonnante, mais encore porteuse de réductions de coût soutenues, figer pour plusieurs années le périmètre des développements et, surtout, le catalogue des technologies mises à contribution pour les entreprendre, c’est se donner la certitude de payer trop cher, avec un surcoût de plus en plus important au fur et à mesure que passent les années. Nous avons là un nouvel exemple d’une pratique qui semble de bon sens, alors que sa mise en œuvre sans prise en compte des caractéristiques réelles des objets auxquels elle s’applique, par défaut de compétence technique, aboutit très souvent (et pas seulement dans l’administration) à un résultat opposé à celui qui était espéré.
Évidemment, pour la bureaucratie tout ira très bien, les choses seront bien en ordre, même si elles ont coûté en fait beaucoup trop cher, mais comment le savoir, puisque l’on n’y connaît rien ?
Source : article original de Laurent Bloch