Les signaux qu'un projet informatique est en train de déraper

Un projet ne dérape jamais d’un coup. Il dérape lentement, et l’annonce du retard arrive longtemps après les premiers signes.

Ces signes sont visibles depuis le côté client, sans compétence technique. Encore faut-il savoir lesquels regarder.

Signal 1 — Vous n’avez rien vu fonctionner depuis trois semaines

C’est le signal le plus fiable, et de très loin.

Sur un projet sain, vous voyez régulièrement l’application tourner — pas des maquettes, pas des captures d’écran : le logiciel réel, sur un environnement accessible. Toutes les deux semaines au minimum.

Quand ces démonstrations s’espacent, avec de bonnes raisons à chaque fois — « on est sur des sujets techniques », « ce ne serait pas parlant » —, quelque chose ne va pas. Il y a toujours quelque chose à montrer, même modeste, et refuser de montrer est en soi une information.

Ce que je conseille : exiger une démonstration toutes les deux semaines dès le lancement, et la traiter comme un engagement contractuel, pas comme une gentillesse.

Signal 2 — Les réponses deviennent vagues

Au début, les réponses sont précises : « la reprise des données sera terminée jeudi ». Puis elles se diluent : « on avance bien sur la reprise », « il reste quelques points à traiter ».

Ce glissement est presque toujours involontaire. Il traduit une équipe qui ne sait plus elle-même où elle en est — parce que le sujet est plus complexe que prévu, ou que trop de choses sont ouvertes en parallèle.

Ce que je conseille : poser des questions fermées. « Est-ce que la reprise fonctionne sur le jeu de données complet, oui ou non ? » Une réponse qui ne peut pas être oui ou non est une réponse en soi.

Signal 3 — L’équipe change

Un développeur remplacé, un chef de projet qui « suit désormais un autre dossier », des interlocuteurs qu’on ne connaît pas dans les échanges.

La rotation existe, elle est normale. Ce qui doit alerter, c’est qu’elle ne soit pas annoncée et expliquée. Un prestataire qui gère bien une transition la prépare et vous en parle. Un changement subi signale un problème interne — surcharge, désengagement, ou pire.

Le coût est réel : chaque arrivée demande plusieurs semaines de reprise de contexte, et cette perte n’apparaît jamais au planning.

Ce que je conseille : demander, dès le contrat, à être informé de tout changement dans l’équipe et à connaître nommément qui travaille sur le projet.

Photo : Matt Bango — licence CC0.

Signal 4 — L’avancement est exprimé en pourcentage

« On est à 70 %. » C’est le chiffre le plus rassurant et le moins informatif qui soit.

Un pourcentage ne se vérifie pas. Il est calculé sur une estimation initiale — celle-là même qui est peut-être fausse. Et il progresse de façon suspecte : 70 % pendant six semaines, c’est un grand classique.

Un projet sain se raconte en fonctionnalités : « la création de dossier et la validation sont en préproduction, la facturation est en cours, la reprise de données n’a pas commencé ». C’est vérifiable, et cela permet d’arbitrer si le temps manque.

Ce que je conseille : refuser les pourcentages dans les comptes rendus, et demander une liste avec trois états — livré et recetté, en cours, non commencé.

Deux signaux plus tardifs

Les demandes de changement se multiplient de votre côté. Si vos équipes demandent beaucoup de modifications en cours de route, ce n’est pas de l’indiscipline : c’est que le cadrage n’a pas suffi, et que les vraies attentes se découvrent maintenant. Le budget dérapera, et ce n’est pas la faute du prestataire.

Les corrections font apparaître de nouveaux bugs. Une correction sur deux qui casse autre chose signale une base fragile ou une absence de tests. C’est le signal le plus grave, parce qu’il annonce que le rythme va s’effondrer — chaque livraison coûtera plus cher que la précédente.

Photo : domaine public (CC0).

Le signal le plus discret : le vocabulaire change

Celui-ci se remarque rarement sur le moment, et il précède presque toujours les autres.

Au début, on parle de fonctionnalités et d’utilisateurs. Puis, progressivement, les comptes rendus se remplissent de sujets techniques : une migration, un socle, une refonte d’une couche interne. Ces travaux sont parfois légitimes. Ce qui doit alerter, c’est qu’ils occupent toute la place.

Ce glissement signifie en général que l’équipe rencontre une difficulté qu’elle ne sait pas formuler en termes métier, et qu’elle avance sur ce qu’elle maîtrise en attendant. Le temps passe, et rien de visible ne sort.

La question à poser : « quelle fonctionnalité un utilisateur pourra-t-il essayer à la fin de cette phase ? » Si la réponse est « aucune, c’est un travail de fond », cela peut être vrai une fois. Deux fois de suite, il faut creuser.

Ce qu’il ne faut surtout pas faire quand on repère un signal

Trois réflexes aggravent systématiquement la situation.

Ajouter du contrôle. Doubler la fréquence des comités et exiger des rapports plus détaillés consomme le temps de ceux qui devraient produire, et ne change rien à la cause.

Ajouter des gens. Sur un projet déjà en difficulté, chaque arrivée coûte du temps aux personnes en place avant d’en rapporter. Le renfort produit ses effets plusieurs semaines plus tard, alors que la situation exigeait une correction immédiate.

Attendre le prochain jalon pour en parler. C’est le plus fréquent, par gêne ou par espoir que les choses se rétablissent. Un problème signalé tôt se traite en discussion ; le même problème signalé au jalon suivant se traite en négociation.

La bonne réaction est plus simple et plus inconfortable : demander à voir l’application fonctionner, en direct, sur l’environnement de test. Tout le reste découle de ce qu’on constate à ce moment-là.

Que faire quand on en repère un

Ne pas attendre le suivant. Ces signaux ne se résorbent pas seuls.

Demander un point spécifique, hors comité de pilotage habituel, en posant la question directement : où en sommes-nous réellement, et qu’est-ce qui vous inquiète ?

Un prestataire sérieux répondra franchement — souvent avec soulagement, parce que le sujet était difficile à aborder. C’est le meilleur moment pour arbitrer : réduire le périmètre, décaler une échéance, renforcer l’équipe.

Un prestataire qui reste rassurant face à une question directe vous en dit beaucoup. À ce stade, il vaut mieux faire regarder le projet par un tiers — le coût d’un audit est sans commune mesure avec celui d’un projet qu’on découvre en échec six mois plus tard.