Que ne laisse-t-on jamais faire seul à un agent de codage ?
Seize refus. Une liste de « jamais » ne se discute pas au cas par cas : c'est ce qui la rend tenable un jour de fatigue.
Les seize « jamais »
1. Jamais laisser une machine agir seule sur ce qui ne se rattrape pas
Supprimer, envoyer, débiter, publier n’ont pas de retour arrière. Une erreur y devient définitive en quelques secondes.
Le prétexte qui le fait céder : « C’est une tâche automatique, elle est fiable. »
2. Jamais modifier un test pour faire passer la chaîne
Le test est le contrat. Le changer pour qu’il accepte le code revient à déplacer la cible après le tir.
Le prétexte qui le fait céder : « Le test était mal écrit de toute façon. »
3. Jamais écrire un secret dans le code, même en exemple
Il part dans l’historique, dans les copies, chez tous ceux qui ont lu le dépôt. Il ne se retire jamais vraiment.
Le prétexte qui le fait céder : « C’est une clé de test, je la remplacerai. »
4. Jamais accepter un livrable sans exécuter sa preuve soi-même
« C’est fait » est la réponse par défaut d’un agent, et elle est compatible avec un travail non fait.
Le prétexte qui le fait céder : « Il a montré la sortie, ça a l’air bon. »
5. Jamais faire vérifier un travail par l’agent qui l’a produit
Il défendra son travail. On n’obtient pas une correction mais une justification, et elle est convaincante.
Le prétexte qui le fait céder : « Il connaît le mieux le code, autant lui demander. »
6. Jamais poser une garde uniquement dans l’interface
Le code de l’écran s’exécute chez l’utilisateur, qui peut le lire et le contourner. Cacher n’est pas interdire.
Le prétexte qui le fait céder : « Le bouton n’est pas visible pour eux. »
7. Jamais travailler sur les données réelles pour essayer quelque chose
Une commande de trop y détruit ce que personne ne peut reconstruire, et l’erreur ne prévient pas.
Le prétexte qui le fait céder : « C’est plus rapide, et je fais attention. »
8. Jamais mettre en ligne sans avoir essayé de revenir en arrière
Une procédure de retour jamais exécutée est une hypothèse. On la découvre fausse au pire moment.
Le prétexte qui le fait céder : « La procédure est écrite, ça suffit. »
9. Jamais considérer une sauvegarde comme existante avant de l’avoir restaurée
Une sauvegarde illisible se comporte exactement comme une sauvegarde valide, jusqu’au jour où on en a besoin.
Le prétexte qui le fait céder : « L’hébergeur sauvegarde automatiquement. »
10. Jamais afficher un état vide là où il y a une panne
Une panne présentée comme une absence de données est le pire mode de défaillance : elle ne réveille personne.
Le prétexte qui le fait céder : « Il n’y avait rien à afficher de toute façon. »
11. Jamais élargir une interception d’erreur pour faire disparaître un message
Le message était l’information. Sans lui, la panne existe toujours mais plus personne ne la voit.
Le prétexte qui le fait céder : « Ça polluait les journaux. »
12. Jamais laisser un agent choisir la technologie
Il prendra la plus représentée dans ses données, ni la plus adaptée au projet, ni celle que vous saurez maintenir.
Le prétexte qui le fait céder : « Il connaît mieux l’état de l’art que moi. »
13. Jamais accepter une différence qu’on n’a pas regardée fichier par fichier
La liste des fichiers touchés révèle en dix secondes ce que la lecture du code ne montrerait qu’en une heure.
Le prétexte qui le fait céder : « C’était trop long à relire. »
14. Jamais laisser une dette sans échéance
Une dette sans date devient invisible, puis structurelle. « Plus tard » signifie « jamais » et tout le monde le sait.
Le prétexte qui le fait céder : « On y reviendra après la mise en ligne. »
15. Jamais promettre ce qu’aucun mécanisme ne tient
Une politique qui annonce une destruction que rien n’exécute est une faute écrite de votre main, et opposable.
Le prétexte qui le fait céder : « C’est ce que tout le monde met dans ses conditions. »
16. Jamais faire vérifier par une seconde machine ce que vous devez constater vous-même
Deux modèles partagent leurs angles morts : la confirmation du second ne prouve rien, elle double la première impression. Une vérification est un fait qu’on constate, pas un avis qu’on collectionne.
Le prétexte qui le fait céder : « J’ai demandé à un autre modèle, il est d’accord. »
Ces pages accompagnent la formation directeur de chantier logiciel. Dix semaines. Une session par semaine. Une mission par semaine. Un seul projet : le vôtre.