Dans ma carrière j’ai croisé quelques projets qui ont mal finis, en tant qu’observateur ou en tant que participant.
Je ne sais pas si tous les gros projets informatiques qui ont mal fini se ressemblent, mais en tous cas ceux que j’ai croisé avaient un certain air de famille.
Un des points communs c’est que souvent on en parle peu à l’extérieur : pour plein de raisons on préfère laver son linge sale en interne, ou même faire comme si le projet avait été un succès pour éviter d’avoir à en tirer les conséquences. Quand des articles sortent dans les journaux, suite à un problème particulièrement visible ou parce qu’une entreprise porte plainte contre un sous-traitant, les détails, passés au filtre des services juridiques, ne laissent pas grand chose à se mettre sous la dent.
Pour une fois ce n’est pas le cas : suite à un projet de migration qui a mal fini, la banque TSB a demandé un audit, et a eu le rare courage de le publier en intégralité.
La migration consistait à changer le système central de gestion bancaire de l’entreprise. TSB est une sous-partie de du groupe bancaire Lloyds qui a été transformée en entreprise indépendante pour des raisons réglementaire. Après la séparation, TSB a continué à utiliser le système informatique de la Lloyds contre redevance.
Si l’idée peut sembler bizarre, il s’agit d’une manière de faire classique dans ce genre de situation car elle permet une séparation rapide et sans risque des deux entités, même si elle n’est pas forcément pérenne sur le long terme.
Quelques années plus tard, le groupe bancaire espagnol Sabadel décide de racheter TSB. Le modèle économique du plan de rachat s’appuyait sur le fait de migrer rapidement le système informatique utilisé par TSB sur le système développé par Sabadel, ce qui permettait d’économiser le prix de la redevance, d’autant que, selon l’échéancier fixé lors de la création de TSB, le prix à payer chaque année allait augmenter significativement. D’autres banques rachetées par Sabadel avaient déjà été migrées sur son système informatique et les migrations s’étaient bien passées. Cela donnait confiance dans le fait que le plan pouvait se dérouler comme prévu.
La lecture me donne un douloureux sentiment de gâchis : tant de problèmes si prévisibles et de temps et d’effort gaspillés.
Si vous n’avez jamais eu la “chance” de participer à ce genre de projets, je vous conseille vivement la lecture de ce rapport (ou au moins le résumé de quelques pages qui se trouve au début), et cela pour deux raisons.
Tout d’abord si un jour vous travaillez un un gros projets qui commence à tourner mal, cela vous permettra d’en reconnaître les symptômes à temps. Je ne sais pas si cela vous permettra d’améliorer les choses, mais cela pourrait au moins vous aider à ne pas y laisser trop de plumes.
Ensuite les gros projets sont des petits projets à plus grande échelle, et cet effet grossissant permet de rendre plus facile à comprendre des mécanismes à l’œuvre même à des tailles plus petites. Et pour le coup, cela pourrait vous aider à faire une différence.
J’ai relevé les points qui m’ont le plus marqués, je vais tenter d’expliquer comment chacun peut arriver, mais je ne proposerai pas forcément de solution.
Piloter un gros projet informatique n’est pas une mince affaire
Si on se moque souvent de l’incompétences des personnes chargées de piloter des projets informatique, on mentionne rarement la difficulté de leur tâche et le niveau de compétence que ça peut nécessiter : il faut maîtriser la gestion de projet “standard”, mais aussi dans une certaine mesure les spécificités des différentes technologies.
Dans beaucoup d’organisations, comme par exemple les banques, les gros projets informatiques sont souvent parmi les projets les plus importants qu’elles ont à gérer, en terme de budget, de durée et de complexité. Cela signifie en général que le pilotage est assuré par des membres de la direction, qui souvent ont des compétences faible en informatique.
La capacité d’un comité de pilotage a faire son travail dans ce genre de situation peut donc être limitée, et peut se limiter à vérifier que les choses sont faites selon les formes.
Si ces personnes peuvent être capable de comprendre les enjeux si on les leur explique, il peut leur être difficile de prendre du recul sur ce qu’on leur raconte, par exemple pour jauger du bien fondé ou du niveau de risque de telle ou telle décision.
Dans le cas TSB, l’audit explique comment le comité en charge du projet n’a pas été en mesure de jouer son rôle par manque d’expérience, et comment les consultants extérieurs appelés à la rescousse n’ont été d’aucune aide.
Les calendriers
Il est difficile de faire des prévisions, surtout à propos du futur.
Prévoir la durée d’un projet informatique d’une certaine taille est un exercice compliqué et risqué rien de neuf là dedans. Malheureusement il est souvent nécessaire pour pouvoir valider que le projet vaut la peine, et pouvoir organiser sa mise en œuvre.
Dans le cas TSB, la durée du projet a une incidence directe sur la rentabilité de toute l’opération, à cause du prix de la redevance à payer sur le logiciel existant.
Cela signifie que les retards peuvent avoir des effets importants.
Le rapport explique que le planning a été fait à rebours : une date satisfaisante pour la fin du projet a été choisie, et on s’est efforcé ensuite d’établir un calendrier permettant d’aboutir à cette date sous forme d’un retro-planning.
Dans certaines organisations, cette manière de faire est vue comme un signe de leadership : la croyance est que faire un planning standard c’est prendre le risque de se faire avoir par différents groupes qui ne cherchent qu’à prendre leur temps.
Imposer sa volonté au système, en choisissant une date et en mettant la pression pour qu’elle soit tenue, est donc pris pour une démonstration de force de caractère.
Dans ce type de situation, annoncer un retard c’est donc défier la volonté de la personne haut-placée qui a choisi une date.
Cela peut avoir deux conséquences.
La première est sur la fiabilité des informations remontées. En général l’effet est assez drastique : tout ce qu’il est humainement possible sera mis en œuvre pour faire en sorte de cacher les problèmes tant que cela est possible.
L’exemple que j’ai vu régulièrement, et qui arrive encore pour TSB, c’est de proposer de gagner du temps en testant des composants avant que leur développement ne soit terminé.
Sur le papier cela semble une bonne idée, mais dans la réalité cela signifie dans mon expérience d’avoir d’un côté des équipes de tests ne sachant pas si les problèmes sont dus à des bugs ou à des développements non terminés, et d’un autre des équipes de développement sous pression pour terminer des fonctionnalités recevant des rapports de bugs qu’elles n’ont donc pas le temps de traiter.
La deuxième est sur la capacité à gérer les risques : quand la pression est trop forte sur la tenue d’une date, il n’est plus possible de choisir rationnellement entre une solution risquée mais qui semble plus rapide et une solution moins risquée mais plus lente ou moins ambitieuse. Cela signifie que les solutions risquées auront davantage de chances d’être choisies que dans d’autres projets, et que plus on s’approche de la fin de projet plus cette tendance va se renforcer.
Dans le cas de TSB, les propositions de tester d’abord la nouvelle solution dans certaines branches, ou seulement pour les nouveaux·elles client·e·s ont ainsi été écartées.
“On l’a déjà fait”
Une des raisons de l’optimisme affiché lors du planning initial est que Sabadel avait déjà réalisé ce type d’opérations et que les fois précédentes s’étaient bien passé.
Leur vision était que leur système — ayant pu absorber sans trop de changements d’autres banques dans d’autres pays — serait suffisamment adaptable pour TSB.
Pour savoir si c’est le cas, il faut mesurer l’écart entre d’un côté les produits bancaires proposés par TSB et la législation britannique et d’autre part ce qu’il est possible de faire dans le système Sabadel.
Mais pour faire une estimation en début de projet, il faut être capable de faire ce type d’analyse d’une manière macroscopique, parce que le faire dans le détail prendrait des mois et coûterait très cher. Cette analyse détaillée est typiquement une des premières choses qu’on fait lorsqu’un projet est déjà démarré, dans l’espoir qu’il est encore temps de modifier le planning en fonction de ce qu’on va trouver.
Lors de la pré-analyse, il faut donc être en mesure d’identifier rapidement les endroits qui pourraient poser problèmes, et d’essayer d’estimer l’effort à fournir pour adapter le système.
Le risque à la fois de rater des zones à problèmes et de mal estimer leur ampleur est donc important, et cela d’autant plus que le système à migrer est complexe. On est typiquement dans un cas d’inconnu inconnu, où les personnes peuvent avoir tendance à se concentrer sur les zones déjà identifiées comme à risque, par exemple parce qu’elles ont posé problèmes dans les migration précédentes, tout en ayant tendance à ignorer les risques dans les endroits qui n’ont pas posé de problèmes dans les cas précédents, car les personnes les n’ont pas la connaissance qui leur permettrait de les identifier comme des zones à risque.
Dans le cas de TSB, ce sont à priori les spécificités du marché britannique qui ont été sous-estimées, par conséquent le planning initial n’était pas du tout réaliste.
Revenir en arrière sur le planning une fois le projet démarré par suite des retours de l’analyse détaillée aurait signifié devoir expliquer que le logiciel de gestion de Sabadel n’était pas aussi adaptable que ce qui avait été annoncé, alors même que cette adaptabilité était largement mise en avant dans les plans de développement de l’entreprise.
Comme dans le cas du planning, on retrouve une situation où la capacité du projet à s’adapter en cours de route est sévèrement limité par des contraintes extérieures (la rentabilité de toute l’opération ou l’image de marque de l’entreprise). On se retrouve donc dans une situation où “ça passe ou ça casse”.
Les validations
Pour savoir si un système informatique fonctionne, on le soumet généralement à différents types de validations sous forme de tests.
Cela peut être des tests à un niveau fin comme à des niveaux plus élevés, comme par exemple les tests d’intégration qui permettent de valider que différentes briques logicielles sont bien en mesure de fonctionner ensemble comme un tout cohérent.
Tant que ces tests n’ont pas été effectués, on ne sait pas si le système fonctionne ou pas.
Il y a alors deux approches.
La première consiste à vouloir dès que possible lever le doute, et donc à vouloir dès que possible être en mesure d’évaluer le fonctionnement du système. L’idée est alors d’identifier les parties les plus à risques pour les éprouver, et ainsi pouvoir mesurer au plus juste l’avancement du projet, et donc pouvoir prendre des le plus rapidement possible des mesures correctives.
La seconde est de vouloir lever le doute le plus tard possible. Cela peut sembler paradoxal, voire même idiot, mais souvenez-vous de ce qui a été dit à propos du planning : tout d’abord pour les personnes appartenant le projet, il est extrêmement important de ne pas remettre en cause le planning officiel pour ne pas se mettre en opposition avec la direction, ensuite le planning ne sera changé que lorsqu’il n’est plus tenable de faire autrement.
Connaître rapidement l’état réel du système, cela fait donc porter un risque pour les personnes dans la confidence tout en ayant de grandes chances de ne servir à rien pour le projet.
Dans cette situation il est donc rationnel de vouloir le plus longtemps piloter le projet à partir d’un avancement théorique, plutôt que de se confronter à la réalité.
Dans le cas de TSB, les tests d’intégrations entre composants ont été planifiés à la fin du projet, et ont révélés de nombreux problèmes. Les résoudre a été compliqué car les équipes en charge des différentes briques ont dépensé beaucoup de temps et d’énergie pour démontrer que le problème ne venait pas de chez elles pour ne pas être blâmées, ce qui a retardé d’autant les corrections
Fournisseur interne
Le dernier problème d’importance est celle de la gestion d’un fournisseur interne.
Un fournisseur interne dans une entreprise c’est le fait de traiter une partie de l’organisation un peu comme s’il s’agissait d’un fournisseur extérieur, en établissant des échanges du type client - fournisseur plus ou moins formalisés.
Lorsque le fournisseur est un centre de coût, cela peut permettre en théorie de mieux mesurer le prix payé pour le service, par exemple en faisant de la facturation interne. Cela signifie aussi dans mon expérience donner aux équipes clientes la légitimité de mettre la pression sur l’équipe fournisseuse pour essayer d’en avoir “pour son argent”, sans penser à l’équilibre global de l’entreprise.
Et, comme dans le cas de TSB, cela signifie que quand les choses tournent mal on peut se retrouver dans des situations très difficiles à gérer où chaque camp se retranche derrière son rôle officiel (client ou fournisseur) pour ne pas avoir à coopérer, mais sans qu’on dispose des outils qui permettent de trancher ce type de problème dans les cas où il s’agit réellement d’un client et d’un fournisseur, par exemple de “vrais” contrats ayant valeur légales, des indemnités…
On a donc alors les inconvénient des deux systèmes (internet et externe) sans les avantages d’aucun des deux.
Conclusion
Comme l’a dit très justement Nicolas : “le truc qui me déprime c’est de penser a tous les gens qui savaient mais n’ont pas pu agir”.
Car ces gros projets ont beau dysfonctionner du sol au plafond, cela n’empêche pas que des personnes de bonnes volontés prennent sur elles d’essayer de sauver les meubles, parfois au détriment de leur santé. De ces personnes là l’audit ne parle pas.
J’espère que la lecture de cet article vous évitera de vous retrouver dans cette posture sans l’avoir choisi, voire qu’il vous aidera à faire une différence.