Les 5 signaux d'alerte d'un projet de digitalisation qui va déraper
Un projet ne dérape jamais du jour au lendemain. Il donne des signes reconnaissables des semaines avant, et ces cinq-là sont les plus fiables.
En résumé : un projet ne dérape pas brutalement — il dérive, et les signes apparaissent des semaines avant que le retard soit visible. Les cinq signaux ci-dessous sont, d'expérience, les plus fiables. Aucun n'est technique : ce sont tous des symptômes de gouvernance, et c'est précisément pour ça qu'on peut les corriger sans refaire le projet.
1. Le reporting devient qualitatif
Au démarrage, on vous dit « le module de commandes est terminé, il reste les tests ». Quelques semaines plus tard, on vous dit « ça avance bien ». Le passage du factuel au rassurant est le signal le plus précoce et le plus négligé.
Correction : demandez un état d'avancement par livrable, avec un pourcentage et ce qui reste. Toujours le même format, à la même fréquence.
2. Les décisions attendent plus d'une semaine
Le prestataire pose une question, personne ne tranche. Le projet ne s'arrête pas — il continue sur une hypothèse. Ces hypothèses non validées s'accumulent, et se découvrent toutes en même temps à la recette.
Correction : une seule personne responsable des arbitrages métier, avec un délai de réponse annoncé. Le délai importe moins que le fait qu'il existe.
3. Le périmètre grossit sans que rien ne bouge
Des demandes s'ajoutent au fil des réunions — « pendant qu'on y est, il faudrait aussi… » — sans que le délai ni le budget ne soient revus. C'est la cause la plus courante de dépassement, et la plus facile à éviter.
Correction : tout ajout est chiffré en délai et en budget avant d'être accepté. Pas de refus systématique : une décision explicite.
4. Les tests sont faits par celui qui a produit
Quand le développeur teste son propre travail, il teste ce qu'il a prévu, pas ce que l'utilisateur va faire. Les défauts remontent alors en production, au pire moment, avec le maximum de visibilité interne.
Correction : une personne côté métier valide chaque livraison contre les critères de recette écrits au départ. Une demi-journée par lot suffit souvent.
5. Personne ne sait ce qui se passe si le prestataire s'arrête
Pas d'accès au code, pas de documentation, une seule personne qui connaît le paramétrage. Le projet peut très bien avancer — il est simplement devenu fragile à un seul événement.
Correction : vérifiez dès le premier mois que vous avez les accès et que la documentation existe. Pas au moment où vous en avez besoin.
Ce que ces cinq signaux ont en commun
Aucun n'est un problème technique. Ce sont des problèmes de cadrage et de gouvernance, ce qui est une bonne nouvelle : ils se corrigent en quelques semaines, sans rien réécrire, à condition de les traiter pendant qu'ils sont encore des signaux et pas encore des faits.
Si plusieurs de ces points vous parlent, le plus utile est de faire un état des lieux avant d'ajouter quoi que ce soit au projet.
Une liste de contrôle hebdomadaire
Répondez chaque vendredi et gardez l'historique. Deux « oui » dans la même semaine : il est temps d'agir.
- Le rapport de la semaine décrit-il l'avancement par livrable, avec un pourcentage et le reste à faire ?
- Une question du prestataire attend-elle une réponse depuis plus de cinq jours ouvrés ?
- Du périmètre a-t-il été ajouté sans impact annoncé sur la date et le budget ?
- Quelqu'un de votre côté a-t-il testé une version face aux critères d'acceptation ?
- Avez-vous aujourd'hui vos propres accès au code, à l'hébergement et à la base de données ?
À quoi ressemble un vrai dérapage
Sur un chantier de 90 000 $, six sprints plus tard, tous les rapports étaient verts. Confrontés aux critères écrits, trois sprints sur six n'étaient que partiellement livrés. Les signaux 1 et 4 (reporting qualitatif, tests faits par ceux qui ont développé) étaient présents dès le premier mois. Détecté au sprint six, cela s'est renégocié sans coût.
Autre cas, côté accès : lors d'une revue technique, le code était meilleur que prévu, mais un seul prestataire détenait les seuls accès à la base de production et au déploiement, et n'était plus payé depuis sept semaines. C'est le signal 5, résolu en quatre jours une fois nommé.
Pour qu'un tiers indépendant note chaque sprint, voir la supervision de prestataire.
Articles similaires
Notes
Audit de code : ce qu’il vérifie et ce qui détermine son prix
Ce que couvre un audit de code utile, des constats réels tirés de projets en production, ce qui fait varier le prix et cinq questions à poser à tout auditeur.
Notes
Modèle de cahier des charges pour une application mobile
Le modèle en neuf rubriques que j’utilise pour une application mobile, avec des critères d’acceptation testables et les erreurs à éviter.
Notes
Comment évaluer le travail d’une agence de développement sans lire le code
Noter chaque livrable face à des critères écrits, tester côté métier, repérer les cinq signaux d’alerte et vérifier ce qui est entre vos mains.
Newsletter
Recevez mes prochains articles directement dans votre boîte mail.