> For the complete documentation index, see [llms.txt](https://weekly-essay.mikey.wang/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://weekly-essay.mikey.wang/fr/2025/w50-what-should-the-team-do-next-year-in-ai-coding.md).

# W50-Que doit faire l'équipe en programmation par IA l'an prochain ?

Cette semaine, j'ai lu [State of AI](https://openrouter.ai/state-of-ai), d'a16z et d'OpenRouter, une étude empirique fondée sur environ 100 000 milliards de tokens réellement traités sur OpenRouter. Dès le début, j'ai eu l'impression que le temps se dérobait : la version officielle d'o1 est sortie le 5 décembre 2024, il y a tout juste un an. La part des tokens traités par les modèles de raisonnement a augmenté tout au long de 2025 et dépasse récemment la moitié.

Supposons que les modèles continuent de progresser pendant plusieurs années, avec la diffusion du multimodal, de la mémoire et des capacités agentiques. L'objectif central de l'équipe ne devrait alors pas être seulement d'adopter quelques outils ou de réunir quelques prompts, mais de construire des fondations d'ingénierie AI-Ready. Plus les modèles deviennent capables, plus notre capacité de livraison doit pouvoir s'exprimer.

Pour travailler durablement dans cette direction, cinq dimensions permettent d'accumuler les progrès.

**1) Architecture**

L'IA agit difficilement dans un projet que l'on ne sait pas expliquer. Elle consomme beaucoup de tokens et risque des régressions en négligeant des dépendances implicites. Les principaux problèmes frontend sont le mélange entre vue et logique métier, l'enchevêtrement de la logique et des effets de bord, et la difficulté à séparer ce qui change souvent de ce qui change peu. Adopter MVVM ou MVC ne suffit pas.

Le projet doit pouvoir dire clairement quel est son code central. Celui-ci porte toute la logique métier et l'évolution de l'état. Idéalement, il se compose de fonctions pures, indépendantes du framework et de l'environnement, testables unitairement, avec des entrées et sorties déterminées. Le reste gère les entrées-sorties réseau, les effets de bord et le rendu. L'IA dispose ainsi d'un point d'appui stable, et les modifications deviennent maîtrisables.

**2) Rendre le contexte explicite**

Sans histoire du projet, l'IA ne comprend pas certains contournements étranges. Documentation et commentaires ne servent plus seulement à conserver le savoir : ils influencent directement la qualité du code généré.

Il faut expliciter les connaissances métier, les contraintes architecturales, les préférences de pile technique et les conventions de l'équipe. Des formes faciles à consommer par l'IA sont préférables : ADR, listes de contraintes, éléments intangibles du README. Une chaîne d'outils adaptée transmettra ce contexte au modèle.

**3) Faire intervenir les contraintes plus tôt**

J'adhère à l'idée de déplacer les problèmes en amont grâce au compilateur et à l'analyse statique. Rust est emblématique d'une compilation stricte, mais la plupart des cas frontend n'exigent pas Rust pour éviter les incidents. Le vrai problème est la sous-utilisation des atouts de TypeScript. Historiquement, pour accélérer son adoption, on l'a autorisé de façon très permissive. Beaucoup de projets n'activent toujours pas toutes les contraintes de type et de compilation.

Le mode strict de TS est une base non négociable. Il faut interdire résolument les types sans valeur comme any. Des règles Lint personnalisées et communes sont nécessaires. Des règles ESLint peuvent imposer les frontières architecturales et harmoniser le style, par exemple en exigeant Composition API et en interdisant les dépendances entre couches inappropriées.

**4) Vérification programmée**

Générer du code coûtera de moins en moins cher. Vérifier sa justesse reste coûteux : faisons donc intervenir d'abord les vérifications peu coûteuses. Cela suit l'esprit du TDD tout en réduisant son ancien coût de mise en œuvre.

Une bonne architecture rend le code central identifiable, et sa couverture unitaire devient très rentable. Frontend et backend collaborent par contrat ; Zod est utile pour valider les schémas à l'exécution. Frontend et QA collaborent par cas de test. Écrire avant l'implémentation les critères d'acceptation ou des cas de test en langage naturel paraît peu séduisant, mais peut être efficace.

**5) Observabilité et diagnostic**

Avec la croissance de l'organisation et la spécialisation du travail, répondre aux réclamations et diagnostiquer les incidents devient moins efficace. Les journaux sont dispersés entre services ; les échanges de faits dans les groupes peuvent prendre plusieurs heures.

Il faut relier les journaux et l'observabilité pour que l'IA voie les données de bout en bout. Au minimum : journaux structurés, traces unifiées et rejeu des parcours essentiels. Automatiser d'abord la collecte des faits rendra la réponse des ingénieurs plus rapide. C'est aussi un préalable au diagnostic automatisé par IA.