Les vérités logicielles de Joel Spolsky pour le développement assisté par l'IA

Pourquoi ces vérités importent encore quand l'IA écrit du code rapidement

L'IA peut produire du code qui a l'air de fonctionner en quelques minutes. Ça change le rythme d'un projet, mais pas ce qui fait le succès d'un logiciel. Les leçons des « vérités logicielles » de Joel Spolsky n'ont jamais vraiment porté sur la vitesse de frappe. Elles portent sur le jugement, les boucles de rétroaction et l'évitement de la complexité auto-infligée.

Ce qui a changé, c'est le coût de création du code. Vous pouvez demander trois approches, cinq variantes ou une réécriture complète et obtenir quelque chose instantanément. Ce qui n'a pas changé, c'est le coût de choisir la bonne approche, de la vérifier et d'en vivre pendant des mois. Le temps gagné à l'écriture se déplace souvent vers la décision de ce que vous vouliez dire, la validation des cas limites et la garantie que la victoire rapide d'aujourd'hui ne devienne pas la taxe de maintenance de demain.

La correction, la sécurité et la maintenabilité prennent toujours du temps réel parce qu'elles reposent sur des preuves, pas sur la confiance. Un flux de connexion n'est pas terminé parce que ça compile. Il est terminé quand il rejette de manière fiable les mauvaises entrées, gère des états étranges et ne fuit pas de données. L'IA peut sembler certaine tout en manquant un détail crucial, comme une vérification de permissions sur un endpoint ou une condition de concurrence dans la mise à jour d'un paiement.

L'IA est la plus utile quand vous la traitez comme une machine de brouillon rapide. Elle excelle dans le boilerplate, les motifs répétitifs, les refactorings rapides et l'exploration d'options que vous pouvez comparer côte à côte. Bien utilisée, elle compresse la phase de « page blanche ».

L'IA nuit le plus quand vous lui donnez des objectifs vagues et acceptez le résultat tel quel. Les mêmes schémas d'échec réapparaissent : hypothèses cachées (règles métier non dites), chemins non testés (gestion d'erreurs, retries, états vides), erreurs confiantes (du code plausible mais subtilement faux) et solutions « futées » difficiles à expliquer plus tard.

Si le code devient bon marché, la nouvelle ressource rare est la confiance. Ces vérités importent parce qu'elles protègent cette confiance : avec les utilisateurs, avec les coéquipiers et avec votre futur moi.

Les tests restent le goulot d'étranglement, et c'est une bonne chose

Quand l'IA peut générer une fonctionnalité en quelques minutes, il est tentant de considérer les tests comme la partie lente à éliminer. Le point de Spolsky reste valable : la partie lente est là où se trouve la vérité. Le code se produit facilement. Le comportement correct ne l'est pas.

Un changement utile est de considérer les tests comme des exigences exécutables. Si vous ne pouvez pas décrire le comportement attendu de manière vérifiable, vous n'avez pas fini de réfléchir. Dans le travail assisté par l'IA, cela compte plus qu'avant, car le modèle peut produire avec assurance quelque chose qui est légèrement faux.

Commencez les tests par ce qui ferait le plus de mal s'il cassait. Pour la plupart des produits, ce sont les flux principaux (inscription, paiement, sauvegarde, export), les permissions (qui peut voir, éditer, supprimer) et l'intégrité des données (pas de doublons, totaux corrects, migrations sûres). Ensuite, couvrez les bords qui causent des incidents nocturnes : entrées vides, textes longs, fuseaux horaires, retries et frontières externes instables comme les paiements, les emails et les téléchargements de fichiers.

L'IA est excellente pour proposer des cas de test, mais elle ne sait pas ce que vous avez réellement promis aux utilisateurs. Utilisez-la comme partenaire de brainstorming : demandez-lui des cas limites manquants, des scénarios d'abus et des combinaisons de permissions. Puis faites le travail humain : faites correspondre la couverture à vos règles réelles et supprimez les tests qui ne « testent que l'implémentation » au lieu du comportement.

Rendez les échecs exploitables. Un test qui échoue doit indiquer ce qui a cassé, pas vous envoyer en quête d'indices. Gardez les tests petits, nommez-les comme des phrases et faites des messages d'erreur spécifiques.

Un petit exemple

Supposons que vous construisiez une simple application de « notes d'équipe » avec l'aide de l'IA. Les écrans CRUD apparaissent vite. Le risque de correction n'est pas l'interface. C'est le contrôle d'accès et les règles de données : un utilisateur ne doit pas voir les notes d'une autre équipe, les éditions ne doivent pas écraser des modifications plus récentes, et la suppression d'une note ne doit pas laisser des pièces jointes orphelines. Les tests qui verrouillent ces règles sembleront le goulot d'étranglement, mais ils sont aussi votre filet de sécurité.

Quand les tests sont le goulot d'étranglement, cela force la clarté. Cette clarté empêche le code rapide de se transformer en bugs rapides.

La simplicité bat la ruse, surtout avec l'IA en boucle

Une des vérités les plus durables est que le code simple l'emporte sur le code astucieux. L'IA incite à accepter des abstractions sophistiquées parce qu'elles arrivent polies et rapides. Le coût apparaît plus tard : plus d'endroits où des bugs peuvent se cacher, plus de fichiers à parcourir et plus de moments « mais qu'est-ce que ça fait ? ».

Quand le code est bon marché, c'est la complexité que vous payez. Un petit design ennuyeux est plus facile à tester, à modifier et à expliquer. Cela compte encore plus quand le premier jet vient d'un modèle qui peut sembler sûr tout en étant subtilement erroné.

Une règle pratique est de garder fonctions, composants et modules assez petits pour qu'un coéquipier puisse les relire en quelques minutes, pas en heures. Si un composant React a besoin de multiples hooks personnalisés, d'une machine à états locale et d'une couche générique de « rendu intelligent », faites une pause et demandez si vous résolvez un vrai problème ou si vous acceptez une architecture parce que l'IA l'a proposée.

Quelques « tests de simplicité » aident à recadrer :

• Un nouveau coéquipier peut-il comprendre le flux principal en une seule session ?
• Pourriez-vous supprimer cette abstraction et la remplacer par du code clair sans perdre en lisibilité ?
• Y a-t-il un endroit évident pour corriger un bug, ou cinq ?
• Chaque partie a-t-elle un seul rôle que vous pouvez énoncer en une phrase ?

Les prompts comptent ici. Si vous demandez « la meilleure architecture », vous obtiendrez souvent quelque chose de sur-construit. Demandez des contraintes qui poussent vers moins d'éléments mobiles. Par exemple : utilisez l'approche la plus simple avec le moins de fichiers ; évitez les nouvelles abstractions sauf si elles suppriment la duplication dans trois endroits ou plus ; préférez du code explicite aux helpers génériques.

Un exemple concret : vous demandez à l'IA d'ajouter un contrôle d'accès basé sur les rôles à une page d'admin. La version futée introduit un framework de permissions, des décorateurs et un DSL de configuration. La version simple vérifie le rôle utilisateur en un seul endroit, protège les routes en un seul point et logge les accès refusés. La version simple est plus facile à relire, à tester et plus difficile à mal interpréter.

Si vous construisez dans un outil de type chat comme Koder.ai, la simplicité rend aussi les snapshots et le rollback plus utiles. De petits changements évidents sont plus faciles à comparer, conserver ou annuler.

Recrutement : vous avez besoin d'éditeurs et de décideurs, pas de dactylographes

Quand le code est facile à produire, la compétence rare est de choisir ce qui doit exister et de s'assurer que c'est correct. Le vieil adage « embauchez de bons programmeurs » s'applique toujours, mais le rôle évolue. Vous n'embauchez pas quelqu'un pour taper plus vite. Vous embauchez quelqu'un pour juger, affiner et défendre le produit.

Les personnes les plus précieuses dans le développement assisté par l'IA partagent généralement quatre traits : le jugement (ce qui compte), le goût (ce à quoi le bon ressemble), l'aptitude au débogage (trouver la cause réelle) et la communication (clarifier les compromis). Elles peuvent prendre une fonctionnalité écrite par l'IA qui « marche à peu près » et en faire quelque chose de digne de confiance.

Une meilleure interview : améliorer un changement généré par l'IA

Au lieu de demander une solution parfaite depuis zéro, donnez aux candidats une pull request générée par l'IA (ou un diff collé) avec quelques problèmes réalistes : noms peu clairs, un cas limite caché, tests manquants et une petite erreur de sécurité.

Demandez-leur d'expliquer en langage simple ce que le code cherche à faire, d'identifier les parties à risque les plus élevées, de proposer des corrections et d'ajouter (ou de décrire) des tests qui attraperaient les régressions. Si vous voulez un signal fort, demandez aussi comment ils changeraient les instructions pour que la prochaine tentative par l'IA soit meilleure.

Cela révèle comment ils pensent dans des conditions réelles : code imparfait, temps limité et besoin de prioriser.

Le super-pouvoir : savoir dire « non »

L'IA parle souvent avec assurance. Les bonnes recrues savent prendre du recul. Elles savent dire non à une fonctionnalité qui ajoute de la complexité, non à un changement qui affaiblit la sécurité et non au déploiement sans preuves.

Un signal concret est leur réponse à « Vous fusionnez ça ? ». Les bons candidats ne répondent pas par une impression. Ils prennent une décision et donnent une courte liste de changements requis.

Exemple : vous demandez une mise à jour d'accès « rapide » et l'IA suggère de parsemer des checks dans les handlers. Un bon candidat rejette cette approche et propose une couche d'autorisation claire, plus des tests pour les chemins admin et non-admin.

Enfin, établissez des standards partagés afin que l'équipe édite la sortie IA de la même manière. Keep it simple : une définition du « done », des attentes de revue cohérentes et une baseline de tests.

Specs et planification : des prompts plus clairs commencent par une pensée plus claire

Quand l'IA peut générer beaucoup de code en minutes, il est tentant de sauter la réflexion et d'itérer. Ça marche pour des démos. Ça casse quand vous avez besoin de correction, de comportement prévisible et de moins de surprises.

Un bon prompt est souvent un petit spec déguisé. Avant de demander du code, transformez l'objectif vague en quelques critères d'acceptation et non-objectifs explicites. Cela empêche l'IA (et votre équipe) d'élargir silencieusement le périmètre.

Gardez le spec petit mais précis. Vous n'écrivez pas un roman. Vous fixez des limites autour de :

• Entrées : ce qui arrive (champs, formats, cas limites)
• Sorties : ce qui doit ressortir (avec des exemples)
• Erreurs : ce qui peut mal se passer et comment répondre
• Contraintes : performance, confidentialité, dépendances ou zones « ne pas modifier »
• Non-objectifs : ce que vous ne faites pas dans ce changement

Définissez « fini » avant la génération, pas après. « Fini » doit être plus que « ça compile » ou « l'UI a l'air correcte ». Incluez les attentes de test, la compatibilité arrière et ce qui sera surveillé après la mise en production.

Exemple : vous voulez « ajouter la réinitialisation du mot de passe ». Un spec plus clair pourrait dire : l'utilisateur demande la réinitialisation par email ; les liens expirent au bout de 15 minutes ; le même message s'affiche que l'email existe ou non ; limitation par IP ; journaliser les tentatives sans stocker les tokens en clair. Non-objectif : pas de refonte de la page de connexion. Maintenant votre prompt a des garde-fous et les revues sont plus simples.

Tenez un journal léger des décisions. Un paragraphe par décision suffit. Notez pourquoi vous avez choisi une approche et pourquoi vous avez rejeté d'autres alternatives. Quand quelqu'un demandera « pourquoi c'est comme ça ? » deux semaines plus tard, vous aurez une réponse.

Un workflow pratique assisté par IA que vous pouvez répéter

Le plus grand changement avec l'IA est que produire du code devient facile. La partie difficile est de décider ce que le code doit faire et de prouver qu'il le fait.

Commencez par écrire l'objectif et les contraintes en langage clair. Indiquez ce qui ne doit jamais arriver, ce qui peut être lent et ce qui est hors périmètre. Une bonne contrainte est testable : « Aucun utilisateur ne doit voir les données d'un autre utilisateur », ou « Les totaux doivent correspondre à l'export financier au centime ».

Avant de demander du code, demandez un design simple et les compromis. Vous voulez que l'IA montre son raisonnement sous une forme que vous pouvez juger : ce qu'elle va stocker, ce qu'elle va valider et ce qu'elle va logger. Si elle propose quelque chose de futé, recadrez et demandez la version la plus simple qui respecte les contraintes.

Une boucle répétable ressemble à ceci :

1. Rédiger une courte énonciation du problème et 3 à 5 checks d'acceptation clairs (pass/échec).
2. Demander un plan minimal : modèle de données, fonctions clés et ce qui pourrait mal se passer.
3. Générer un petit changement à la fois (un endpoint, un écran, une migration), pas un dump d'application complet.
4. Relire comme un éditeur : lire les diffs, exécuter les tests, essayer les cas d'échec, puis demander des corrections.
5. Déployer en sécurité : feature flag ou déploiement restreint, surveiller logs et métriques, et être prêt à revenir en arrière.

Voici un petit scénario : vous ajoutez un « statut de remboursement » à un écran de commande. L'IA peut générer l'UI rapidement, mais la correction vit dans les cas limites. Et si le remboursement est partiel ? Et si le prestataire de paiement retry une webhook ? Écrivez d'abord ces cas, puis implémentez une tranche (colonne de base + validation) et vérifiez-la avec des tests avant d'aller plus loin.

Si vous utilisez Koder.ai, des fonctions comme le mode planification, les snapshots et le rollback s'intègrent naturellement dans cette boucle : planifier d'abord, générer par tranches et capturer un point de restauration sûr pour chaque changement significatif.

Erreurs courantes quand coder avec l'IA paraît trop facile

Quand la génération de code est rapide, on a tendance à considérer le code lui-même comme le produit fini. Ce n'est pas le cas. Le produit est le comportement : l'application fait ce qu'il faut, même quand ça merde.

1) Croire la sortie confiante sans la prouver

L'IA paraît souvent sûre, même quand elle devine. L'erreur est de sauter la partie ennuyeuse : exécuter les tests, vérifier les cas limites et valider les entrées réelles.

Une habitude simple aide : avant d'accepter un changement, demandez « Comment savons-nous que c'est correct ? » Si la réponse est « ça a l'air juste », vous jouez à la roulette.

2) Laisser l'outil élargir le périmètre

L'IA adore ajouter des extras : cache, retries, plus de réglages, plus d'endpoints, une UI plus jolie. Certains sont utiles, mais ils augmentent le risque. Beaucoup de bugs viennent des fonctionnalités « agréables à avoir » que personne n'a demandées.

Gardez une frontière stricte : résolvez le problème que vous vous étiez fixé, puis arrêtez. Si une suggestion est intéressante, créez-en une tâche séparée avec ses propres tests.

3) Fusionner des changements trop gros pour être relus

Un gros commit généré par l'IA peut cacher une douzaine de décisions sans lien. La revue devient un tamponnage parce que personne ne peut tout tenir en tête.

Traitez la sortie du chat comme un brouillon. Fractionnez-la en petits changements que vous pouvez lire, exécuter et annuler. Les snapshots et le rollback ne servent que si vous les prenez à des points sensés.

Quelques limites simples évitent la plupart des problèmes : une fonctionnalité par change set, une migration par change set, une zone à risque à la fois (auth, paiements, suppression de données), tests mis à jour dans la même modification et une note claire « comment vérifier ».

4) Copier du code sans garantir licence ou sécurité

L'IA peut reproduire des motifs issus de ses données d'entraînement ou suggérer des dépendances inconnues. Même si la licence est correcte, le risque majeur est la sécurité : secrets en dur, gestion des tokens faible ou opérations de fichiers/requêtes non sûres.

Si vous ne pouvez pas expliquer ce qu'un extrait fait, ne le shippez pas. Demandez une version plus simple ou réécrivez-la vous-même.

5) Oublier les migrations, les limites et les modes d'échec

Beaucoup de bugs « ça marche sur ma machine » sont en réalité des bugs de données et d'échelle. L'IA peut créer des changements de schéma sans penser aux lignes existantes, aux tables volumineuses ou aux temps d'arrêt.

Exemple réaliste : le modèle ajoute une nouvelle colonne NOT NULL à une table PostgreSQL et la backfill dans une boucle lente. En production, cela peut verrouiller la table et faire tomber l'app. Pensez toujours à ce qui se passe avec un million de lignes, un réseau lent ou un déploiement échoué à mi-chemin.

Exemple : une appli simple où la correction compte plus que la vitesse

Imaginez un petit tracker de demandes interne : les gens soumettent des demandes, des managers approuvent ou rejettent, et la finance marque les éléments payés. Ça paraît simple, et avec l'aide de l'IA vous pouvez générer écrans et endpoints vite. Ce qui vous ralentit reste la même vieille vérité : les règles, pas la dactylographie.

Commencez par écrire le minimum qui doit être correct. Si vous ne pouvez pas l'expliquer simplement, vous ne pouvez pas le tester.

Une définition de première version serrée ressemble souvent à ceci : champs (titre, demandeur, département, montant, motif, statut, timestamps) ; rôles (demandeur, approbateur, finance, admin) ; statuts (brouillon, soumis, approuvé, rejeté, payé). Puis indiquez les transitions qui comptent : seul un approbateur peut passer soumis -> approuvé ou rejeté ; seule la finance peut passer approuvé -> payé.

Utilisez l'IA dans un ordre contrôlé pour attraper les erreurs tôt :

1. Définissez d'abord le schéma de base de données et l'enum de statut.
2. Générez des endpoints autour des transitions (submit, approve, reject, pay), pas une route générique update-anything.
3. Générez l'UI en dernier, en fonction de ce que l'API autorise.

Les tests à plus forte valeur ajoutée ne sont pas « la page se charge ». Ce sont les vérifications de permissions et les transitions d'état. Prouvez, par exemple, qu'un demandeur ne peut pas approuver sa propre demande, qu'un approbateur ne peut pas marquer comme payé, que les demandes rejetées ne peuvent pas être payées et que (si c'est votre règle) les montants ne peuvent pas être modifiés après soumission.

Ce qui prend le plus de temps, c'est de clarifier les cas limites. Un approbateur peut-il changer d'avis après avoir rejeté ? Que se passe-t-il si deux approbateurs cliquent approuver en même temps ? Et si la finance doit payer partiellement ? L'IA peut générer du code pour n'importe quelle réponse, mais elle ne peut pas choisir la réponse à votre place. La correction vient de ces décisions, puis du fait d'obliger le code à les respecter.

Checklist rapide avant de déployer des changements générés par l'IA

L'IA peut produire beaucoup de code vite, mais le dernier kilomètre reste du travail humain : prouver que ça fait ce que vous vouliez et échouer de manière sûre quand ça ne le fait pas.

Avant de cocher les cases, choisissez la plus petite définition de « fini » qui compte. Pour une petite fonctionnalité, cela peut être un happy path, deux chemins d'échec et une vérification rapide de lisibilité. Pour les paiements ou l'auth, montez la barre.

Les cinq vérifications

• Chaque exigence est vérifiable. Pour chaque exigence, vous avez soit un test soit une vérification manuelle claire en une phrase. Si vous ne pouvez pas expliquer comment vérifier, vous ne comprenez probablement pas ce que vous avez construit.
• Les échecs sont gérés et expliqués. Testez les principaux cas d'erreur (entrée invalide, permissions manquantes, échec réseau, base vide). Assurez-vous que l'app affiche un message utile et ne fuit pas d'informations sensibles.
• Le design est resté simple. Si l'IA a ajouté des helpers, abstractions ou patterns futés, demandez-vous : les garderiez-vous si vous l'aviez écrit à la main ? Supprimez les couches inutiles à moins qu'elles ne justifient leur présence.
• Un réviseur non impliqué peut suivre. Supposez que le réviseur n'a pas suivi la session de chat. Le code doit se lire comme une histoire : noms clairs, fonctions courtes et une note brève sur la raison du changement.
• Vous pouvez annuler en sécurité. Sachez à quoi ressemble le « retour à la normale ». Capturez une version connue bonne et confirmez que vous pouvez revenir rapidement si la production se comporte différemment.

Un exemple rapide

Supposons que l'IA ajoute une fonctionnalité « invitation en masse » à un écran admin. Le happy path fonctionne, mais le vrai risque vient des cas limites : emails en double, échecs partiels et limites de débit. Une décision de mise en production solide pourrait être : un test automatisé pour les doublons, une vérification manuelle pour les messages d'échec partiels et un plan de rollback.

Prochaines étapes : ajoutez des garde-fous, puis industrialisez votre processus

Quand le code est bon marché, le risque se déplace vers la qualité des décisions : ce que vous avez demandé, ce que vous avez accepté et ce que vous avez expédié. La façon la plus rapide de tirer parti de ces vérités dans le travail assisté par l'IA est d'ajouter des garde-fous qui empêchent les changements « presque corrects » de passer.

Commencez par un spec d'une page pour la prochaine fonctionnalité. Restez simple : pour qui c'est, ce que ça doit faire, ce que ça ne doit pas faire et quelques tests d'acceptation rédigés en langage courant. Ces tests deviennent votre ancre quand l'IA propose un raccourci tentant.

Un ensemble de garde-fous qui évolue sans trop de processus :

• Gardez les changements assez petits pour être relus en minutes, pas en heures.
• Exigez des tests (ou au moins des notes de test) pour chaque changement de comportement.
• Utilisez un template de prompt standard : contraintes, style de code et attentes de test.
• Ayez un chemin de rollback fiable pour chaque déploiement.
• Consignez les inconnues comme TODO explicites, pas comme hypothèses cachées.

Les prompts font désormais partie de votre processus. Mettez-vous d'accord sur une house style : quelles bibliothèques sont autorisées, comment gère-t-on les erreurs, ce que signifie « fini » et quels tests doivent passer. Si un prompt ne peut pas être réutilisé par un autre coéquipier, il est probablement trop vague.

Si vous préférez un mode chat-first pour construire des apps web, backend et mobiles, Koder.ai (koder.ai) est un exemple d'une plateforme où le mode planification, les snapshots et l'export de code peuvent soutenir ces garde-fous. L'outil accélère les brouillons, mais c'est la discipline qui garde les humains maîtres de la correction.