Les vérités logicielles de Joel Spolsky restent utiles même quand l'IA écrit du code rapidement. Découvrez comment garder tests, recrutement et simplicité focalisés sur la correction.
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.
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.
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.
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 :
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.
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.
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.
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.
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 :
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.
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 :
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.
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.
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.
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.
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 ».
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.
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.
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 :
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.
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.
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.
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 :
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.
Traitez la sortie de l'IA comme un brouillon rapide, pas comme une fonctionnalité terminée. Commencez par rédiger 3 à 5 critères d'acceptation clairs (pass/échec), puis générez une seule tranche (un endpoint, un écran, une migration) et vérifiez-la avec des tests et des essais de cas d'échec avant d'aller plus loin.
Parce que les tests sont l'endroit où vous découvrez ce que le code fait vraiment. L'IA peut produire une logique plausible qui oublie une règle clé (permissions, retries, états limites). Les tests transforment vos attentes en quelque chose d'exécutable, répétable et digne de confiance.
Commencez par ce qui ferait le plus de mal si ça cassait :
Ajoutez ensuite la couverture après avoir verrouillé les comportements à fort impact.
Demandez l'approche la plus simple avec des contraintes explicites, puis retirez les couches supplémentaires sauf si elles « paient leur loyer ». Une bonne règle : n'introduisez une nouvelle abstraction que si elle supprime de la duplication dans 3+ endroits ou rend la correction plus facile à prouver.
Rédigez un petit spec : entrées, sorties, erreurs, contraintes et non-objectifs. Incluez des exemples concrets (requêtes/réponses, cas limites). Puis définissez d'avance ce que signifie « fini » : tests requis, compatibilité arrière et un court « comment vérifier ». Ça transforme le prompt en un vrai contrat.
Fractionnez. Gardez chaque ensemble de modifications lisible en quelques minutes :
Ainsi la revue reste réelle au lieu d'être un simple tamponnage.
Ne vous fiez pas à la confiance—fiez-vous à la preuve. Exécutez des tests, tentez des entrées malformées et vérifiez les frontières de permission. Recherchez aussi les pièges courants de l'IA : checks d'auth manquants, construction de requêtes non sécurisée, gestion faible des tokens et erreurs silencieuses.
Privilégiez des endpoints de transition explicites plutôt qu'un « update anything » générique. Par exemple : submit, approve, reject, pay au lieu d'une route générique de mise à jour. Puis écrivez des tests qui imposent qui peut effectuer chaque transition et quelles transitions sont interdites.
Donnez aux candidats un diff généré par l'IA avec des problèmes réalistes : noms flous, test manquant, cas limite et petite faille de sécurité. Demandez-leur d'expliquer l'intention, d'identifier les zones à risque, de proposer des corrections et de décrire les tests qu'ils ajouteraient.
Utilisez les fonctions de l'outil pour soutenir une boucle disciplinée : planifiez d'abord, générez par petites tranches, prenez un instantané avant les changements risqués et revenez en arrière si la validation échoue. Dans un outil chat-first comme Koder.ai, cela s'intègre bien avec le mode planification, les snapshots et le rollback—surtout pour l'auth, les paiements ou les migrations.
