La responsabilité première d'un ingénieur : fournir un code qui résiste à l'examen minutieux. Cet article, tiré du dernier blog de Simon Willison, explore comment les ingénieurs logiciels peuvent redéfinir leurs valeurs fondamentales et leurs responsabilités à l'ère des outils de programmation d'IA généralisés. Argument clé : Générer du code à moindre coût contre garantir une qualité de livraison optimale. À l’ère de l’IA, les barrières et le coût liés à l’écriture de code ont été considérablement réduits. Simon souligne que la simple génération de code et la soumission d’une demande de fusion (PR) n’ont plus aucune valeur. Si un ingénieur utilise l'IA pour générer une grande quantité de code, puis le soumet à ses collègues pour relecture sans vérification, il s'agit non seulement d'un grave manquement à ses obligations professionnelles, mais aussi d'un manque de respect envers autrui. La véritable valeur d'un ingénieur réside dans sa capacité à garantir l'exactitude du code. Comment s'acquitter de la responsabilité de « prouver que le code est valide » ? Simon estime que pour prouver la validité d'un code, deux étapes indispensables doivent être scrupuleusement respectées : Étape 1 : Tests manuels. C’est l’étape fondamentale. L’auteur insiste sur un principe : si vous ne constatez pas que le code s’exécute correctement, considérez-le comme défectueux. • Voir, c'est croire : vous devez exécuter le code vous-même et observer son comportement. • Fournir des preuves : lors de la soumission de code pour relecture, il est important de fournir des preuves. Par exemple, collez les journaux d’exécution du terminal dans la description de la demande de fusion, ou, pour les modifications d’interface utilisateur, joignez des enregistrements d’écran ou des captures d’écran. • Couvrez les limites : ne vous contentez pas de tester le scénario le plus favorable ; essayez également les cas limites susceptibles de générer des erreurs. Étape 2 : Les tests automatisés ne suffisent pas, même combinés aux tests manuels. Le code source doit intégrer des tests automatisés capables de garantir une efficacité continue. • Tester plutôt que vérifier : les modifications de code soumises doivent inclure un nouveau cas de test. Idéalement, le test devrait échouer avant la modification de l’application (en rouge) et réussir après la modification (en vert). • Atout majeur de l'IA : Les juristes diplômés d'aujourd'hui excellent dans la rédaction de code de test. L'auteur estime que, compte tenu de la puissance actuelle de l'IA, s'en servir comme prétexte pour se dispenser de rédiger des tests est totalement inacceptable. • Relation complémentaire : les tests automatisés ne peuvent pas remplacer complètement les tests manuels ; les deux doivent être utilisés conjointement et aucun ne peut être omis. L'article « Règles de survie à l'ère des agents programmables d'IA » évoque une tendance majeure en 2025 : la prolifération d'agents de programmation capables d'exécuter des tâches de manière autonome. Face à cette tendance, l'auteur propose des conseils très concrets : • Adoptez une posture de mentor : considérez les agents d’IA comme vos jeunes collaborateurs. Votre rôle consiste à les former et à leur apprendre à valider eux-mêmes leur travail en exécutant du code ou en rédigeant des tests. • « Le goût détermine l’altitude » : l’IA excelle dans l’imitation. Si votre projet dispose déjà d’une suite de tests bien structurée et bien conçue (ce que l’auteur appelle le « goût »), l’IA peut parfaitement étendre ces tests par imitation. • Tirez parti des fonctionnalités de l'outil : contrairement aux humains, les agents ne se lassent pas d'écrire des tests ; ils y prennent même plaisir. En tant qu'ingénieur senior, vous devriez exploiter cet atout pour instaurer une culture de test performante. En conclusion : la responsabilité humaine est irremplaçable. Aussi performante que devienne une IA, une machine ne pourra jamais assumer ses erreurs. Seuls les humains en sont capables. De nos jours, générer des milliers de lignes de code via Prompt ne prend que quelques secondes, mais cela n’a aucune importance. Ce qui compte vraiment, c’est vous, en tant qu’« humain au cœur du processus », qui montrez le code avec assurance et déclarez à l’équipe : « J’assume la responsabilité de ce code car j’ai prouvé qu’il fonctionne. » Article de blog original
