Projet logiciel en difficulté : arbre de décision pour les 14 premiers jours

Lorsqu'un projet informatique part à la dérive, cela fait généralement plusieurs semaines que des signaux d'alerte sont passés inaperçus. La réunion au cours de laquelle il apparaît clairement que la mise en production ne pourra pas avoir lieu donne l'impression d'être le début de la crise. En réalité, ce n'est que le moment où celle-ci devient visible.

Ce qui compte lors des premiers jours d'une crise liée à un projet informatique

La question de savoir quoi faire se pose souvent trop tôt. Il faut d’abord déterminer ce que nous savons réellement à ce moment-là et ce que nous croyons simplement savoir. C’est précisément pour cette raison qu’il ne faut pas céder à l’activisme dans les premiers jours. La pratique classique en matière de gestion de crise consiste à dresser d’abord un état des lieux avant même d’envisager un report des échéances ou une réaffectation des ressources (Projekt Magazin, 2015). Ceux qui repoussent immédiatement les échéances sans en connaître la cause ne font souvent que repousser de quelques semaines l’échec suivant.

Les 14 premiers jours sous forme d'arbre de décision

Une approche qui a fait ses preuves dans la pratique consiste à diviser les deux premières semaines en quatre phases, chacune ayant son propre objectif. Il ne s'agit pas d'un schéma rigide, mais d'un cadre qui empêche la crise de devenir une préoccupation permanente au lieu de déboucher sur une décision.

1. Jours 1 à 3, état des lieux. Qui prend réellement les décisions dans ce projet, et qui se contente de croire qu’il le fait ? Quels risques sont documentés, et lesquels ne circulent que sous forme de rumeurs ? L’objectif de cette phase est d’établir un tableau écrit et fiable des rôles, des risques et des obstacles en suspens, sans porter de jugement ni chercher à attribuer des responsabilités. Deutscher Consulting décrit précisément cette approche comme la norme pour les dix premiers jours d'une mission (Deutscher Consulting, 2025).
2. Jours 4 à 7 : parties prenantes et contrat. Viennent ensuite les discussions avec le donneur d'ordre, le service concerné et, le cas échéant, le prestataire externe. Que prévoit le contrat en matière de critères de réception et de processus de modification ? En quoi les attentes verbales s’écartent-elles de ce qui a été convenu par écrit ? Cette phase met souvent davantage de choses en lumière que l’analyse technique, car c’est là qu’apparaît s’il existe réellement un consensus sur ce que le projet doit fournir.
3. Jours 8 à 11, contrôle technique approfondi. Ce n'est qu'à ce stade que l'on se penche sur le code, l'architecture et le modèle de données. Quel est le niveau de couverture des tests ? Dans quelle mesure les interfaces sont-elles documentées ? Combien de solutions de contournement le système comporte-t-il, dont plus personne ne peut expliquer le fonctionnement ? Cette phase permet de déterminer si les fondements techniques sont solides ou s'ils constituent la cause réelle du retard.
4. Jours 12 à 14, décision. Les trois phases précédentes débouchent sur l'une des trois recommandations suivantes : poursuivre le travail avec un plan adapté, remanier le projet sur le plan technique ou organisationnel, ou l'arrêter et le relancer à zéro. Cette décision doit être motivée par écrit, en s'appuyant sur des observations concrètes et non sur l'intuition de la personne responsable.

Pourquoi l'ordre est important

Dans la pratique, l'erreur la plus courante réside dans l'ordre dans lequel on procède au début. Celui qui commence par l’analyse technique avant d’avoir cerné les rôles et les attentes se retrouve souvent à évaluer le mauvais système, car les capacités réelles attendues de ce dernier ne sont pas clairement définies. À l’inverse, celui qui aborde immédiatement la question des contrats avec les parties prenantes avant d’avoir clarifié en interne les risques se retrouve en position de faiblesse lors des négociations.

Selon ce modèle, la stabilité opérationnelle, c'est-à-dire un état dans lequel le projet informatique peut à nouveau être planifié et piloté, n'est atteinte qu'au 30e jour (Deutscher Consulting, 2025). Les deux premières semaines fournissent les éléments nécessaires à la prise de décision. La mise en œuvre nécessite ensuite autant de temps, voire souvent davantage.

Pour les modèles présentés dans l'article Pourquoi les projets informatiques échouent-ils ? Comme cela a été décrit, cela vaut tout particulièrement ici, car les exigences floues ne peuvent pas être clarifiées en passant.

Ce qui ressort concrètement à l'issue de ces 14 jours

Les trois issues possibles diffèrent considérablement en termes d’effort et de risque. Poursuivre le travail avec un plan adapté implique généralement de nouveaux jalons, un changement dans les rapports adressés à la direction et, souvent, une réduction de l’étendue des fonctionnalités à ce qui est réellement nécessaire à la date initialement prévue. Dans la pratique, la refonte concerne souvent l’architecture ou la structure de l’équipe, par exemple lorsque deux groupes travaillent en parallèle sur le même module sans que personne ne soit responsable de l’interface. L’arrêt du projet est l’option la plus rare, mais aussi la plus importante, lorsque l’analyse technique approfondie montre que les fondements ne tiennent pas la route.

Un redémarrage peut sembler être la pire des solutions, mais c’est parfois l’option la plus avantageuse par rapport à un projet informatique qui continue à engloutir de l’argent pendant des mois sans se rapprocher de son objectif. Les critères à prendre en compte sont présentés dans l’article consacré à Sauver le projet ou repartir à zéro.

Il est important de noter que cette décision ne relève pas uniquement de la personne qui a mené l'évaluation de 14 jours. Celle-ci fournit simplement les faits. La décision elle-même doit être prise au niveau de la direction responsable du budget, c'est-à-dire généralement la direction générale ou la direction informatique, en collaboration avec le donneur d'ordre du projet.

Foire aux questions

Qui effectue l'analyse au cours des 14 premiers jours ?

Idéalement, il s'agit d'une personne dotée d'une expérience technique et organisationnelle, qui ne faisait pas partie de la structure du projet jusqu'à présent. Les responsables internes sont souvent trop impliqués dans les décisions prises jusqu'à présent pour pouvoir les évaluer en toute impartialité. Un CTO par intérim assume souvent ce rôle précisément pour la durée de l'audit et au-delà.

L'équipe doit-elle continuer à travailler pendant l'audit ?

En règle générale, oui, pour les parties incontestées du système, pour lesquelles un arrêt des travaux n'entraînerait que des coûts supplémentaires sans apporter de nouvelles connaissances. Pour les domaines directement concernés par la décision, comme un composant architectural controversé, un arrêt temporaire vaut la peine jusqu'à ce que l'analyse approfondie soit terminée.

Que dit-on à l'équipe à ce stade ?

La transparence sur le processus inspire davantage confiance que les paroles rassurantes. Une équipe qui sait qu’un examen structuré, assorti d’un calendrier précis, est en cours et qui connaît la date à laquelle une décision sera prise, travaille avec plus de concentration qu’une équipe qui n’entend que des rumeurs concernant une éventuelle réorientation.

La prochaine étape

torck réalise l'analyse de la situation, l'évaluation des parties prenantes et l'étude technique en équipe, qui se charge ensuite elle-même de la suite du projet, au lieu de se contenter de remettre un rapport. Une fois la décision prise, ses propres équipes de développement à Maxhütte-Haidhof, Vienne et Rabat sont prêtes à prendre immédiatement en charge la mise en œuvre et la direction technique. Prenez rendez-vous pour un premier entretien sans engagement en fonction de la situation concrète de votre projet.