Le système d'information
Michel Volle
Contribution au livre bientôt publié de Laurent Bloch, L'informatique, priorité stratégique pour la France.
Le couple que forment l'être humain et son « ordinateur », interface vers la ressource informatique, a fait émerger un être hybride : le « cerveau d'œuvre » qui résulte de la symbiose de l'informatique et de l'être humain [1], phénomène dont les conséquences sont analogues à celles de la domestication du cheval qui a fait naître le personnage du cavalier, autre être hybride, et aussi celui du chevalier, cavalier expert dans les maniement des armes.
L'informatisation d'une institution ou d'une entreprise réalise une autre symbiose : celle de l'informatique avec une organisation ayant une histoire, des valeurs, une sociologie intime et un comportement collectif. Comme toute symbiose, celle-ci fait émerger un être nouveau : le système d'information.
L'intelligence humaine qui a été stockée dans les processeurs, mémoires, logiciels et réseaux rencontre dans le système d'information une intelligence humaine vivante, active mais emmaillotée dans la sociologie de l'organisation. La complexité de cette hybridation ne peut être surmontée que par une technique particulière qui ajoute aux techniques de l'informatique des exigences analogues à celles du métier des armes ou de la diplomatie, arts confrontés tous deux aux aléas et incertitudes des situations et comportements.
Ces aléas et ces incertitudes n'empêchent pas qu'il existe, pour répondre à ces exigences, des principes qui certes ne suffisent pas à garantir le succès, mais dont on ne saurait s'écarter sans courir à l'échec. On pourrait croire qu'une intuition éclairée par le bon sens puisse suffire pour posséder et appliquer ces principes, mais la décision risque d'errer – et, en fait, errera fatalement – si elle n'est pas guidée par un intellect qu'ont armé l'expérience et la réflexion.
On rencontre parfois, trop rarement, des entreprises admirablement informatisées (Amazon, Décathlon, etc.). Elles ont été organisées, elles sont animées par des entrepreneurs : lorsqu'on s'enquiert auprès des salariés des raisons d'une telle réussite, ils répondent invariablement « le patron s'est impliqué personnellement ». C'est en effet nécessaire pour que l'entreprise puisse surmonter les obstacles que les habitudes et la sociologie des pouvoirs opposent toujours à l'informatisation, et dont résultent des pathologies que l'examen du système d'information permet de diagnostiquer.
La construction et le fonctionnement d'un système d'information obéit à quelques ingénieries dont chacune apporte son lot de principes et que l'on peut délimiter ainsi : l'ingénierie sémantique définit le langage de l'entreprise, avec l'administration des données et les référentiels ; l'ingénierie des processus structure l'action productive, avec la pensée procédurale et la modélisation ; l'ingénierie du contrôle éclaire le pilotage avec les indicateurs et tableaux de bord ; l'ingénierie d'affaires éclaire l'orientation stratégique et le positionnement de l'entreprise en interprétant les données que procurent le système d'information et l'observation du monde extérieur.
L'ingénierie du système d'information ne se confond donc pas avec l'ingénierie de l'informatique qui, avec l'architecture des logiciels et le dimensionnement des ressources, fournit sa plate-forme physique et logique à l'informatisation : l'informatique et l'informatisation sont dans un rapport dialectique analogue à celui qui existe entre la construction navale et la navigation.
Cette dialectique est cependant masquée par la simplicité illusoire de la vie quotidienne. Les personnes, équipées à leur domicile d'un ordinateur et d'un réseau WiFi et accompagnées partout par un smartphone qui leur procure l'accès permanent à la ressource informatique, peuvent croire celle-ci banale et « naturelle ». En réalité l'ensemble est très complexe et les barrières d'accès sont nombreuses. On peut citer par exemple :
les salariés, dont l'activité passe par l'interface qui les relie au système d'information, ignorent la complexité de son architecture et s'irritent de ses éventuels défauts ; parmi les dirigeants, rares sont ceux qui possèdent une intuition exacte de ses exigences et de ses apports ; de grands informaticiens, fascinés et passionnés par les techniques, ne s'intéressent pas aux systèmes d'information dont la nature hybride les contrarie ; l'enseignement de l'informatique ignore souvent les systèmes d'information et ne permet donc pas aux étudiants de comprendre à quoi sert l'informatique ; des méthodes prétentieusement nommées « méthodologies » proposent des garde-fous, mais ceux-ci ne peuvent être respectés que par des personnes conscientes de leur raison d'être ; alors que la qualité des systèmes d'information est cruciale pour l'efficacité des services publics comme pour la compétitivité des entreprises, elle ne figure pas parmi les priorités de l'État.
Il résulte de cette situation une surprenante abondance d'erreurs et de failles de sécurité dans la démarche de l'informatisation et dans l'ingénierie des systèmes d'information. Le bon sens devrait suffire, semble-t-il, pour s'en prémunir et les corriger quand elles se révèlent. Il n'en est rien : il faut donc connaître et expérimenter les principes techniques propres à l'informatisation, dont le présent chapitre contient une description schématique.
L'organisation du cerveau d'œuvre
L'acteur productif, le travailleur qu'emploient les entreprises, est désormais en fait le couple que forment l'être humain et son « ordinateur », interface vers la ressource informatique qui entoure le monde d'un nuage de données et d'algorithmes.
Leur symbiose est le cerveau d'œuvre : il supplante dans l'entreprise informatisée d'aujourd'hui la main d'œuvre que l'entreprise mécanisée d'autrefois employait tout en laissant ses facultés mentales en jachère.
L'ordinateur est un automate programmable conçu pour pouvoir exécuter automatiquement et très rapidement n'importe quel programme [2]. L'art de la programmation sait comment éviter ces pièges., ce qui lui donne une apparence d'intelligence. L'être humain est par contre intuitif, émotif, inventif, donc capable d'agir devant l'inconnu et l'imprévu. Le cerveau d'œuvre fusionne ces deux compétences.
Tout ce qui est prévisible peut en principe être programmé et les tâches répétitives sont éminemment prévisibles : l'informatisation a donc pour conséquence une automatisation des tâches répétitives.
La raison d'être d'une entreprise est d'organiser une action collective pour élaborer un produit jugé utile. La formule de l'efficacité ne réside donc pas dans la seule accumulation des actions individuelles, mais dans la synergie des cerveaux d'œuvre auxquels le système d'information offre une grille conceptuelle commune, un vocabulaire partagé et des outils de communication.
La symbiose que réalise le cerveau d'œuvre multiplie le potentiel du cerveau par celui de l'automate, la synergie des cerveaux d'œuvre multiplie les potentiels individuels pour développer le potentiel de l'organisation. Réussir cette symbiose et cette synergie est l'affaire des entrepreneurs, des organisateurs, et l'organisation se concrétise dans le système d'information en définissant les procédures du travail, les processus de l'action productive et la répartition des pouvoirs de décision légitimes.
Alors que le travail de la main d'œuvre consistait à exécuter des tâches répétitives, l'entreprise demande au cerveau d'œuvre d'avoir du jugement, du discernement, de savoir comprendre ce qu'a voulu dire une personne extérieure à sa spécialité ou à son entreprise, de savoir prendre des initiatives : elle lui délègue ainsi une responsabilité sur le terrain de l'action quotidienne.
Il faut donc qu'elle lui délègue aussi la légitimité qui répond à cette responsabilité : les structures hiérarchiques héritées de la mécanisation s'y opposent encore et leur résistance est le plus grand des obstacles que rencontre aujourd'hui l'informatisation.
Le cerveau d'œuvre engagé dans la programmation des automates accumule un capital, une « intelligence à effet différé ». Le cerveau d'œuvre engagé dans le flux de la production ou de la gestion met en œuvre une « intelligence à effet immédiat ». Dans les deux cas l'entreprise exploite une ressource naturelle, le cerveau humain, qui contrairement aux ressources fossiles est inépuisable car renouvelée à chaque génération.
L'émergence du cerveau d'œuvre fait craquer la croûte des habitudes dans l'économie et la sociologie de l'entreprise : elle transforme le capital et le travail, les procédures de la production, la répartition des responsabilités et légitimités. Elle transforme aussi l'insertion et les effets de l'action productive dans le monde de la nature.
Ces transformations se reflètent et se révèlent dans la conception et l'architecture du système d'information.
La sémantique de l'entreprise
L'informatisation des entreprises a commencé dans les années 1960 par la mise en place d'une informatique de gestion qui donna naissance à des applications séparées : comptabilité, paie du personnel, gestion des stocks. Il apparut bientôt que la séparation de ces applications engendrait des redondances et incohérences dans le traitement des données. D'où l'idée d'unifier en un système cohérent les diverses visions de l'entreprise exprimées par ces applications : ainsi est né le Système d'Information de l'Entreprise, en abrégé SIE.
Si une donnée, disons la catégorie d'un employé, est enregistrée de façon indépendante dans le fichier de paie d'un côté, dans l'organigramme de l'entreprise de l'autre, il est à peu près inévitable que ces enregistrements soient incohérents. C'est pour éviter cela qu'ont été inventés les Systèmes de Gestion de Bases de Données (SGBD), qui permettent de n'associer qu'un seul enregistrement à chaque donnée.
Le mot « donnée » est cependant trompeur car les données ne sont pas « données » par la nature : chacune résulte de l'observation d'un être réel et l'entreprise n'observe que les êtres que concerne son action et ne considère, sur ces êtres, que les attributs qui lui importent. La définition de la grille conceptuelle qui structure cette observation dépend donc de l'action que l'entreprise veut accomplir, de ses intentions et priorités en regard de sa situation.
Le mot « objet », familier en programmation, est lui aussi trompeur : alors qu'il désigne la représentation sélective d'un être réel, il suggère une identité de nature entre cette représentation et cet être. La même confusion résulte de l'utilisation du mot « ontologie », « science de l'être », pour désigner la grille conceptuelle en masquant son caractère sélectif.
Les êtres que contient le monde réel – personnes, institutions, techniques, ressources naturelles, machines, bâtiments et autres artefacts – sont en effet d'une complexité sans limite : aucune description ne peut épuiser leur consistance physique ni leur histoire. Il en est de même de la situation de l'entreprise, de son insertion dans le monde réel. Il serait vain d'ambitionner une connaissance complète et absolue de cette situation et des êtres qu'elle comporte, mais il est possible d'en obtenir une connaissance pratique qui réponde aux exigences de l'action : cela peut et doit suffire à l'entreprise comme aux personnes.
Ainsi l'information n'est pas une denrée qui existe dans la nature : elle est le résultat d'une élaboration selon une démarche en trois temps : définition de la grille conceptuelle ; observation de la valeur des attributs sélectionnés par cette grille (c'est cette observation qui procurera les « données ») ; enfin interprétation de ces données en s'appuyant notamment sur l'analyse des corrélations, et aussi sur les apports de l'expérience et de la théorie.
L'entreprise observe ainsi les faits dont la connaissance est utile à son action : investissement, production et distribution, relation avec les clients, fournisseurs et partenaires, positionnement concurrentiel, etc.
Dans l'immensité du monde qui l'entoure, et aussi dans la complexité de son monde interne, l'entreprise choisit donc diverses « populations » qu'elle va observer : ses clients, ses agents, ses équipements, ses établissements, les entités de son organisation, ses logiciels, ses méthodes, ses produits, ses concurrents, les factures, les rubriques de la comptabilité, etc.
L'entreprise va aussi choisir les attributs qu'elle observe sur chacun des « individus » d'une population. Chaque individu possède a priori une infinité d'attributs (que l'on pense à un être humain : son poids, sa taille, le nombre de ses cheveux, la couleur de ses yeux, etc.) : l'entreprise ne retiendra que ceux qui lui importent (il faut que leur liste puisse être mise à jour si la situation change).
De leur observation résultent les données inscrites dans le système d'information. Deux obstacles se présentent alors :
Le désordre lorsque chaque direction, chaque usine, chaque partenaire classe, code et nomme les données à sa façon. Synonymes et homonymes abondent alors, et avec les homonymes on ne peut plus savoir quel fait précis désigne une donnée. L'inefficacité : le désordre des données altère le processus de production en provoquant des malentendus sources d'erreur.
Le traitement des séries chronologiques, l'estimation des données manquantes, la présentation et l'interprétation des tableaux de bord, etc., nécessitent des compétences en statistique et en économie que la plupart des entreprises, même les plus grandes, ne possèdent pas souvent.
Le problème est particulièrement sévère lorsque le processus, dit alors « transverse », traverse les frontières entre plusieurs directions ou avec divers partenaires : l'« interopérabilité » d'un processus exige que la cohérence des définitions et observations soit assurée pour chacune des données qui alimentent son flux, ce qui nécessite des négociations difficiles.
Nommer, identifier, observer
Chaque « population » doit être nommée, chaque individu doit être identifié, chaque donnée résulte d'une observation : c'est tout simple en apparence mais compliqué en pratique.
La population des « clients » va être parfois nommée « client », « usager », « assuré », « consommateur », « utilisateur », « bénéficiaire », « passager », etc. : on mentionne alors dans le nom de cette population la relation que l'entreprise a ou veut avoir avec elle. Cela ne facilite pas la communication dans une entreprise qui pratique plusieurs métiers.
Les entreprises sont fréquemment tentées de se focaliser sur leurs équipements et procédures, ce qui entraîne dans la définition des êtres observés des erreurs qu'il est ensuite difficile de corriger. Les opérateurs télécoms ont identifié ainsi le client par le numéro de sa ligne téléphonique, c'est-à-dire qu'en fait ils ne l'identifiaient pas. Les banques l'ont identifié par le numéro de son compte, le RIB. Les transporteurs aériens ont identifié le passager, qu'ils connaissent pendant la durée d'un vol, et non le client qui fait plusieurs voyages (seuls peuvent être alors suivis les clients des « programmes de fidélité »).
À chaque individu l'entreprise doit associer un identifiant : pour une personne physique « nom et prénom » serait un identifiant de mauvaise qualité car les homonymes sont nombreux. La pratique montre que l'identifiant doit être composé d'une suite de chiffres et de lettres tirés au hasard en évitant les doublons : il ne faut pas introduire d'attribut dans l'identifiant, ni composer l'identifiant à partir des attributs comme le prétend la théorie des bases de données relationnelles, car il faudra modifier l'identifiant si la valeur d'un attribut change (et rien ne garantit que ne surviendra pas dans le futur un individu qui posséderait le même multiplet d'attributs qu'un autre).
Pertinence et pratique de l'abstraction
Qu'est-ce qui guide le choix des populations à observer et des attributs que l'on observe sur chaque individu ? C'est la relation que l'entreprise a ou veut avoir avec ces individus, c'est l'action qu'elle entend avoir sur eux.
Les intentions de l'entreprise, qui orientent son action, déterminent ainsi en même temps le choix des populations et des attributs qu'elle va observer. La construction d'un référentiel (définition des populations et des attributs) doit donc partir des questions « que voulons-nous faire ? » (et, plus profondément, « que voulons-nous être ? »), puis « comment voulons-nous le faire ? ».
Choisir les populations et les attributs que l'entreprise va observer, c'est choisir du même coup ceux qu'elle n'observera pas : l'informatisation s'appuie sur une abstraction, représentation sélective et simplifiée du monde qui répond aux exigences de l'action.
L'informaticien est donc un praticien de l'abstraction. Cependant dans l'opinion commune l'abstraction est supposée loin de la pratique, la production des abstractions est réservée aux Grands Savants. La pratique de l'abstraction rencontre donc naturellement une incompréhension générale, source de certaines des difficultés que l'informaticien rencontre dans ses relations avec les spécialités que rassemble l'entreprise.
Certains informaticiens sont malheureusement tentés de considérer les données comme du « charbon », matière première indifférenciée que l'on traite en masse sans se soucier de son contenu. Cette attitude est implicite lorsque l'on dit que les données sont « un nouveau pétrole », l'expression « data lake » implique la même connotation.
Diversité
L'entreprise pratique plusieurs métiers qui ont chacun leur action propre : dans le cas d'une banque on peut énumérer gestion d'actifs, gestion des comptes, assurances, trading, etc. Chacun de ces métiers se découpe encore en métiers de moindre ampleur.
Il en résulte que l'entreprise n'a pas une action à partir de laquelle elle pourrait choisir les populations et les attributs, mais plusieurs. Sur un même individu chaque métier va observer quelques attributs, certains attributs seront observés par plusieurs métiers.
Si les métiers sont organisés en silos étanches chacun va définir à sa façon les populations et les attributs, chacun va identifier à sa façon les individus. Il en résulte des obstacles : dans certaines entreprises la nomenclature des produits et des pièces détachées diffère d'une usine à l'autre, ce qui ne facilite ni la production, ni la relation avec les clients.
Enfin ceux des attributs qui sont observés par plusieurs métiers recevront souvent des noms différents. Les synonymes gênent la communication mais on peut à la rigueur savoir les traduire. Les homonymes par contre sont destructeurs car on croit parler de la même chose alors que ce n'est pas le cas : le malentendu peut durer pendant des réunions entières et plus encore, puis s'incarner dans des logiciels...
La définition des populations, attributs et données est déposée dans un texte, le « référentiel », qui comme son nom l'indique sert de référence au système d'information sous forme de document et aussi d'outil informatique apte à alimenter des automatismes.
Pour mettre au point le référentiel d'une entreprise existante il faut commencer par construire un dictionnaire qui recueille tous les usages, puis faire la chasse aux synonymes et, surtout, aux homonymes. Il faudra souvent faire appel à l'autorité du dirigeant pour convaincre les métiers d'adopter un vocabulaire commun car chacun chérit des habitudes auxquelles il associe le particularisme de sa spécialité et l'idée qu'il se fait de sa légitimité.
Origine des données
Chaque donnée résulte de l'observation de la valeur d'un attribut sur un individu à une certaine date ou période. À chaque population, à chaque attribut, le référentiel associe un concept.
Un concept, c'est une idée à laquelle s'ajoute une définition : l'image d'un « rond régulier » est une idée qui permet de reconnaître un cercle quand on le voit, mais seule sa définition (« lieu des points d'un plan équidistants d'un point donné ») permet de raisonner sur le cercle.
Chaque donnée est donc un être hybride résultant de la rencontre d'un concept et d'un individu, puis de l'action volontaire de l'entreprise qui observe cette rencontre.
L'action s'appuie toujours sur une grille conceptuelle : lorsque vous conduisez votre voiture, votre cerveau sélectionne dans les images qui s'affichent sur votre rétine cela seul qui est nécessaire à la conduite et ignore les détails (physionomie des passants, ornements de l'architecture) qui pourraient le distraire. L'ensemble des grilles conceptuelles dont chacun dispose délimite un « petit monde », découpé dans le « grand monde » du réel.
Dans une entreprise le système d'information définit la grille conceptuelle de l'action productive et délimite ainsi le « petit monde » dans lequel il arrive que toute l'action d'un individu puisse s'enfermer. Le monde réel existe cependant, et se manifeste par des phénomènes qui semblent incompréhensibles, des incidents imprévus, des événements qui transforment la situation, etc. Si chacun vit dans son « petit monde », il faut être conscient de l'existence du « grand monde » et attentif aux surprises qui peuvent en provenir.
Critères de qualité
L'exigence de qualité varie selon la nature des données. Les identifiants nécessitent le plus grand soin : un identifiant erroné, c'est un dossier perdu, une affaire ratée, un client ignoré, etc. L'exigence d'exactitude est ici liée à celle de la précision : aucune erreur n'est tolérable. Il en est de même pour les « données de référence » : le taux de la TVA ne tolère aucune approximation, les nomenclatures doivent être à jour, etc.
Le résultat d'une observation est une donnée quantitative (longueur d'une distance, délai d'une action, volume ou masse d'un bien, densité d'un gaz ou d'un liquide, âge ou revenu annuel d'une personne, date d'un événement, etc.), une donnée qualitative (département de résidence, sexe ou métier d'une personne, entité d'une organisation, etc.) ou une donnée qualitative ordinale (tranche de revenu, tranche d'âge, etc.).
Le critère de qualité d'une donnée quantitative est l'exactitude, c'est-à-dire la capacité à alimenter un raisonnement exact et une décision judicieuse. L'exactitude n'est pas la même chose que la précision car un ordre de grandeur peut souvent suffire. La précision peut d'ailleurs être fallacieuse : mesurer la taille d'un être humain au micron près, c'est ignorer que le corps humain est élastique, ce qui risque de faire croire qu'il a la même consistance qu'une barre d'acier à température constante.
Le critère de qualité d'une donnée qualitative est là encore l'exactitude, car une erreur de classement peut avoir des conséquences. Il faut aussi considérer la nomenclature qui définit les rubriques selon lesquelles on classera les individus.
Il arrive qu'une nomenclature soit utilisée dans des situations auxquelles elle ne correspond pas, avec la conséquence que les données qualitatives risquent de ne pas être pertinentes : c'est ce qui se passe lorsque l'on impose une même nomenclature à des situations diverses, ou que l'on conserve une nomenclature tandis que la situation a changé [3].
Les architectes du système d'information doivent faire en sorte que les évolutions des données de référence soient répliquées sans délai dans les applications : si un programmeur transcrit « en dur » la version actuelle d'une nomenclature sans se soucier de sa tenue à jour, l'application passera les tests mais des problèmes surviendront par la suite.
La qualité des données observées dépend de la pertinence du concept et de l'exactitude de l'observation. Les données calculées sont obtenues en appliquant un algorithme aux données observées : leur qualité dépend donc et de la qualité des observations, et de celle de l'algorithme. Il arrive que celui-ci doive surmonter des différences conceptuelles. Il n'est pas facile par exemple de produire des indicateurs à partir des bases de données opérationnelles pour construire des séries chronologiques : calculer des totaux mensuels à partir de données hebdomadaires suppose une estimation, et il en est de même chaque fois que les nomenclatures ne s'emboîtent pas exactement.
Pour désigner un concept on utilise un nom et parfois aussi un adjectif. L'action que les données alimentent (les « use cases ») sera désignée, elle, par un verbe : l'ingénierie des processus associe donc la sémantique des données, que nous venons de considérer, à l'ingénierie de l'action productive.
L'informatisation du processus de production
Pour élaborer un produit l'action de l'entreprise doit enchaîner une succession de tâches qui, chacune, ont reçu d'une tâche antérieure un produit intermédiaire qu'elles transforment pour le pousser vers une tâche ultérieure. L'enchaînement de ces tâches, c'est le processus de production. L'action productive de l'entreprise se concrétise donc dans les processus qui aboutissent à ses produits.
Les tâches réalisées pour produire sont soit mentales (perception, jugement, décision) soit physiques (fabriquer quelque chose, livrer le produit à un client, réaliser une opération de maintenance), les tâches mentales préparant et accompagnant les tâches physiques. On appelle « activité » l'ensemble des tâches réalisées par un même acteur lors d'une étape du déroulement du processus.
Pour identifier les activités qu'il enchaîne et l'ordre de leur succession, il faut partir du produit auquel il aboutit puis remonter vers l'amont le cours du processus et de ses affluents (« sous-processus ») jusqu'à l'événement qui l'a amorcé (commande d'un client, alimentation d'un stock, plan de production, etc.).
Le système d'information d'une entreprise se définit donc à partir des processus de production qu'il lui faut formaliser afin de réaliser le programme informatique qui effectuera automatiquement les opérations suivantes :
présenter aux agents les interfaces nécessaires à chaque activité (regrouper sur un écran les plages de consultation et de saisie leur évitera de se connecter, déconnecter, reconnecter à de multiples applications, de faire des doubles saisies, de naviguer dans des codes et touches de fonction divers, etc. [4]) ; router le message d'une activité à la suivante (lorsque l'agent tape sur la touche « valider » à la fin de son travail, il ne doit pas avoir à chercher à qui envoyer le résultat : le programme est équipé de tables d'adressage et assure automatiquement le routage) ; surveiller le délai de réalisation d'une activité : en cas de dépassement l'agent est prévenu par une alarme, ou bien le dossier est expédié vers un autre agent ; produire les indicateurs (délais de réalisation, volumes traités, utilisation des ressources, satisfaction du client) qui alimenteront le manager du processus et lui permettront de vérifier la bonne utilisation des ressources humaines et matérielles.
Modéliser un processus, c'est décrire la succession des activités et le contenu de chacune : ce que fait chaque agent, les données qu'il manipule, les traitements qu'il ordonne, les délais dans lesquels son travail doit être exécuté ; c'est aussi décrire le routage des messages entre les activités ainsi que les compteurs qui permettront au manager de contrôler la qualité du processus.
L'exécution des tâches nécessite souvent des actions qui ne peuvent être réalisées que par un être humain et échappent donc à l'ordinateur même si celui-ci aide leur préparation : comprendre ce qu'a voulu dire un client, répondre à un événement imprévu, etc. Le processus relève donc de l'« assisté par ordinateur » et non de l'automatisation intégrale : il aide l'agent sans se substituer à lui, tout en automatisant les tâches répétitives qu'il devait faire à la main avant l'informatisation.
Un processus peut se décrire sous la forme d'un graphe : les nœuds représentent les activités, les arcs représentent le trajet des messages émis à la fin d'une activité pour lancer l'activité suivante.
Il est commode de donner à ce graphe une forme circulaire, les sous-processus étant représentés par des cercles secondaires branchés sur le cercle principal (Peter Keen [5]) : cette représentation souligne que le processus est déclenché par un événement provenant de l'extérieur (réception d'une commande, d'une lettre de réclamation, franchissement d'un délai de maintenance, etc.) auquel il répond par un autre événement émis vers l'extérieur (livraison, lettre, opération de maintenance, etc.).
Le rôle du processus, c'est de réaliser l'ensemble des tâches qui concourent à l'élaboration de cette réponse et constituent l'acte de production. Il convient de s'assurer que la réponse est émise dans un délai et sous la forme convenable, qu'elle est de bonne qualité et satisfait le client : c'est le contrôle du bouclage du processus.
Maîtrise d'ouvrage et maîtrise d'œuvre
On dit que la DSI d'une entreprise est « maître d'œuvre » du système d'information tandis que les directions utilisatrices (« clients » de la DSI) en sont les « maîtres d'ouvrage ».
Dans le langage courant les mots « œuvre » et « ouvrage » sont à peu près synonymes. Il n'en est pas de même dans les expressions « maître d'ouvrage » et « maître d'œuvre », où se retrouve leur sens d'origine que voici :
Ainsi chaque entreprise, et chaque métier dans l'entreprise, est à la fois maître d'œuvre de ses produits et maître d'ouvrage de ses processus de production.
Le métier est donc maître d'ouvrage du système d'information qui équipe ses processus. Il doit en spécifier les fonctions en rédigeant une « expression de besoin » qui décrit ce que le métier veut faire en s'appuyant sur la ressource informatique.
La DSI est maître d'œuvre du système d'information car c'est elle qui le produit, conformément aux spécifications qu'a fournies le maître d'ouvrage et à l'état de l'art de l'informatique, en trouvant les solutions qui permettront de satisfaire les besoins du métier (NB : la DSI est elle-même maître d'ouvrage de ses processus de production).
La relation entre le maître d'ouvrage et le maître d'œuvre ou, autrement dit, entre les métiers et l'informatique, est une dialectique. Bien que les rôles soient en principe clairement délimités les compétences se chevauchent : certains informaticiens connaissent ou croient connaître le métier, certains agents du métier connaissent ou croient connaître l'informatique. Il en résulte un dialogue parfois constructif et parfois confus.
Lorsque les métiers sont dupes de l'apparente simplicité de l'informatique, telle qu'elle apparaît sur l'écran de l'ordinateur ou du smartphone, il arrive que leurs exigences en termes de délai de réalisation, de coût et de performance soient démesurées. Il arrive aussi que les informaticiens, focalisés sur l'architecture de la plateforme informatique, accordent plus d'importance à leur technique qu'aux besoins des métiers, qu'ils ne savent pas entendre.
Enfin chacun vit dans la sociologie de sa profession, qui définit des règles que personne ne peut enfreindre sans risquer sa réputation : tandis que seules certaines actions sont jugées sérieuses et légitimes, d'autres rencontrent une résistance. Les métiers et l'informatique sortant difficilement du cercle de leurs habitudes, besoins et solutions sont souvent rétrogrades.
La dialectique de la maîtrise d'ouvrage et de la maîtrise d'œuvre est donc une relation organique et vivante : elle anime et propulse l'entreprise, non sans incidents et retours en arrière, mais poussée vers l'avant par le ressort que l'informatisation procure à l'action productive.
Des besoins au projet
« L'optimisation prématurée est la source de tous les maux. » [6].
On dit parfois qu'il faut satisfaire la demande des utilisateurs du système d'information et que les spécifications fonctionnelles doivent donc être écrites sous leur dictée. Mais leur demande ne correspond pas nécessairement à leur besoin car elle exprime ce que ces utilisateurs croient possible, normal et souhaitable. C'est comme lorsque l'on fait construire sa maison : la conversation avec un architecte est nécessaire pour prendre conscience de ce que l'on veut vraiment, et de ce qui est vraiment possible.
L'expression de besoins comporte cinq étapes dont les deux premières relèvent de la maîtrise d'ouvrage :
La première expression, dite « informelle », doit être compréhensible à la lecture par tous et notamment par les dirigeants. Ces derniers doivent pouvoir s'assurer qu'elle correspond aux priorités et à la stratégie de l'entreprise : sans une telle validation, on risque leur désaveu au cours du travail.
Il est utile de consulter des experts parmi les agents du terrain et les organisateurs. Les premiers indiquent comment les choses se passent en pratique, les organisateurs indiquent comment les choses devront se passer pour éviter des erreurs concernant le positionnement et les orientations de l'entreprise.
La consultation des experts, les entretiens, les séances de validation, la rédaction et la vérification des comptes rendus représentent une tâche matérielle considérable. L'expression des besoins peut échouer, en qualité ou en délai, si la logistique des recueils d'expertise, consultations et validations n'est pas convenablement organisée. Il ne faut pas sous estimer l'effort nécessaire pour obtenir que des personnes compétentes se rendent disponibles, pour s'assurer de leur ponctualité et de leur assiduité, pour rédiger de façon claire des comptes rendus qui portent parfois sur des questions complexes. On établit ensuite une expression dite « formalisée » en utilisant un langage de modélisation comme UML (Unified Modeling Language [7]) : le « diagramme d'activité » procure sur le processus une vue qui peut être comprise et partagée par tous les participants.
La formalisation fait alors apparaître des ambiguïtés et imprécisions qui sont inévitables dans la première version du modèle informel : on les corrige et la modélisation progresse jusqu'à convergence des versions formelle et informelle.
Avant la livraison du modèle à la maîtrise d'œuvre, le modèle informel doit être validé par les dirigeants. Il faut présenter à ces derniers un texte rédigé en français et illustré par des graphiques sur lequel ils puissent exercer leur jugement, de sorte qu'ils ne risquent pas de revenir plus tard sur leur validation (la modification des priorités en cours de réalisation peut être catastrophique). Les compléments techniques éventuels sont à mettre dans des annexes que les dirigeants consulteront s'ils éprouvent le besoin d'aller au détail, mais sur lesquelles il ne leur est pas demandé d'apposer leur signature.
Le livrable fourni alors par la maîtrise d'ouvrage à la maîtrise d'œuvre s'appelle « modèle métier » ou encore « spécifications générales ». Le maître d'œuvre doit se l'approprier : il peut ainsi relever des points obscurs, et alors on entre dans un cycle de remarques adressées au maître d'ouvrage et auxquelles celui-ci doit répondre en précisant et adaptant le modèle métier.
À la fin de ce cycle, on dispose d'un modèle métier stabilisé, compris par les parties, et qui servira de fondement à la réalisation [8]).
Un « modèle d'analyse » (ou « spécifications détaillées ») est rédigé par le maître d'œuvre afin d'apporter au modèle métier des précisions techniques (cardinalité des liens, définition des classes, etc.) en vue d'une réalisation efficace. Il doit être validé par la maîtrise d'ouvrage et sera ensuite le modèle sur lequel fournisseur et client se seront mis d'accord, et qui servira de charte à la réalisation. Un « modèle technique » (ou « spécifications techniques ») sera fourni aux développeurs pour la réalisation. Il n'a pas en principe à être validé par le maître d'ouvrage.
Pour comprendre le sens de la succession de ces modèles, supposons que vous fassiez construire une maison dont vous avez établi le plan d'ensemble avec l'aide d'un architecte. Vous dites : « dans cette chambre, il faut quatre prises de courant, un interrupteur commandant une prise et un éclairage commandé par un autre interrupteur ». Ce sont vos spécifications générales.
L'électricien vous demande de dire où il faut installer les prises, les interrupteurs et l'éclairage. Marquer sur le plan ces emplacements précis, c'est établir les spécifications détaillées.
Puis l'électricien fera le plan de câblage qui détermine le parcours des goulottes et saignées. Ce sont les spécifications techniques : elles ne vous concernent pas (mais l'électricien demandera peut-être votre accord pour l'emplacement de l'armoire de raccordement).
Toute modélisation doit parcourir ces cinq étapes et être conduite de sorte que l'on n'ait le moins possible à mettre en cause les choix opérés lors des étapes précédentes. Le modèle ainsi construit doit posséder trois qualités : cohérence, pertinence, sobriété.
cohérence : un modèle est incohérent s'il exprime un choix dans une de ses parties et un choix contraire dans une autre, violant ainsi la logique. Cela provoquera des impossibilités lors de la réalisation et de l'utilisation ; pertinence : le modèle doit répondre exactement aux besoins de l'entreprise et non aux exigences de la mode, des habitudes, du cloisonnement des métiers, de la sociologie des pouvoirs, etc. Il faut pour y parvenir avoir su répondre à la question « que voulons-nous faire » ; sobriété : plus un logiciel est compliqué, plus sa maintenance sera difficile. Il faut donc n'automatiser que ce qui peut et doit l'être, ne confier à l'informatique que le gros du travail répétitif et laisser à l'agent humain les tâches qui exigent du discernement.
Une fois le modèle technique élaboré, on entre dans la phase de réalisation (développement) qui sera suivie du déploiement, de la formation des utilisateurs, etc.
Signalons quelques pièges :
Sous-estimer la difficulté de la logistique de consultation et de validation auprès des experts du métier : les rendez-vous sont difficiles à obtenir, les personnes ne sont pas assidues, elles ne se sentent pas autorisées à donner un avis si leur mandat n'est pas clair, elles sont désavouées après l'avoir donné, etc. Les délais peuvent alors s'allonger et la qualité de l'expression des besoins peut être douteuse. On présente aux dirigeants des documents d'une lourde technicité qui ne correspondent ni à leur langage, ni à leurs préoccupations. La validation prend alors beaucoup de temps ou bien elle est superficielle et risque d'être remise en cause par la suite, car un dirigeant ne doit pas tolérer que la réalisation ne soit pas conforme à la stratégie de l'entreprise. On prend en compte les contraintes techniques de façon trop précoce : l'« optimisation prématurée » consiste par exemple à se soucier des spécifications détaillées ou même des spécifications techniques alors que les spécifications générales n'ont pas été clairement définies : cette tentation est comme l'a dit Donald Knuth « la source de tous les maux ». (Il peut arriver que sous prétexte de « sérieux » et de « rigueur » on prétende imposer au métier des règles de modélisation anticipant les choix à réaliser dans le modèle d'analyse ou le modèle technique. Des choix trop précoces devront alors être révisés par le maître d'œuvre d'où confusion, travail en double et perte de temps.) On instaure de fait une cloison étanche entre maîtrise d'ouvrage et maîtrise d'œuvre : même si la maîtrise d'œuvre n'est pas responsable du modèle métier, il est utile que le maître d'ouvrage la consulte pour s'assurer de la faisabilité de ce qu'il envisage ; et même si le modèle technique ne concerne pas le maître d'ouvrage, il est utile qu'il soit informé de choix qui ont pour lui des conséquences en termes de performance, fiabilité, sécurité, etc. : la spécialisation des rôles ne doit pas exclure la collaboration.
Du projet à la solution
Une fois le modèle au point, il faut passer à la réalisation. La « méthodologie » de la gestion de projet [9] a fait l'objet de nombreux travaux, notamment ceux qui ont abouti au PMBOK, « Project Management Body of Knowledge » [10]. Nous donnerons ici les quelques indications qui nous semblent les plus importantes.
Pour s'assurer que les performances du produit seront convenables un « cahier de tests » devra être rédigé au début de la réalisation, chaque test devant simuler de façon réaliste une sélection jugée représentative des situations et des opérations.
Si le modèle technique indique ce qu'il faut faire, il ne précise pas comment le faire. La réalisation va donc devoir régler des questions pratiques et surmonter les difficultés que la physique et la logique lui opposent, difficultés souvent imprévues et qui vont solliciter l'ingéniosité des informaticiens.
On découvre par exemple que les données présentent des défauts qu'il faut corriger, ce qui nécessite de négocier avec les métiers concernés ; que la volumétrie est telle qu'il sera impossible d'atteindre une performance acceptable, ce qui peut nécessiter de découper la base de données avec tous les inconvénients qui en résultent ; que les utilisateurs refusent l'ergonomie de l'interface qui leur est proposée ; que les délais de la réalisation s'allongent démesurément ; que le logiciel présente des bogues qui altèrent sa qualité, etc.
Pour résoudre chacune de ces difficultés l'informaticien doit se plonger dans l'intimité de la technique des logiciels, processeurs et réseaux. L'expérience montre que chacun risque, étant accaparé par une tâche spéciale et difficile, de perdre de vue le but et le sens de l'ensemble du projet. Des conflits naissent alors entre les spécialités, chacune se jugeant gênée par les décisions des autres. L'expression informelle du besoin, texte court, clair et dûment validé, fournit utilement tout au long du projet la référence qui permet de retrouver à quoi sert ce que l'on fait et de restaurer un esprit de coopération.
Certains projets, lourds et complexes, demandent plusieurs années. Lorsque le produit sera enfin livré, ne risque-t-il pas d'être refusé par les utilisateurs car la situation a changé ? Pour éviter ce danger il faut découper le projet en lots exploitables, réalisations partielles mises en service progressivement et dont l'utilisation apportera des enseignements. Les méthodes agiles1, mises en œuvre par de petites équipes qui réunissent un représentant de la maîtrise d'ouvrage à une unité opérationnelle de la maîtrise d'œuvre, ont pour objectif de contribuer à cette démarche. Elles permettent de faire des expériences tôt, ce qui fera éventuellement constater que les idées initiales n'étaient pas les bonnes et qu'il convient de les corriger.
La réalisation des tests fera apparaître des anomalies qu'il faut corriger. Lorsque le logiciel est trop complexe il arrive que la correction d'une anomalie suscite d'autres anomalies : alors le nombre des anomalies ne décroît pas, symptôme pathologique qui annonce un échec du projet.
Selon les enquêtes du Standish Group 25 % des projets informatiques aboutissent dans le délai et le budget prévus, 50 % souffrent de dépassements de l'ordre d'une multiplication par trois, 25 % échouent complètement. L'allongement répété du délai de livraison des lots et l'accumulation des anomalies sont des symptômes qui doivent alerter l'entreprise et l'inciter à réviser sa démarche.
Quelques utilisateurs futurs de la solution, nommés « experts métier », sont associés au projet et participent à la définition des fonctionnalités, aux tests et à l'évaluation de l'ergonomie : la solution leur est donc familière mais les autres utilisateurs, qui n'ont pas partagé cette expérience, ne la connaissent pas. Il faudra les former pour qu'ils sachent utiliser ses instruments.
Dans une entreprise qui emploie quelques milliers ou dizaines de milliers de personnes l'organisation des sessions de formation requiert une préparation lourde : la maîtrise d'ouvrage devra préparer les exposés et démonstrations, réserver des salles de réunion et des chambres dans des hôtels, s'assurer de la ponctualité des participants, etc.
Dans certaines entreprises projets et nouveautés se succèdent à une cadence si rapide que les utilisateurs protestent : à peine ont-ils assimilé une formation, ils doivent en subir une autre. Le rythme de l'innovation doit donc être raisonnable.
La plate-forme de l'informatique
Un système d'information ne pourrait pas fonctionner s'il n'était pas soutenu par la plate-forme matérielle et logicielle de l'informatique.
On pourrait croire que le logiciel est logique, car il appartient au monde de la pensée alors que la matière dont sont faits les processeurs, mémoires et réseaux est soumise aux aléas du monde de la nature (transformation de la structure cristalline, effets du rayonnement cosmique, etc.). Mais les logiciels qu'une DSI achète à des fournisseurs (systèmes d'exploitation, « progiciels », ERP, CRM, etc.) ne sont pas vraiment des « êtres logiques » : la plupart sont un assemblage de « boîtes noires » dont on ne connaît que les interfaces d'entrée et de sortie (les « API ») et qui ont été collées ensemble par une « glu » de code.
Si le logiciel est un produit de la pensée, il s'agit donc en fait d'une pensée en cascade dont la connaissance et la compréhension ne se transmettent pas d'une étape à l'autre : cela le rend aussi énigmatique qu'un être naturel.
Le fournisseur d'un progiciel teste le produit ainsi fabriqué pour s'assurer qu'il répond bien à quelques situations type, rédige une documentation pour les utilisateurs, organise des formations puis commercialise l'ensemble que forment le logiciel, la documentation et la formation. La vraie vie étant plus complexe qu'une liste de situations type, les DSI qui ont acheté le logiciel découvrent parfois qu'il ne fonctionne pas bien alors même que l'on suit la documentation à la lettre : il a des « bogues ».
Le fournisseur ouvre alors un « forum » pour accueillir les questions des utilisateurs. Il y publie des réponses qui sont autant de rustines qu'il faudra ajouter au logiciel et dont certaines plongent dans les profondeurs du compilateur, du système d'exploitation ou même du matériel. Progressivement, ce forum contiendra la réponse à la plupart des bogues qui se rencontrent en pratique, mais non à toutes celles que l'on peut rencontrer. Les rustines efficaces pour une version du logiciel ne le seront pas pour les suivantes, qui arrivent tous les trois à cinq ans. Il faut alors recommencer : des questions sont de nouveau posées sur un forum, les réponses sont autant de nouvelles rustines.
Une DSI renouvelle par ailleurs son matériel tous les cinq ans environ car une machine qui a huit ans d'âge n'est plus suivie par le constructeur : il a fermé les services de maintenance et de support. Dans ce changement de machine, nombre des rustines ajoutées aux logiciels deviennent inopérantes et il faut les remplacer par d'autres.
Les informaticiens s'épuisent ainsi, sous la pression des utilisateurs, à faire fonctionner des machines qui deviennent instables, des logiciels bogués, en utilisant des rustines dont l'empilement est de plus en plus complexe. Leur métier qui, vu de loin, semble relever de la logique pure, est ainsi soumis à une démarche empirique.
Certes, une DSI peut limiter les dégâts en se dotant d'une infrastructure aussi stable que possible et en sélectionnant les logiciels selon la qualité et le sérieux des fournisseurs : cela demande un investissement dont la direction générale ne voit pas l'utilité mais plutôt le coût. Si l'informatique du chercheur est une science, celle de l'ingénieur est un art comme la médecine du généraliste : pour l'exercer il faut des bases scientifiques mais l'expérience est irremplaçable. Un DSI doit savoir trouver les bons ingénieurs, les faire travailler ensemble, leur donner envie de rester dans l'entreprise. S'il n'y parvient pas le reste sera voué à l'échec.
Michel Volle
Paru le 18 novembre 2023 sur volle.com.
http://michelvolle.blogspot.com/2023/11/le-systeme-dinformation.html
Cet article est sous licence Creative Commons Attribution 4.0 International.
https://creativecommons.org/licenses/by/4.0/deed.fr
NOTES
[1] « On espère que dans quelques années le cerveau humain et l'ordinateur seront associés si étroitement que le partenariat qui en résultera pourra penser comme aucun cerveau humain n'a jamais pensé, et traiter des données d'une façon hors d'atteinte des machines de traitement de l'information que nous connaissons aujourd'hui. » (Joseph Licklider. Man Computer Symbiosis, IRE Transactions on Human Factors in Electronics , mars 1960, p. 4-11).
[2] L'exécution de certains programmes demanderait une durée supérieure à l'âge de l'univers....
[3] Isabelle Boydens, Informatique, normes et temps, Bruylant, 1999.
[4] Ces interfaces cruciales pour l'interaction homme-machine sont trop souvent mal construites.
[5] Peter Keen, Shaping the Future, Business Design Through Information Technology, Harvard Business School, 1991.
[6] Donald E. Knuth, TEX : The Program, Addison-Wesley (Vuibert pour la traduction française), 1986.
[7] Pascal Roques et Franck Vallée, UML en action, Eyrolles, 2003.
[8] La qualité des documents ainsi produits est cruciale : leur rédaction doit être claire et sobre.
[9] Wikipédia : Gestion de projet
[10] Wikipédia : Project Management Body of Knowledge.
|
