Remettre l’informatique au milieu du village !

En préambule il est bon de rappeler que l’informatique n’est pas une fin en soi et qu’elle ne peut pas apporter une « solution finie » à une problématique à l’image de la réponse d’une opération mathématique. En effet, l’environnement métier dans lequel elle se meut est tout sauf figé et ne se limite pas à une succession d’opérations mathématiques. Bien au contraire l’informatique est confrontée en permanence à des interactions avec un environnement mouvant qui ne peuvent pas et ne doivent pas être figées dans une pure codification logique, stricte et sans échappatoire – l’activité humaine qu’elle est sensée servir n’obéit pas toujours à un raisonnement rigoureux. En réalité il est judicieux de n’informatiser, dans le sens automatiser, que ce qui est maîtrisé, stable dont le périmètre est connu et qui est source de valeur, dans le cas contraire la manipulation humaine demeure plus efficace. Il n’en demeure pas moins qu’un processus automatisé doit être placé sous la supervision de l’être humain.
L’étude des fondements juridiques d’une organisation constituent un bon point de départ pour l’informatisation.
D’autre part l’informatique n’est d’aucune utilité pour résoudre un problème organisationnel, par contre avec la nécessité d’analyser finement tous les cas d’utilisation qu’elle impose, elle constitue un formidable révélateur des carences et des disfonctionnements organisationnels.
De surcroît il est illusoire de penser que l’introduction d’une application informatique va parfaitement coller aux besoins métiers sans adaptation ni perturbation, au contraire elle va inévitablement induire des bouleversements qu’il est préférable d’anticiper. L’informatisation se caractérise en réalité par une restriction du monde vivant.

Il ne faut pas se leurrer, l’informatique est une science complexe. Thierry Crouzet (Auteur des livres cultes "Le peuple des connecteurs" et du "5ème pouvoir") ingénieur et journaliste scientifique, donne une bonne image de cette complexité. Il s’agit du processeur qui équipe un ordinateur, un téléphone mobile, une machine à café ou tout autre automate. Pour les plus puissants ils contiennent 2 milliards de transistors (ce n’est pas encore la complexité du cerveau humain et de très loin mais l’évolution de sa puissance est très rapide). L’Homme maîtrise la construction du processeur, il sait comment il fonctionne et les opérations binaires de base qu’il effectue sont extrêmement simples pourtant il est incapable de garantir que les résultats calculés par ces machines soient toujours corrects. On sait que ces processeurs fonctionnent mais on ne peut pas certifier que tout fonctionne, il y aura toujours un certain nombre d’opérations pour lesquelles le résultat sera erroné. En d’autres termes, on sait faire mais on ne maîtrise pas la totalité de son champ de fonctionnement! Même si l’on arrive obtenir la carte complète, il y a tellement d’interactions possibles que l’on ne peut pas en mesurer toutes les conséquences.

L’informatique « free of bug » n’existe pas ! On estime que les logiciels embarqués de la NASA, qui sont parmi les mieux vérifiés, comportent encore en moyenne un défaut par 10'000 lignes de code source (Architecture logicielle – Jacques Printz). Par conséquent il est plus profitable de prévoir une alternative en cas de survenance d’un disfonctionnement que de mener une chasse éperdue aux bugs. Par contre quand une défaillance se produit il faut être en mesure de détecter le plus rapidement possible la cause afin d’apporter le correctif nécessaire d’où l’importance, pour une organisation, de maîtriser son informatique.
L’absence de compétences adéquates ou l’inexistence d’une analyse des risques et de leur mitigation peut se révéler lourd de conséquences. A ce titre deux étudiants dans le cadre de leur travail de diplôme avaient conçu une application dans un langage de programmation logique utilisé principalement dans les applications d’intelligence artificielle, le Prolog afin de gérer les processus de sécurité d’une centrale nucléaire. L’objectif était de remédier aux carences d’un ancien logiciel qui provoquait régulièrement de fausses alertes. Comme l’outil qu’ils avaient développé était prometteur les deux jeunes furent engagés par la société électrique qui gérait la centrale pour le mettre en production. Après quelques années de loyaux services et un logiciel qui fonctionnait à entière satisfaction les deux concepteurs, las de la routine, décidèrent de quitter leur employeur pour une nouvelle expérience professionnelle. Et comme souvent le transfert de connaissance n’avait pas été réalisé et qui plus est la maîtrise de ce langage de programmation n'étant pas très répandue la centrale nucléaire fut contrainte à l’arrêt.