Une deadline se négocie sur le périmètre, jamais sur la qualité
Ce qu'on sacrifie quand on accepte de livrer plus vite, et pourquoi ce n'est jamais la partie qu'on croit.
La demande arrive toujours de la même façon. Le produit est prêt à 80 %, la date est déjà annoncée au client, et on demande si « on peut serrer un peu ».
La réponse honnête est oui. On peut toujours serrer. La vraie question est : sur quoi.
Il n'y a que trois variables
Un projet tient sur trois axes : le périmètre, le délai et la qualité. Fixer les trois est impossible — c'est de l'arithmétique, pas une posture d'ingénieur.
Quand la date est imposée, il reste deux leviers. Le périmètre est visible : tout le monde comprend qu'une fonctionnalité passe à la version suivante. La qualité est invisible : personne ne voit qu'on a sauté les tests, jusqu'au jour où tout le monde le voit.
C'est précisément pour ça que la qualité est le levier par défaut. Elle ne se défend pas toute seule.
Ce que « couper dans la qualité » veut dire concrètement
Rien d'abstrait. Voilà ce qui saute en premier, dans l'ordre :
- Les tests des cas limites — ceux qui ne se déclenchent qu'en production.
- La gestion des erreurs — on renvoie un 500 générique au lieu d'un message utile.
- La revue de code — « on regardera après la livraison ».
- La documentation de la décision — six mois plus tard, personne ne sait pourquoi c'est fait comme ça.
Les trois premières coûtent des incidents. La quatrième coûte l'équipe : un développeur qui ne comprend pas le code qu'il maintient finit par le réécrire, ou par partir.
La formulation qui fonctionne
Je ne dis jamais « c'est impossible ». Je dis :
« Pour cette date, voilà ce qui entre : A, B et C. D et E passent à la version suivante. Si D est indispensable, alors c'est B qui sort. »
Cette phrase transforme un refus en décision. Elle rend le coût visible et elle laisse le choix à la bonne personne — celle qui porte la responsabilité commerciale.
Et surtout, elle est vérifiable. Si on m'a dit oui, c'est écrit. Si on m'a dit non, c'est écrit aussi.
Ce qu'on écrit
Toute décision de report tient en trois lignes dans le backlog :
Reporté : export comptable PDF
Raison : périmètre v1 tenu pour la date du 12/09
Coût : les clients exportent en CSV en attendant
Revue : sprint 24Sans cette trace, le report devient un oubli. Et un oubli, six mois plus tard, s'appelle de la dette technique — alors que c'était une décision assumée.
Le cas où j'ai eu tort
Sur une migration de données métier, j'ai accepté de raccourcir la phase de vérification. L'argument me semblait bon : les données venaient d'un système qu'on connaissait, le format était stable depuis des années.
Il l'était. Sauf pour 0,4 % des enregistrements, saisis à la main entre 2014 et 2016, avec une virgule décimale au lieu d'un point.
La migration a fonctionné. Les montants étaient faux. Nous l'avons découvert trois semaines plus tard, à la clôture mensuelle.
Depuis, la vérification n'est plus une phase — c'est un critère de fin. Elle ne peut pas être coupée, parce qu'elle n'est plus une étape séparée qu'on peut retirer du planning.
C'est la seule façon vraiment fiable de protéger la qualité : ne pas la laisser être une ligne du planning.
À lire ensuite
Tenir une base de code qu'on n'a pas écrite
Ce qu'on fait les trois premières semaines quand on hérite d'un système en production, avant de toucher à une seule ligne.
Recruter un backend sans lui demander d'inverser un arbre binaire
Un exercice tiré du produit, corrigé à deux, avec une grille écrite avant l'entretien. Ce qui change, et ce que ça coûte.
FastAPI en production : ce qui compte vraiment
Cinq réglages qu'on ne voit dans aucun tutoriel et qui font la différence entre une API qui tourne et une API qu'on peut exploiter.