The blog of blog of blogs

Les aventures d'un ethnologue dans le grand monde

Ces Gauloises qui se consument 21 novembre 2012


.
Comme tous les métiers, l’informatique a ses propres références et ses propres dictons qui transmettent en arrière-plan des savoirs et des valeurs qui influencent les comportements. Les dictons véhiculent l’idée de ce qui est normal ou anormal.

Or il y a au moins un dicton très courant dans le monde de l’informatique et en particulier dans la gestion de projets d’informatique, c’est que 70% des projets ne réussissent pas. L’origine de l’expression provient d’un rapport publié par le Standish Group en 1995, sous le titre évocateur de Chaos.
Gloups.
.

Ce rapport a fait date, c’est le moins qu’on puisse dire… Mais à 17 ans d’intervalle, on pourrait se demander pourquoi il est toujours aussi vrai. Comment se fait-il que le taux de succès des projets d’informatique ne dépasse pas en moyenne les 30% ? Est-ce que la technologie ne s’est pas améliorée ? Est-ce que l’expérience des échecs ne permet pas de rendre plus fiables les projets suivants ?
.

Il existe un certain nombre d’outils, de méthodes et de normes qui permettent de rendre un projet plus fiable : normes ITIL, CMMI, PRINCE2 et j’en passe. Bien sûr que tout cela existe ! Que croyez-vous, c’est dans l’intérêt de tout le monde qu’un projet réussisse !
Le CMMI par exemple est le fruit d’un partenariat entre l’armée américaine et des universités de premier plan pour verrouiller absolument la qualité logicielle de son armement. Pour éviter par exemple que la mise à feu d’un missile thermonucléaire se fasse de manière aléatoire… L’industrie du logiciel a pris conscience du problème très tôt, ne vous y trompez pas. Dans tous les pays du monde, les fabricants et les sociétés de conseil et d’ingénierie en informatique ont fait des efforts pour « fiabiliser » leurs pratiques et pour vous convaincre que leur entreprise peut tout faire ou presque (le marketing ayant tendance à insister sur le ‘tout’ et les ingénieurs ayant tendance à insister sur le ‘presque’).
L’expérience des projets passés permettant en effet de rester crédibles face à des clients qui doivent déployer des installations toujours plus  monstrueusement complexes (le marketing ici évitant d’aborder les projets n’ayant pas marché).

.
Mais s’il est vrai que le diable se cache dans les détails (autre dicton universellement valable), alors on constate qu’en termes strictement techniques, c’est rarement le logiciel qui pose problème -un logiciel particulier que l’on pourrait montrer du doigt- c’est plutôt la manière dont le client a exprimé ses besoins au départ (« l’expression des exigences »), ainsi que la façon dont on intègre ce besoin à tous les autres logiciels d’un système d’information. En informatique, c’est là que surgit le diable : dans la gestion des exigences et dans l’intégration au SI.
En ce sens, les fournisseurs de services en informatique ont bien raison : ils peuvent tout faire… sous réserve que le client ait fait sa part du boulot : exprimer correctement son besoin et s’assurer que ce besoin une fois transformé en code logiciel sera compatible avec tout le reste de son système d’information. Ils sont là, les 70% d’échecs dont parle le dicton. Cette proportion ne peut pas être résorbée car c’est un cas particulier à chaque fois, d’où la permanence de ce pourcentage depuis presque vingt ans.
.

Pour terrifiant que ça puisse paraître, cela reste la partie facile d’un projet… l’ethnologue pourra vous parler ensuite de la partie difficile : la conduite du changement, l’appropriation par les utilisateurs, les valeurs du management, la culture interne de l’organisation, les symboles et les comportements face à l’erreur… bref le « facteur humain ».

Car l’échec total d’un projet provient rarement de la technique. La technique on peut la bidouiller, voire même fonctionner en solution dégradée le temps que les correctifs soient déployés. Par contre s’il vous faut un jour affirmer que le projet Untel doit être abandonné… quels que soient vos arguments, on trouvera probablement en arrière-plan des sujets organisationnels qui concernent le collectif de travail.
.

Comme je l’écrivais il y a quelques temps, dans le domaine de la gestion de projet, les méthodes et les Procédures Opérationnelles Standard couvrent assez bien les dérapages possibles à l’intérieur du projet. C’est ce qu’on appelle la gestion des risques et c’est le chef de projet qui en porte la responsabilité. Mais le point invisible concerne le projet tout entier. Que fait-on si c’est le projet lui-même qui dérape ? Que se passe-t’il si le projet met en difficulté tout le reste de l’organisation ? En général, c’est à ce moment là qu’on se rend compte qu’il est trop tard, si on n’a pas déjà prévu un plan B. La loi de Murphy n’est jamais loin, souvenez-vous, et j’espère que vous penserez à moi la prochaine fois que vous-vous frapperez le front en criant : Mince ! On n’a pas de plan B !
Or ce n’est pas l’équipe projet qui va le faire ce plan B, puisqu’il concerne autre chose que le projet.
Pour ceux qui n’ont pas bien compris je vais donc le redire : le plan de secours en cas d’échec d’un projet entier devrait être systématique et il relève de la responsabilité de l’organisation cliente, pas du sous-traitant ni de l’équipe projet, ni personne d’autre.
.

Concernant le projet LOUVOIS, c’est à peu près au milieu de l’année 2012 que tout le monde a compris que c’était un échec et qu’il n’y avait pas de plan B. L’organisation n’avait pas de plan de secours. Il n’y avait rien pour assurer la continuité de service.
C’est à ce moment là que des femmes de militaires ont formé le groupe des Gauloises En Colère et ont commencé à montrer publiquement des slogans écrits sur leurs propres dos.
.

LOUVOIS (Logiciel unique à vocation interarmées de soldes) est le nom du projet qui est devenu dans le secteur de l’informatique une référence en termes de foirage magistral. Foirage technique d’abord, puis surtout foirage organisationnel.

A l’origine, c’est une bonne idée et un projet somme toute assez répandu dans les grandes organisations. Ce contrat fut signé entre le ministère de la Défense et l’entreprise sous-traitante, Steria, en 2009 pour quatre ans et 6 millions d’euros.
Il s’agissait pour Louvois de recevoir et d’intégrer les données de cinq SIRH (Systèmes d’Information de Ressources Humaines) afin de déclencher les calculs et le versement des salaires.
Le premier déploiement concernait le branchement du SIRH du service de santé des armées, sans souci notable. C’est lorsque les 130.000 membres du SIRH de l’armée de Terre ont du être pris en compte en octobre 2011 que Louvois s’est retrouvé à genoux… et qu’il y est encore, un an après.
Dans cet intervalle, le versement des salaires s’est montré plus que fantaisiste et ce serait très drôle si, au final, ce n’étaient pas des familles entières qui finissaient par devoir s’excuser, s’endetter, s’humilier auprès de leur banque vu que, non, ce mois-ci encore la solde de monsieur (ou madame) n’a pas été versée. Pas du tout. Rien, que dalle.
.

Ce ne serait pas bien grave donc, si l’échec du projet Louvois était seulement un problème d’informatique. Pendant un an ce fut le point de vue d’une organisation incapable de voir la réalité en face. Pour une large part les valeurs qui font la force des soldats en service actif ont joué ici contre eux. Habitués à dédaigner les contraintes de leur métier, les victimes du nouveau logiciel de paie n’ont pas bronché. Pour des civils, c’est difficile à imaginer mais ici dans une organisation qui gère la routine de la guerre c’est un fait établi : on fait face, on ne se plaint pas et celui qui se plaint on lui dit de faire face.
Mais en n’entendant personne se plaindre, la gravité du problème a pu être minimisée par la hiérarchie qui n’avait pas bien accepté de reconnaître compris à quel point l’échec de ce projet informatique avait des conséquence directes et négatives dans le vrai monde.
Depuis octobre 2011, la meilleure estimation affirme qu’environ 40% des 130.000 militaires de l’Armée de Terre sont frappés par Louvois -et Louvois frappe fort !
Imaginez donc la révolution si 40% des salariés de, par exemple, Renault, découvraient que leur salaire n’était pas versé (ou mal)… pendant plus d’une année.
.

Du point de vue de la théorie des organisations, le projet Louvois en entier et chacune de ses phases de branchement à un SIRH avait au moins 3 bonnes probabilités de conséquences gigantesques. Cette simple déduction aurait du justifier la mise en place d’un Plan B, à la demande du responsable de chaque SIRH. Car ce sont les cinq SIRH des armées qui sont concernés ici, pour être branchés un à un sur Louvois : Arhmonie pour la Santé, Concerto pour l’armée de Terre, Rhapsodie pour la Marine, Orchestra pour l’armée de l’Air et Agorha pour la gendarmerie.   400.000 fiches de salaire en version cible…
Question : le ministère de la Défense possède t’il une fonction de Responsable SIRH ?Due salary for October 2012 : 0.   Ouch, that's a failed IT project !

La première probabilité réside (1) dans la nature de ce projet, lié au versement des salaires. Les conséquences, succès ou échec, sont à effet immédiat. Toutes les équipes qui ont travaillé sur un projet de paie pourront vous le dire, c’est chaud ! Le sujet est d’autant plus sensible que, à première vue, ça se passe loin, très loin, dans le monde obscur du back office. Erreur de perspective… car le versement des rémunérations fait partie de l’infrastructure vitale d’une organisation.

C’est (2) ensuite un projet qui se déroule dans une organisation bureaucratique, c’est-à-dire une organisation qui possède une inertie longue et inversement, une agilité très, très moyenne s’il faut apporter des actions correctives rapidement. Ce n’est pas une tare en soi d’être une bureaucratie, ne me faites pas dire ce que je n’ai pas dit, c’est juste qu’il y a des valeurs internes bien particulières à prendre en compte. Ceux qui ont déjà travaillé dans une banque me comprendront… Tout cela n’a rien de nouveau, relisez Michel Crozier et Henry Mintzberg. Leurs analyses démontrent qu’une telle organisation est incapable de se corriger, sauf accident majeur. Elle n’a pas de mécanisme, d’instance, de procédure pour le feedback, elle ne connaît pas le mouvement responsif.
Les soldats en opération connaissent et utilisent largement le compte-rendu pour informer leurs collègues combattants, mais l’organisation bureaucratique ne possède pas de mécanisme qui permette des ajustements rapides. Si un projet dégénère, on peut compter sur le fait que l’organisation ne saura pas faire face et laissera la situation pourrir jusqu’à la situation de crise.

C’est (3) enfin une population bien particulière qui est en jeu : si problème il devait y avoir dans le projet et dans le versement des salaires, les victimes seraient essentiellement des femmes et des enfants dont le conjoint et père est éloigné pour des raisons de service (et quel service !). Dans le secteur informatique on parle d' »utilisateur final » : celui qui constate et utilise un logiciel, ou ses effets. Pour le versement de la solde des militaires, l’utilisateur final n’est pas le soldat lui même s’il est en opération, c’est sa famille. Or sa famille a d’autres chats à fouetter que de savoir si le salaire sera effectivement versé et, si oui, avec quelle marge d’erreur. Il y a là une forte charge symbolique car la solde versée ne se compte pas seulement en euros, c’est aussi la reconnaissance de services rendus qui peuvent impliquer une mort violente. Pas de salaire signifie que l’organisation cesse de reconnaître les services rendus.
Accessoirement, c’est souvent aussi la seule source de revenus de la famille…

Tout cela en plus du fait qu’un projet informatique, avant même son démarrage, a seulement une probabilité de réussite de 30%.
…Dites-moi donc, quel était le plan B déjà ?
.
Maintenant que les torts sont causés cependant, le ministère et son prestataire vont devoir trouver une réponse à la question qui fait vraiment mal : comment déconstruire Louvois ?
.

En effet, non seulement le logiciel ne fonctionne pas comme on l’espérait (euphémisme !), mais surtout, par conception, il semble incompatible avec le reste du système d’information.
Ce n’est pas un problème de fenêtres de mauvaises dimensions, c’est un problème d’urbanisme.  Il faudrait pouvoir analyser les spécifications fonctionnelles et les documents d’architecture technique, pour vérifier si les blocages majeurs proviennent d’une mauvaise expression du besoin par le client, ou d’une mauvaise mise en œuvre de ce besoin par le prestataire.
Car de mon -modeste et mal informé- point de vue, nous ne parlons plus de ‘bugs’ informatiques. Déjà, un bug en informatique, ça n’existe pas. Il y a des anomalies, chacune avec son numéro unique, sa description et une solution à lui trouver. Mais avec Louvois on n’en est plus là. Depuis un an que les problèmes s’empilent, s’il s’était agi d’anomalies de code, elles auraient été résolues ou au moins contournées. Le problème semble lié à l’intégration au reste du système d’information… et un SI ce n’est pas de la mécanique, on n’enlève pas une pièce pour la remplacer par une autre : elles sont fusionnées. L’avenir de Louvois dans le SI des armées n’est donc pas garanti, il va peut-être falloir envisager de déconstruire, comme on désamiante un bâtiment, sans toucher à la structure du bâtiment lui-même.
.

Bref, c’est la procédure PBM pour tout le monde : pour les informaticiens, pour les responsables de l’organisation et aussi pour les membres de l’organisation. Or, s’il y a bien une chose anormale, c’est qu’ici, c’est l’organisation elle-même qui met ses membres en difficulté sans apporter d’action correctrice pendant un an.

A ce titre, que personne ne se trompe, en comparaison des aspects purement techniques il y a un projet bien plus difficile à mener dès aujourd’hui pour l’institution militaire : restaurer la confiance de ses membres et de leurs familles -voire même calmer la défiance qui a grossi depuis un an.
Vaste tâche qui pourrait commencer par un dédommagement substantiel pour 130.000 personnes. Quelque chose qui dépasse le symbole et des excuses au journal de 20 heures. Quelque chose pour montrer que l’organisation est capable de reconnaître qu’elle a fortement nuit à la vie privée des membres qui la servent -et que c’est inacceptable.
.
Ensuite mettre en place des procédures de feedback qui soient fonctionnelles et pérennes du point de vue de la vie quotidienne. Quelque chose pour montrer que le collectif de travail est capable d’apprendre à ne pas nuire à ses propres membres par apathie.
Ainsi, grâce à l’échec de ce projet, l’armée française et l’administration au sens large ont l’opportunité de gagner un peu en agilité et de ressembler un peu davantage à un yo-yo, l’outil le plus remarquable jamais inventé pour ceux qui savent s’améliorer.
.

Cela doit être réalisé avant de lancer la suite du projet Opérateur National de Paye.  Un indice : ce ne sera sans doute pas Louvois dans sa forme actuelle qui assurera le rôle d’ONP…
.
.
.

Publicités
 

5 Responses to “Ces Gauloises qui se consument”

  1. Nicolas Says:

    Bonjour,

    Article très intéressant, comme souvent sur ce blog !

    Le fait que ce projet LOUVOIS soit un échec si cuisant est est en effet terrible pour les familles…

    Par contre, il me semble distinguer un mythe dans l’analyse de ce projet.

    Un mythe lorsqu’il est dit qu’  » Il faudrait pouvoir analyser les spécifications fonctionnelles et les documents d’architecture technique, pour vérifier si les blocages majeurs proviennent d’une mauvaise expression du besoin par le client, ou d’une mauvaise mise en œuvre de ce besoin par le prestataire. ».

    C’est en effet illusoire de croire qu’on trouvera la raison de l’échec dans l’une ou l’autre des raisons : en réalité, on recherche plus un responsable d’abord, un coupable ensuite, un bouc émissaire enfin. Le mythe est dans la recherche de la responsabilité unique. La responsabilité est partagée, même si elle n’est pas forcément à hauteur égale pour les différentes parties prenantes. La méthode de gestion de projet traditionnelle est quasi inévitable pour des projets de cette envergure, mais par définition elle ne permet de ne se rendre compte que tardivement (à la « recette ») de l’étendue des problèmes. Alors lorsque cela se passe mal, ou très mal comme ici, seule « la » crise permettra de rétablir, provisoirement, la paix sociale.

    C’est d’ailleurs bien de cela qu’il est question lorsque vous parlez de « restaurer la confiance » : à ce niveau-là de crise, c’est l’organisation même qui est en jeu.

  2. […] Le point fort des méthodes agiles sur ce sujet consiste à considérer avec attention le rapport entre les avantages et les inconvénients d’une architecture planifiée dès le lancement du projet. La meilleure décision portera sur le point médian -le juste milieu- entre les extrêmes de ‘pas d’architecture du tout’ et l’illusion d’une architecture complète, comme on a pu le voir dans la catastrophe du projet LOUVOIS. […]

  3. […] va très sévèrement dégénérer… Si vous voulez vous faire peur, vous pouvez lire l’histoire lamentable du projet LOUVOIS, le procès entre l’assureur MACIF et son prestataire IGA, ou la question posée à la […]


Laisser un commentaire

Entrez vos coordonnées ci-dessous ou cliquez sur une icône pour vous connecter:

Logo WordPress.com

Vous commentez à l'aide de votre compte WordPress.com. Déconnexion / Changer )

Image Twitter

Vous commentez à l'aide de votre compte Twitter. Déconnexion / Changer )

Photo Facebook

Vous commentez à l'aide de votre compte Facebook. Déconnexion / Changer )

Photo Google+

Vous commentez à l'aide de votre compte Google+. Déconnexion / Changer )

Connexion à %s