Dans une boutique en ligne fictive, les paniers contenant deux colis sont facturés deux fois pour la livraison, alors que le tarif annoncé couvre les deux. Le support rembourse le trop-perçu.
La correction prend deux heures le mardi matin, puis une heure de tests et de relecture. À midi, elle est prête. Le processus de l’entreprise impose un passage au comité du jeudi et une mise en production le lundi suivant à midi.
Trois heures de travail, puis six jours d’attente. Les horaires et les volumes de cet article sont des hypothèses de démonstration. Ils permettent de calculer ce que le délai laisse à la charge du support, même lorsque le ticket de développement est terminé.
Le ticket passe à « terminé » le mardi à midi
Voici la chronologie retenue pour ce cas.
| Moment | Événement | Ce que voit le client |
|---|---|---|
| Mardi, 9 h à 11 h | Correction du calcul | Frais encore facturés deux fois |
| Mardi, 11 h à 12 h | Tests et relecture | Erreur toujours présente |
| Jeudi, 14 h | Comité de validation | Erreur toujours présente |
| Lundi suivant, 12 h | Mise en production | Frais facturés une seule fois |
Le suivi du développement s’arrête à la deuxième ligne. Le support doit travailler jusqu’à la quatrième. Le comité valide la correction sans demander de modification supplémentaire dans notre scénario.
Les réunions quotidiennes ne changent aucune de ces dates. Tout le monde sait que la correction est prête, mais l’équipe présente au point du matin n’a pas le droit de la déployer. Ajouter un compte rendu donnerait une trace de plus du même blocage.
Six jours ajoutent trois cents remboursements
L’exemple suppose cinquante commandes concernées par jour pendant ces six jours, et deux minutes de traitement par remboursement.
50 commandes × 6 jours × 2 minutes = 600 minutes, soit 10 heures de support.
Ce calcul ne compte ni les réclamations supplémentaires ni le temps des clients. Il ne transforme pas non plus le remboursement en perte commerciale : le trop-perçu devait de toute façon être rendu. Il isole dix heures de travail manuel après la fin de la correction.
Diviser par deux les deux heures de développement aurait économisé une heure le mardi. Avec le même comité et le même créneau, la correction serait quand même arrivée le lundi. Les trois cents remboursements seraient restés à faire.
Le délai de déploiement mérite donc un arbitrage explicite. Dans ce cas, six jours d’attente coûtent dix heures de support. Un risque qui justifie ce délai doit être examiné en regard de ce coût, au lieu de disparaître derrière la formule « c’est la procédure ».
La validation peut-elle se faire le mardi ?
Pour répondre, il faut préciser ce que le comité vérifie. Dans notre exemple, le dossier comprend le panier à deux colis qui reproduit l’erreur, le montant attendu, le résultat après correction et la relecture d’un second développeur. Le panier à un seul colis est aussi testé pour vérifier que son tarif ne change pas.
Si le comité reçoit ces mêmes éléments le jeudi et les accepte sans demander d’autre preuve, les deux jours écoulés n’ont ajouté aucune vérification. Une personne habilitée pourrait examiner le dossier le mardi. Le contrôle resterait présent, mais ne dépendrait plus de la réunion hebdomadaire.
La mise en production a ses propres contraintes : une personne disponible pour la suivre et une procédure prévue si la nouvelle version échoue. Si elles ne peuvent être réunies que le lundi, l’attente a une cause identifiée. C’est alors la capacité à livrer qu’il faut traiter, plutôt que la vitesse des développeurs.
Le résultat attendu est une date de livraison différente
Une modification du processus n’aura servi à ce cas que si elle permet de mettre la correction en ligne avant le lundi suivant, avec les vérifications requises. Renommer les colonnes du tableau ou raccourcir le point du matin ne change pas le calcul des remboursements.
La comparaison porte sur les mêmes événements : fin de la relecture, autorisation de déployer, mise en production. Elle indique où le temps a été gagné et si une étape de contrôle a été supprimée ou simplement avancée.
Cette démonstration n’établit pas que tous les comités sont inutiles. Elle montre qu’ici, le développement supplémentaire n’est pas la ressource manquante. La correction existe déjà. Ce qui manque est une décision de livraison prise avant que le support ait effectué trois cents remboursements de plus.
L’article Quand chaque initiative attend une autorisation examine un autre cas : une amélioration qui ne peut même pas commencer. Tous deux font partie des cinq visages de la dette technique.