Un système d'information est un être vivant : il naît, il évolue et se renouvelle, il connaît des incidents et des accidents, il se métamorphose même, mais il mourra le jour où l'institution qu'il sert disparaîtra – car aucune institution, aucune entreprise n'est éternelle.
Ses utilisateurs ne font que trois choses : ils lisent, ils écrivent et ils lancent des traitements. Il met à leur disposition quatre choses : des mémoires, des processeurs, des logiciels et un réseau. Vu comme cela, l'affaire peut sembler très simple...
Les langages
… mais dès que l'on a dit « les utilisateurs lisent et ils écrivent », cela implique toute la complexité de l’ingénierie et du langage.
Les utilisateurs conversent entre eux en utilisant le langage naturel, moyen de communication dont la puissance est gagée par une imprécision : tous les mots du langage naturel sont en effet entourés de connotations suggestives mais floues.
L'action technique, qui concerne des choses et des actions professionnelles, exige au contraire un langage précis, dépourvu de connotations et donc strictement conceptuel. Outre les connotations, elle bannit les synonymes et les homonymes qui sont autant de sources de malentendus.
La première étape de la construction d'un système d'information réside dans l'élaboration d'un langage conforme aux exigences du métier : il faut que toute l'entreprise, et même certains clients/partenaires dans le cas de l’entreprise « étendue », parle la même langue sans homonymes ni synonymes ; il faut que cette langue respecte des règles logiques formelles de complétude et de cohérence, indépendantes des opinions des usagers (« context-free ») ; il faut que les concepts qu'elle utilise soient pertinents (c'est-à-dire adéquats à l'action productive).
L'ingénierie du système d'information doit mobiliser la technique informatique de façon à satisfaire les besoins des utilisateurs (et non de répondre à leur demande, car celle-ci n'est le plus souvent qu'une traduction erronée du besoin).
Lorsque le système d'information utilise l'informatique, les données saisies et les ordres de traitement sont traduits en une cascade de langages intermédiaires avant de parvenir aux processeurs sous la forme d'instructions élémentaires écrites en 0 et 1 : le langage du processeur est celui des opérations physiques, qui n'est ni celui des êtres humains, ni celui de la logique pure.
Le modèle en couches
La vie du système d'information suppose donc le fonctionnement simultané de plusieurs langages ou, si l'on veut, de plusieurs logiques, et une cascade de traductions/interprétations entre ces langages.
Nota Bene : dire « simultané », c'est une approximation car chacune de ces traductions prend du temps. Pour un utilisateur qui travaille sur un micro-ordinateur ce délai est imperceptible dès qu’ils est inférieur à un dixième de seconde ; dans un système d'information qui sert plusieurs dizaines de milliers d'utilisateurs, ce délai peut provoquer des incidents : nous y reviendrons.
Chacune des logiques définit le langage et les actions utilisés dans une « couche » du système d'information. On nomme « modèle en couche » la représentation de l'ensemble de ces couches. Pour que le système d'information puisse fonctionner, il faut que chacune des couches fonctionne selon sa logique propre. On a donc affaire à un empilage de conditions simultanément nécessaires et c'est très exigeant : il suffit qu'une seule des couches tombe en panne pour que tout s'arrête.
Le modèle OSI distingue ainsi sept couches dans les télécoms : « physique, liaison, réseau, transport, session, présentation, application ». Le modèle TCP/IP de l'Internet, plus simple, distingue quatre couches : « physique, réseau, transport, services ».
Dans un ordinateur, on peut distinguer au minimum six couches de langages : code source, code objet, assembleur, système d'exploitation, microprogramme, physique du processeur enfin.
On nomme « protocole » le langage qui exprime les actions réalisées dans une couche et qui permet de coopérer aux entités qui appartiennent à cette couche (par exemple : faire coopérer plusieurs processeurs). On nomme « interface » la traduction entre langages qui permet de faire communiquer deux couches différentes (la « compilation », par exemple, traduit le code source en code objet).
La taille des systèmes d'information
Pour une grande banque dont l’informatisation a démarré dans les années 60 le patrimoine logiciel peut monter jusqu’à 300 millions de lignes de code source (LCS).
Nota Bene : à titre de comparaison, un système d'exploitation comme Windows ou Linux comporte de l'ordre de 30 millions de LCS.
Pour un grand ministère comme les Finances ou la Défense, informatisé de longue date, le patrimoine comprend de 150 à 200 millions de LCS.
Pour de grandes entreprises de création récente comme celles qui gèrent les réservations de billets d’avion, de train, d’hôtel, etc., les clients des opérateurs de téléphonie mobile ou le transport de l’énergie, le patrimoine comprend de 100 à 150 millions de LCS.
Un livre de 400 pages, à raison de 50 lignes par page, est l’équivalent d’un programme de 20 000 LCS. 100 millions de LCS équivalent donc à une bibliothèque de 5 000 volumes à laquelle il faut ajouter le mode d'emploi (référentiels système), les aides en ligne et les scénarios de test qui permettent de déclarer que la bibliothèque est « bonne pour le service » aux utilisateurs : cela revient à doubler sa taille.
Un programmeur produit en moyenne 4 000 LCS/an.100 millions de LCS représentent donc au minimum un coût de développement de 25 000 homme*année, et il en faut trois fois plus si l'on fait tout ce qu'il faut pour réussir.
On comprend pourquoi il est si difficile de faire évoluer un système d'information, même lorsqu'il est notoirement boiteux.
La supervision
Il ne faut pas supposer que l'automate va toujours fonctionner tout seul convenablement, de façon nominale : des incidents sont inévitables car tout système d'information est sujet à des pannes. Les logiciels présentent des défauts, les liaisons se rompent dans les réseaux, les mémoires se dégradent. En outre, il se peut que les demandes des utilisateurs outrepassent le dimensionnement des ressources : alors les mémoires tampon (buffers) débordent, les réseaux s'engorgent, etc.
On introduit donc dans les programmes des automatismes qui permettent de réagir à certains incidents pour assurer la sûreté de fonctionnement. Ces automatismes représentent un tiers du code d'un système d'exploitation, trois quart du code dans un commutateur du réseau télécoms : contrôle et redondance des données, répétition des messages, reprise automatique, fonctionnement en régime dégradé, etc.
Dans les réseaux télécoms, par exemple, des filtres bloquent un pourcentage des appels lorsque leur avalanche risque de saturer les commutateurs (après une émission de radio, après un accident qui a fait de nombreuses victimes...).
Ce dernier exemple montre que les incidents peuvent avoir pour cause non seulement une défaillance de l'informatique, mais aussi le comportement des utilisateurs lorsque leur demande cumulée outrepasse le dimensionnement des ressources.
Certaines des décisions nécessaires en cas d'incident supposent une action humaine : lancer une équipe de dépannage, bloquer ou réallouer certaines ressources pour soulager l'ensemble du système, rappeler à l'ordre certains utilisateurs, etc. Dans les systèmes d'information bien organisés des superviseurs sont installés dans un centre de supervision qui dispose d'outils d'observation permettant de surveiller le fonctionnement d'ensemble afin de percevoir et diagnostiquer les incidents, ainsi que de commandes qui permettent de lancer les mesures nécessaires à leur résolution. Le système de supervision du système d'information du réseau de transport de l’énergie, par exemple, est redondant pour des raisons de sécurité : il en existe trois exemplaires dont l'un est hébergé sous un « bunker ».
Le fait est que de trop nombreuses DSI, inconscientes des risques, négligent la supervision : elles font comme si le fonctionnement du système d'information devait obéir en permanence au régime nominal. C'est le cas par exemple avec le trading de haute fréquence, qui fonctionne délibérément trop vite pour qu'un être humain puisse le superviser : il en est résulté, il en résultera des catastrophes (dans ce cas c'est volontaire, et conçu pour pouvoir frauder en toute quiétude : cf. Jean-François Gayraud, Le nouveau capitalisme criminel, Odile Jacob, 2014).
Le parallélisme
Les grandes plates-formes informatiques supposent le fonctionnement simultané de plusieurs dizaines de milliers de processeurs ; par ailleurs les processeurs eux-mêmes deviennent « multi-cœurs » pour des raisons d'efficacité et pour limiter la consommation d'énergie. Des processeurs à 8 cœurs équipent en standard les SmartPhones et les tablettes de dernière génération.
Il en résulte une complexification importante des systèmes d'information. La supervision d'une plate-forme suppose une gestion statistique et dynamique des pannes, les données devant pouvoir se réallouer immédiatement : cela suppose une gestion avisée de la redondance.
L'exécution d'un programme découpé en plusieurs modules fonctionnant en parallèle exige de maîtriser des phénomènes d'asynchronisme et de communication qui présentent un caractère imprévisible : des appels vers une même base de données vivante, réalisés à des instants différents, apportent des données qui risquent d'être incohérentes si un protocole d’accès n’a pas été établi entre les utilisateurs, et alors l'exécution du programme fournira des résultats incohérents. Si le parallélisme n’est pas organisé à partir des données manipulées le diagnostic des pannes devient impossible, en particulier dans le contexte Big Data.
Les bonnes pratiques de la programmation séquentielle, celles que l’on a enseignées depuis 50 ans à des générations de programmeurs, sont devenues inopérantes ou même fausses dans le cas du parallélisme. La généralisation des architectures multi-coeurs est une vraie révolution car elle transforme les exigences auxquelles doit répondre le travail de plusieurs millions de programmeurs.
* *
Les artefacts que nous avons évoqués sont les plus complexes que l'homme ait imaginés et créés dans l'histoire de l'humanité. Personne ne peut les comprendre entièrement, mais chacun doit en posséder une certaine compréhension pour pouvoir penser et agir dans le monde contemporain. Acquérir cette compréhension passe par une initiation à la programmation.
Nous pouvons en conclusion retenir les idées suivantes :
- tout système d'information doit s'appuyer sur un langage conceptuel rigoureux et pertinent ;
- l'architecture, complexe, fait fonctionner ensemble des logiques différentes ;
- des pannes et incidents sont inévitables : il faut que les programmes sachent leur apporter une réponse automatique, complétée par la supervision qu'exercent des êtres humains ;
- l'évolution en cours vers le parallélisme exige une évolution profonde des méthodes de programmation ;
- le patrimoine d'un grand système d'information a coûté des dizaines de milliers d'homme*année de travail : il sera difficile de le faire évoluer ;
- il faut introduire un enseignement de l'informatique dans le secondaire ; ceux qui dirigent les institutions devront avoir reçu cet enseignement et avoir été formés à la gestion des systèmes d'information.
Aucun commentaire:
Enregistrer un commentaire