Une commande cadeau doit partir à Lyon, mais la cliente veut sa facture à Paris. Le logiciel ne connaît qu’une adresse. Saisir Lyon corrige le colis et fausse la facture. Saisir Paris fait l’inverse.
Le développeur doit modifier ce que le logiciel sait enregistrer et ce que ses différents traitements lisent. Si le logiciel possède déjà les deux adresses et que la correction attend seulement une autorisation de mise en production, ce travail ne servira à rien. Le défaut a déjà été corrigé.
Les exemples construits dans cette série séparent ces situations en suivant des documents, des heures et des décisions. Le dernier volet part de découvertes réelles d’accès oubliés. J’utilise le mot « dette » au-delà du code pour regrouper ces coûts persistants, sans supposer qu’ils ont tous la même cause.
1. Deux champs dans le formulaire, une seule adresse sur la facture
Dans la boutique fictive, l’ajout d’un champ « facturation » permet d’enregistrer Paris en plus de Lyon. Mais le programme qui imprime la facture lit encore l’adresse historique. Le document continue d’indiquer Lyon.
Il faut modifier ce programme, puis l’export comptable qui utilise la même donnée. Les anciennes commandes, créées avec une seule adresse, doivent aussi continuer à produire leurs documents. Le changement est terminé lorsque le colis, la facture et l’export donnent chacun le résultat attendu, y compris sur ces commandes.
Quand un simple champ devient un chantier déroule les erreurs successives et les quatre cas qui permettent de vérifier la reprise.
2. Trois heures de correction, dix heures de remboursements
Autre cas construit : des frais de livraison sont facturés deux fois. Deux heures suffisent à corriger le code et une heure à le vérifier. La correction est prête le mardi à midi, mais attend le lundi suivant pour être mise en production.
Avec cinquante commandes concernées chaque jour et deux minutes par remboursement, ces six jours ajoutent dix heures de support. Diviser le temps de développement par deux ne change ni le créneau de livraison ni ces remboursements.
Une correction terminée mardi, livrée la semaine suivante suit la chronologie et les validations qui imposent cette attente.
3. Une automatisation attend, un doublon explique le désaccord
Un rapport commercial fictif demande une heure de préparation chaque vendredi. La proposition d’automatisation attend quatre semaines sans décision. Quatre heures de préparation et deux heures de discussion ont été consommées, sans essai produit.
L’objection à l’automatisation est pourtant vérifiable : une affaire apparaît deux fois dans l’export. Additionner les lignes donne 3 200 €, compter une fois chaque affaire donne 2 000 €. Ce défaut définit le test de l’essai. Un fichier parallèle peut être comparé au rapport manuel sans remplacer celui-ci.
Quand chaque initiative attend une autorisation distingue l’autorisation d’effectuer cet essai de la décision d’abandonner le traitement manuel.
4. Le site répond, deux factures restent sans envoi
Dans le lot fictif de l’article sur l’outillage, 120 commandes payées ont produit 120 factures. Le prestataire d’envoi a accepté 118 messages, puis refusé les deux suivants. Le contrôle de disponibilité continue d’ouvrir avec succès la page d’accueil.
Comparer les identifiants des factures attendues à ceux des envois acceptés retrouve les deux documents manquants. Envoyer un nouvel email de test après réparation ne les traite pas. Il faut reprendre ces deux factures et suivre séparément leur résultat.
Le site répond, mais les factures n’arrivent plus suit le lot jusqu’à cette reprise, avec les limites de chaque vérification.
5. Le service est abandonné, son code reste dans le site
J’ai retiré une intégration Brevo devenue inutilisée d’un site corporate. Son code était toujours présent. L’abandon de l’outil n’avait pas supprimé son intégration technique.
J’ai aussi retrouvé un domaine expiré dans une liste de sources autorisées. Le nom était proposé à la vente pour 50 dollars lors de ma recherche. Cette autorisation ne prouvait pas qu’un script y était chargé ni qu’une attaque avait eu lieu. Elle obligeait à examiner une confiance accordée à un nom susceptible de changer de propriétaire.
Les accès qui survivent aux outils sépare les observations de terrain des vérifications nécessaires sur les scripts, les domaines et les permissions.
La correction dépend de ce qui reste à faire
Ces cas produisent des fins de chantier différentes. Pour les adresses, la facture et le colis doivent indiquer deux destinations distinctes. Pour la correction bloquée, une autorisation doit devenir une mise en production. Pour les factures non envoyées, chaque document en attente doit avoir été repris ou rester explicitement à traiter.
Un budget de développement supplémentaire ne remplace pas l’autorisation manquante. Un nouveau contrôle de disponibilité ne vérifie pas l’envoi des factures. Le nom donné à la dette importe moins que l’erreur ou l’attente que l’intervention doit supprimer.
Chez Gridky, plusieurs travaux ont été réunis dans le Drynuary : suspendre les nouvelles demandes, corriger les bugs et imposer des tests au code touché. L’équipe a ensuite été réunifiée, et mon tri manuel des exceptions chaque matin a disparu. Ce sont ces changements constatés qui donnent son contenu au récit.