La qualité est la seule variable

Le travail d’un chef de projet consiste à équilibrer quatre variables : périmètre, délais, coût et qualité. Le triangle classique des contraintes dit qu’on peut en optimiser deux, mais pas les quatre. Vous le voulez rapide et bon marché ? La qualité en pâtit. Vous le voulez bon et rapide ? Le coût augmente. Ce triangle est un modèle mental utile dans les environnements aux ressources limitées.

Je n’opère pas dans un environnement aux ressources limitées. Je travaille avec un agent IA capable de produire du code à la vitesse de l’inférence, une fenêtre de contexte qui contient une base de code entière, et un coût de session en dollars, pas en salaires. Le triangle des contraintes s’effondre.

Quand l’agent peut implémenter une fonctionnalité en quelques minutes, la question n’est pas « peut-on se permettre de bien faire ? » La question est « pourquoi ferait-on mal ? »

L’élimination

Retirez le temps de l’équation. Non pas « combien de temps cela prendra-t-il ? » mais « à quoi cela devrait-il ressembler une fois terminé ? » La première question optimise la rapidité de livraison. La seconde optimise l’artefact.

Retirez le coût de l’équation. Une session qui produit du code correct, propre et bien testé coûte autant qu’une session qui produit du code expédié, brouillon et non testé. Le API facture le même prix par token, quelle que soit la qualité. Le coût marginal de bien faire est nul.

Retirez l’effort de l’équation. L’agent ne se fatigue pas. La centième fonction est écrite avec la même capacité que la première. Aucune courbe de fatigue humaine ne justifie les raccourcis en fin de session. La qualité du résultat est limitée par la qualité de l’instruction et la qualité du contexte environnant, pas par le nombre d’heures écoulées.

Que reste-t-il après avoir éliminé le temps, le coût et l’effort ? La qualité. La qualité est la seule variable restante.

Ce que cela signifie en pratique

Quand la qualité est la seule variable, plusieurs décisions d’ingénierie courantes deviennent évidentes :

Écrivez le test. Le débat sur l’opportunité d’écrire un test pour une fonction spécifique disparaît. L’agent écrit le test en quelques secondes. Le coût marginal est nul. Le bénéfice marginal est une vérification permanente. Ne pas écrire le test, c’est choisir d’accepter moins de qualité sans aucune économie.

Corrigez le code adjacent. Lorsqu’on corrige un bug, le code environnant présente souvent des problèmes liés : nommage incohérent, gestion d’erreurs manquante, patterns obsolètes. Dans un environnement contraint par le temps, on corrige le bug et on laisse le code adjacent pour « plus tard ». Quand la qualité est la seule variable, on corrige tout ce qu’on touche. Plus tard n’arrive jamais. Maintenant est gratuit.

Utilisez la bonne abstraction. Un hack rapide résout le problème immédiat. La bonne abstraction résout la catégorie de problèmes. Dans un environnement contraint par le temps, le hack est livré aujourd’hui et l’abstraction n’est jamais livrée. Quand l’agent peut implémenter l’un ou l’autre dans la même session, le hack n’a aucun avantage. Choisissez l’abstraction.

Lisez avant d’écrire. Dans un environnement contraint par le temps, les ingénieurs modifient parfois du code qu’ils n’ont pas entièrement lu, en s’appuyant sur une compréhension locale. Quand l’agent peut lire le fichier entier, comprendre les patterns et modifier avec un contexte complet, il n’y a aucune raison d’opérer avec une compréhension partielle. Lisez le fichier en entier. Comprenez le pattern. Puis écrivez.

Ne reportez pas. TODO, FIXME et HACK sont des marqueurs de qualité différée. Dans un environnement contraint par le temps, le report est rationnel : on corrigera plus tard quand on aura le temps. Quand la qualité est la seule variable, le report est irrationnel. L’agent est là. Le contexte est chargé. La correction coûte autant maintenant que plus tard. Faites-le maintenant.

Le principe Jiro

Jiro Ono prépare des sushis depuis plus de 70 ans. Son restaurant a trois étoiles Michelin et dix places. Il n’a changé ni le menu ni la méthode. Il a affiné la méthode chaque jour pendant 70 ans.

Quand quelqu’un demande à Jiro si un sushi est assez bon, la réponse ne repose jamais sur l’affluence du restaurant, le nombre de clients qui attendent, ou le prix du poisson. La réponse repose sur le fait que le sushi répond ou non à son exigence. L’exigence est absolue. Les circonstances sont hors sujet.

Tel est le principe appliqué à l’ingénierie : l’exigence porte sur le code, pas sur le sprint. Une fonction est soit correcte, propre et bien testée, soit elle ne l’est pas. La date limite ne change pas l’évaluation. Le budget ne change pas l’évaluation. La seule question est de savoir si l’artefact répond à l’exigence.

Les agents IA rendent ce principe praticable pour la première fois dans l’ingénierie logicielle. Avant les agents, le principe Jiro était un idéal. Le coût humain de la perfection était trop élevé. Chaque raccourci avait une justification rationnelle : on livre jeudi, le budget est épuisé, l’ingénieur est à bout. Avec les agents, le coût de bien faire est identique au coût de mal faire. Les raccourcis perdent leur justification.

Le contrôle de fierté

Après chaque modification non triviale, je pose cinq questions :

1. Un ingénieur senior respecterait-il cette approche ?
2. Le code s’explique-t-il de lui-même ?
3. Les cas limites sont-ils gérés ?
4. Est-ce le bon niveau de simplicité ?
5. Ai-je laissé la base de code en meilleur état que je ne l’ai trouvée ?

Ces questions ne portent pas sur la correction. La porte de preuves gère la correction. Le contrôle de fierté gère l’artisanat. Du code correct que personne ne veut maintenir échoue à la question 1. Du code astucieux qui nécessite des commentaires pour être compris échoue à la question 2. Du code qui gère le cas nominal mais ignore le chemin d’erreur échoue à la question 3.

La question 4 est la plus difficile. « Le bon niveau de simplicité » ne signifie pas « le plus simple possible ». Un hack d’une ligne est plus simple qu’une abstraction correcte, mais le hack est au mauvais niveau de simplicité si le problème se reproduira. La bonne simplicité est la complexité minimale qui résout le problème réel sans résoudre des problèmes futurs hypothétiques.

La question 5 porte sur la trajectoire. Chaque session devrait laisser la base de code dans un meilleur état qu’elle ne l’a trouvée. Pas seulement les fichiers spécifiquement modifiés, mais le contexte environnant : tests mis à jour, imports nettoyés, commentaires corrigés, code mort supprimé. L’exigence n’est pas « ai-je terminé la tâche ? » L’exigence est « le projet est-il meilleur parce que j’étais là ? »

L’objection

L’objection évidente : la vitesse compte. Livrer compte. Une base de code parfaite qui n’est jamais livrée est pire qu’une base de code brouillonne qui résout un vrai problème.

L’objection est valable dans un monde où qualité et vitesse sont inversement corrélées. Dans un monde où un agent IA produit un résultat de haute qualité à la même vitesse qu’un résultat de basse qualité, la corrélation se brise. Qualité et vitesse deviennent des variables indépendantes. On peut avoir les deux.

Le compromis restant est l’attention, pas le temps. Lire le fichier entier demande de l’attention. Exécuter la porte de preuves demande de l’attention. Appliquer le contrôle de fierté demande de l’attention. Le temps de l’agent est gratuit. Votre attention est finie.

La qualité est la seule variable, mais l’attention est la contrainte sur la qualité. La solution n’est pas d’abaisser l’exigence. La solution est de construire une infrastructure qui réduit le coût attentionnel du maintien de l’exigence : des hooks qui interceptent automatiquement les erreurs courantes, des skills qui encodent les flux de travail qualité, et des systèmes de mémoire qui transportent le contexte d’une session à l’autre pour ne pas re-dériver les décisions.

C’est le contexte composé au service de la qualité. Chaque élément d’infrastructure réduit le coût attentionnel de la session suivante. Au bout de suffisamment de sessions, l’exigence se maintient d’elle-même.

FAQ

Ce principe s’applique-t-il à tous les projets logiciels ?

Le principe s’applique le plus directement aux projets où des agents IA réalisent l’implémentation. Dans les projets entièrement implémentés par des humains, le temps et le coût restent des contraintes réelles. Le principe devient d’autant plus applicable que la capacité des agents augmente et que le temps d’implémentation humaine diminue.

Qu’en est-il du prototypage ?

Les prototypes sont jetables par définition. L’exigence de qualité pour un prototype est « répond-il à la question que nous investiguons ? » Si la réponse est oui, le prototype a rempli sa fonction, indépendamment de la qualité du code. Le principe s’applique au code qui persistera, pas au code qui sera jeté.

N’est-ce pas simplement du perfectionnisme ?

Le perfectionnisme est une exigence infinie que rien ne satisfait. La qualité est une exigence finie que la porte de preuves définit : correct, propre, testé, sans régression, et résolvant le problème réel. Atteindre l’exigence est réalisable. La dépasser est inutile. L’exigence est élevée mais pas infinie.

Comment gérez-vous la dette technique ?

En ne la créant pas. La dette technique est de la qualité différée. Quand la qualité est la seule variable, le report perd sa justification. L’agent est disponible maintenant. La correction coûte autant maintenant que plus tard. Il n’y a pas de taux d’intérêt sur la dette technique produite par un agent, car il n’y a aucune raison de la contracter.

Sources

La philosophie décrite ici s’inspire de la tradition Shokunin de l’artisanat japonais et de l’expérience de production documentée à travers la série AI Engineering. Implémentations spécifiques référencées :

• Porte de preuves : six critères de vérification de complétude
• Contrôle de fierté : cinq questions pour évaluer l’artisanat
• Système de hooks : 84 hooks comme infrastructure qualité (Every Hook Is a Scar)
• Contexte composé : infrastructure qui réduit le coût attentionnel de la qualité (Compound Context)