Une présentation hors sujet

Un premier mensonge est celui de l’achèvement. On présente un système non pas pour ce qu’il fait (ou ce qu’il fait mieux), mais par sa taille et l’effort financier ou humain. Les communications montrent des progrès hors finalité du programme : empreinte carbone, emploi, organisation, réglementation… 

Quand la présentation est difficile à comprendre, change de format tous les mois voire toutes les semaines, et ne propose pas autre chose qu’un effort accentué : danger ! Danger aussi quand le chef de projet, convaincu des bons résultats futurs, ignore le biais cognitif que cela peut entraîner.

Par exemple Eau-France présente en 64 planches l’avancement de la V.3.1.3, une livraison fin avril, une mise en production début juin, alors que les données ne sont pas encore accessibles : « Malgré un travail important effectué ces derniers mois pour garantir un fonctionnement optimal et la qualité des données présentées, nous attirons l’attention des utilisateurs sur le fait qu’il subsiste encore quelques dysfonctionnements dans la base de données qui l’alimente, qui peuvent altérer la qualité et la pertinence de certaines données. Les équipes du réseau travaillent activement pour résoudre etc. »

La langue absconse est utilisée d’autant plus facilement que l’objet du programme n’a même pas à être décrit ; un grand nombre de sigles, souvent inexpliqués, finissent de perdre le lecteur.

En un mot la communication sert à prouver le soin, mais ne montre pas l’avancement réel. Le secret est qu’il se passe énormément de choses sans que les chefs soient au courant. C’est peut-être nécessaire quand (ou car) les décideurs manquent de compétence technique, mais c’est dangereux de les laisser décider des choses qu’ils ne comprennent pas. 

Une fragilité intrinsèque

Les systèmes numériques, avec l’environnement qui les rend utiles, ne sont ni totalement fiables, ni figés, ni complets. Cela ne signifie pas un défaut, mais leur essence, et appelle des précautions constantes. Les composants sur lesquels on s’appuie sont bien sûr frappés de la même incertitude. C’est dangereux, mais nécessaire. Il y a 60 ans, la mode était aux thèses sur la démonstrabilité des logiciels, et les conclusions étaient toujours les mêmes : ce n’est pas possible dans les hypothèses préétablies ici, mais…

La fragilité, observée chaque jour ou presque, est rarement avouée : risques techniques d’arrêt momentané lors des mises à jour, exhaustivité incertaine (il reste toujours de petites incertitudes ou omissions).

La fragilité vient aussi d’erreurs parfois impossibles à observer. Le système de combat de la frégate Cassard avait été parfaitement simulé dans des scénarios les plus complexes ; lors d’un essai réel, les leurres pyrotechniques, au lieu d’être lentement éloignés sous le vent, sont partis au vent et sont retombés très près de l’hélicoptère stationné sur la plage arrière… la catastrophe a été évitée. L’erreur venait du réseau de distribution de l’information du vent, qui n’avait pas pu être vérifié. On ne peut pas tout démontrer. 

L’organisation

Bien faire passe par une bonne connaissance réciproque entre le maître d’ouvrage et l’industrie qui réalise… en sachant qu’un excès d’intimité peut conduire à la collusion, et donc à des arrangements visant à ne pas peiner l’autre. Dit autrement, comme on ne peut pas spécifier totalement, il faut s’entendre et se comprendre, presque entre amis. 

C’était un mérite du CPM, Centre de Programmation de la Marine, mêlant utilisateurs, développeurs et certificateurs, sorte d’État dans l’État. Bref ça marchait mais de façon incompatible avec les méthodes naissantes de construction de grands programmes numériques : on ferme ! Une question éternelle reste ouverte : à complexité égale, une organisation industrielle rigide ne conduit-elle pas à renchérir la complexité contractuelle et les prix ? 

Une cause d’incertitude est aussi que les compétences des équipes de réalisation sont morcelées dans une chaîne d’encadrement aux connaissances lacunaires et peu pérennes, où les jeunes, seuls au courant des dernières techniques, ont un fort turnover. A l’opposé, les ingénieurs indiens, au lieu de s’appuyer sur leur seul diplôme, trouvent naturelle une formation permanente forte.

Pas stabilisé

On ne sait jamais si les objectifs sont atteints, car on ne vérifie pas tout, et les systèmes en interface changent ; le tout est intrinsèquement évolutif. Le monde change, et un logiciel qui ne bouge plus est un logiciel mort.

La plupart du temps on s’appuie sur l’idée qu’il y a un aboutissement de la réalisation. C’est à peu près aussi étrange que de déclarer que les travaux de voirie et de révision du plan de circulation sont terminés à Paris. Espérons que les systèmes courants dont la complexité devient impressionnante, les téléphones et les voitures, resteront utilisables avec fiabilité dans leur état initial : rien n’est moins sûr. 

Les mises à jour sont inéluctables. 

Pas complet

La complexité de ce que doit faire un outil numérique cache toujours des zones oubliées. La simplification des logiciels de RH est ainsi impossible sans omettre des cas particuliers traités auparavant par le simple bon sens. Ainsi les permanences de 24h des réservistes ne peuvent pas s’étendre sur deux jours ; la prime d’activité des plongeurs comptée en journées au lieu d’heures fait perdre un avantage qu’il faut alors corriger. Bien sûr tout sera rectifié, mais au futur. Les arrangements à la limite du droit, qu’il s’agisse de RH ou des clauses complexes d’un marché, sont impossibles à intégrer.

L’optimisation sur seulement la majorité des cas peut satisfaire les dirigeants, et peut rendre des cas pires qu’auparavant, comme dans Parcours Sup.

L’utilisateur final n’est pas dans la boucle

Ou plutôt si, il est dans la boucle de la phase d’utilisation… et en souffre. Notre magazine en a déjà donné l’illustration, les exemples sont innombrables.

«cette première version est marquée par un alourdissement très important de la charge de travail des services, qu’accentuent le retard et les imperfections des outils informatiques.»

Alors, comment on fait ? 

Si le SCCOA a abouti, son homologue européen ACCS a souffert de la multiplicité des acteurs et personne ne peut dire réellement quand il a pu être mis en œuvre dans les 12 pays concernés. (On notera que conformément à une remarque ci-dessus, il n’est pas nécessaire de préciser ce qu’est le LOC1).

Les IA sont plus à l’aise sur des projets définis (guidés par le besoin) que sur des projets lancés pour créer du mouvement. Ils ont le droit de comprendre : qu’ils profitent de ce droit, trop souvent oublié ! Ils savent distinguer le développement agile, la mise au point laborieuse et l’adaptation à l’environnement qui change.

Que manque-t-il ? Pour éviter trop de distance entre le donneur d’ordre, les utilisateurs et le maître d’œuvre, une équipe intégrée ; pour éviter les drames, un langage à chaque fois adapté. 

Il est impossible de comprendre, développer, maintenir et savoir à qui faire confiance, sans amis. Le choix des équipes et des personnes est ici primordial.