Le développement du logiciel SIRHEN, qui devait assurer la gestion administrative des personnels de l’Education Nationale, vient d’être arrêté après 11 ans de développement et 320 millions d’euros de dépenses. La situation de ce logiciel est en tous points analogue à celle du logiciel Louvois, qui devait servir à gérer la paie des armées et qui a coûté plus de 470 millions d’euros avant que son développement n’ait été stoppé.

Les raisons d’un fiasco

Pour comprendre l’origine du fiasco, le mieux est de tenter d’additionner des nombres compris entre 1 et 100 000. Chaque addition est excessivement simple et vous pouvez la faire à la main. Si vous tentez à la main d’additionner des centaines de nombres, vous avez très peu de chances d’obtenir le même résultat que votre voisin – donc vous perdez confiance dans le résultat obtenu (comme les personnels des armées ont perdu confiance dans les feuilles de paie produites par Louvois).

Si vous tentez d’additionner des milliers ou des dizaines de milliers de nombres, vous n’avez pratiquement aucune chance de tomber sur le bon résultat même en utilisant une calculatrice. Il y a toujours un moment où vous allez confondre 2 nombres, inverser 2 étapes, etc… et donc, là encore, vous perdrez confiance dans le résultat obtenu. Des techniques de gestion sophistiquées sont nécessaires pour avoir une bonne chance d’arriver au résultat. On peut imaginer par exemple que 3 personnes saisissent indépendamment la liste des nombres dans un tableur puis utilisent la fonction somme du tableur (cette méthode fonctionne sous Excel si on a moins de 65 000 nombres à additionner). Si le résultat des 3 personnes est identique, on commence à avoir une confiance raisonnable dans le résultat obtenu.

Ainsi, l’opération qui consiste, pour chaque fonctionnaire, à calculer sa paie est simple. Mais un programme qui calcule automatiquement les paies de chaque fonctionnaire est d’une très grande complexité, qui n’a rien à voir avec l’opération de base. Il y a des milliers d’échelons, de régimes, de cas particuliers, d’exclusions, etc… Tout ceci crée des dizaines de milliers de règles, que personne, absolument personne, ne maîtrise dans leur ensemble. Et le test de ce programme est d’une complexité encore plus grande que son développement. Les règles interagissant les unes avec les autres, les procédures dites de “test unitaires” ne peuvent pas être suffisantes. Le nombre de cas à tester croît alors de fonction exponentielle, c’est à dire qu’il faut développer de multiples programmes complexes pour générer les cas de tests eux mêmes – et d’autres programmes pour vérifier que le logiciel aboutit au bon résultat. En cas de divergence, qui a raison ? Le programme de test ou le programme développé ? Le problème peut être – est – littéralement sans fin et c’est ce qui s’est passé dans le cas de Louvois et de Sirhen.

Au-delà de cette limite, votre ticket n’est plus valable

Je lis beaucoup de tentatives d’explications et toutes ont un certain degré de pertinence. De multiples stratégies ont été mises en oeuvre par les équipes pour tenter de résoudre les différents problèmes mais la réalité est tout bonnement la suivante:

Au-delà d’une certaine complexité de gestion – correspondant à celle d’une grande administration de l’état français –  des programmes tels que Louvois ou Sirhen sont tout bonnement impossibles à développer et tester.

 

La limite atteinte n’est pas de nature informatique, le problème n’est pas dans la puissance des machines ou dans les temps de traitement. Le problème est dans l’incapacité des équipes de développeurs à maîtriser, programmer et tester l’ensemble des règles nécessaires – ceci quelle que soit la compétence et la taille de ces équipes.

 

Il est aussi illusoire de faire fonctionner de tels programmes que d’arriver à additionner à la main et sans erreur des milliers de nombres simples.

Il ne faut pas informatiser l’Etat pour le simplifier, mais le simplifier pour l’informatiser

Compte tenu de cette impossibilité, quelle doit être la stratégie du donneur d’ordres – en l’occurrence l’état français ?

Le logiciel ne pouvant être développé compte tenu des règles existantes, il faut absolument changer les règles de gestion, les simplifier, de façon à ce que, une fois les nouvelles règles définies, celles-ci soient en suffisamment petit nombre pour être convenablement maîtrisées par des développeurs y ayant été préalablement formés – au moins quelques dizaines de personnes.

Les informaticiens doivent aussi avoir participé à la définition de ces règles, de façon à ce que leur programmation – et surtout leur test – soit rendu le plus simple possible. Des résultats convaincants, sinon finaux, devraient être obtenus en en moins d’un an pour des budgets relativement réduits (10 millions d’euros me semble un maximum). Il y aurait là matière à la création d’un grand corps d’état composé d’agents ayant reçu une formation d’excellence en informatique – pourquoi ne pas renommer et transformer, par exemple, le corps des Mines ?

En bref, l’erreur est de penser qu’on doit informatiser l’Etat pour le simplifier, alors qu’il faut faire exactement le contraire, il faut simplifier l’Etat pour l’informatiser. On entend parler, souvent à tort et à travers, de “start up nation” mais le grand avantage concurrentiel d’une startup est que, n’ayant pas d’historique, elle est capable de définir ses propres règles sans s’embarrasser de l’historique qui plombe les acteurs existants du marché.

Contrairement à ce qu’on pense, les problèmes de Sirhen et de Louvois ne sont pas techniques, ils sont du côté du donneur d’ordre, ils sont politiques. La gestion de l’Etat est devenue une chose trop importante pour ne pas être confiée, au moins en partie, à des informaticiens.