Sommaire (7 sections)
- Avant : le coût du changement dictait l'architecture
- Trois marqueurs datés de l'entrée de l'IA dans le dépôt
- Le virage : trois semaines, et la moitié du socle change
- Ce que le virage a exigé en échange
- Ce qui n'a pas bougé, et qui explique tout le reste
- Les limites, telles qu'elles apparaissent dans l'historique
- Ce que nous en faisons chez nos clients
On présente souvent la révolution de l'IA dans le développement comme une affaire de vitesse de frappe. C'est l'angle le plus visible, et le moins intéressant. Ce qui a réellement changé tient en une phrase : le coût du changement s'est effondré, et quand le coût du changement s'effondre, ce n'est pas la productivité qui bouge, c'est l'architecture des décisions.
Nous en avons une démonstration datée, sur un projet que nous menons depuis deux ans : la plateforme BuyStep. Entre le 24 mars et le 12 avril 2026, elle a changé de framework, de base de données, de front et de back-office. Trois semaines. Le même projet avait mis quatre mois, deux ans plus tôt, à se débarrasser d'un thème e-commerce acheté. Voici ce qui sépare les deux.
Avant : le coût du changement dictait l'architecture #
La première année de BuyStep ressemble à beaucoup de premières années. Les commits sont rédigés à la main, en français, souvent dans l'urgence. Les horaires parlent : trente-cinq des trente-neuf commits de décembre 2024 sont postés entre 22 h et 6 h ; vingt-quatre sur vingt-neuf en janvier 2025 ; quarante-trois sur quatre-vingt-trois en mars 2025.
Les traces de ce que coûte un changement sont partout. Les migrations de base de données sont réinitialisées quatre fois entre décembre 2024 et octobre 2025 — la quatrième efface 54 fichiers d'un coup. En juin 2025, une suite de tests est retirée du dépôt parce qu'elle n'est « plus maintenue ». En janvier 2026, les tests et l'analyse de qualité sont désactivés temporairement dans la pipeline. Chacune de ces décisions est rationnelle prise isolément ; ensemble, elles décrivent une équipe qui paie le changement au prix fort et qui rogne là où elle peut.
Trois marqueurs datés de l'entrée de l'IA dans le dépôt #
L'IA n'arrive pas par une annonce mais par des fichiers. Trois dates, toutes vérifiables dans l'historique :
- Juin 2025 — un fichier
.cursorrules. Premier outillage d'IA visible. À ce stade, l'assistance est une aide à la frappe : elle propose des lignes, jamais une architecture. Le dépôt ne contient rien d'autre d'elle. - Octobre 2025 — un fichier d'instructions, un dossier de configuration, un premier agent. Le dépôt gagne un
CLAUDE.md, un répertoire.claude/et un premier agent spécialisé (unit-test-fixer). Le même mois, la configuration passe en variables d'environnement, l'application est dockerisée, les migrations sont remises à plat et un jeu de données d'amorçage est écrit. - Mars 2026 — des spécifications versionnées avant le code. Audit fournisseurs, moteur de scoring, parcours acheteur et fournisseur : le document précède l'implémentation, et il est dans le dépôt.
Le fait le plus important de cette liste n'est pas technique. En octobre 2025, écrire pour l'assistant a obligé à écrire tout court : conventions, commandes de build, architecture attendue, règles à ne pas franchir. Documenter pour l'IA revient à documenter pour l'équipe — et le projet est devenu lisible par quelqu'un qui ne l'a pas écrit, humain ou non.
Le virage : trois semaines, et la moitié du socle change #

Le 24 mars 2026, un commit reçoit le tag V3-PRE-REFONTE. C'est le seul tag de tout l'historique, et il est posé sur un écran rigoureusement identique à celui de fin février, alors que 626 fichiers ont changé sous le capot. Ce qui suit tient en trois actes :
- 26 mars — la restructuration. Un plan de réorganisation du dépôt est écrit et exécuté le jour même : les bibliothèques partagées dans
libs/, les applications dansapps/, l'ancien monolithe danslegacy/. - 28 mars — la bascule technique. MySQL est remplacé par PostgreSQL (deux migrations le même jour, dont la fusion de la base de fichiers dans la base principale), l'ensemble des projets passe à .NET 10 et Entity Framework Core 10, et Swashbuckle cède la place à l'OpenAPI natif — après un aller-retour reverté dans la journée.
- 12 avril — la suppression. L'administration Blazor est retirée du dépôt,
admin-nextdevient l'unique back-office, AutoMapper est remplacé par un générateur de code, le stockage de fichiers part sur un objet compatible S3 avec CDN, et l'historique des migrations est compressé en une seule.
Les deux fenêtres d'analyse qui couvrent fin mars et avril 2026 totalisent 311 commits et 32 pull requests fusionnées. La veille de la suppression de l'admin Blazor, des commits corrigeaient encore sa navigation : le code a été réparé puis supprimé le lendemain. C'est le geste le plus révélateur de tout l'épisode — on n'entretient pas ce qu'on va jeter, sauf quand jeter est devenu bon marché.
Ce que le virage a exigé en échange #
Le point que les récits enthousiastes omettent : cette vitesse n'est pas gratuite, elle est payée d'avance. Les garde-fous n'arrivent pas après le volume, ils arrivent avec lui, et dans la même fenêtre.
- Les tests d'intégration quittent la base en mémoire pour un vrai PostgreSQL éphémère lancé en conteneur, remis à zéro entre les tests. Une base en mémoire ne rejoue ni les migrations ni le SQL propre au moteur : elle cache exactement les bugs qu'une migration massive produit.
- Des tests d'architecture vérifient à chaque build que les couches ne se traversent pas. C'est ce qui permet de remplacer un socle sans réécrire le domaine.
- 291 tests sur 25 services, séparés en unitaires et intégration, plus une couche de tests sur l'ensemble des contrôleurs.
- Une pipeline en cinq étapes qui bloque tout ce qui casse, avec des images conteneurisées taguées par empreinte de commit.
Ce qui n'a pas bougé, et qui explique tout le reste #
Le virage de mars 2026 a été possible pour une raison qui n'a rien à voir avec l'IA : le modèle de domaine posé en août 2024 n'a pas été touché. Le patron « une entité, une table de traductions » qui porte les six langues, la séparation Domain / Application / Infrastructure, les entités métier : tout cela a survécu à trois piles techniques, deux moteurs de base de données et deux frameworks de présentation.
Autrement dit, l'IA n'a pas rendu l'architecture facultative. Elle l'a rendue décisive : c'est la seule partie du système qu'on ne peut pas régénérer à bon compte, et c'est elle qui détermine ce que l'on peut remplacer à côté. Un projet mal découpé accélère aussi avec un assistant — il accélère vers le mur.
Les limites, telles qu'elles apparaissent dans l'historique #
Nous tenons à les nommer, parce que le même dépôt les montre. En janvier 2026, neuf agents et cinq rapports d'analyse internes sont supprimés du dépôt, en même temps qu'un fichier .env qui n'aurait jamais dû s'y trouver : l'outillage d'IA aussi produit de la dette, et il faut l'élaguer. Le 14 avril 2026, un revert restaure la construction des images après une tentative de simplification de la pipeline. Le 24 août 2026, un correctif de facturation est reverté dans la journée et remplacé par une solution plus humble — afficher un montant comme une estimation plutôt que de prétendre le figer.
Trois reverts en deux ans, tous le jour même : ce n'est pas un mauvais chiffre, c'est le signe que la boucle de détection fonctionne. Mais aucun de ces trois problèmes n'a été trouvé par une relecture. Ils ont été trouvés en exécutant. C'est la limite la plus dure du développement assisté, et elle ne bouge pas : un modèle peut écrire et relire, seul un système qui tourne dit la vérité.
Ce que nous en faisons chez nos clients #
Rien de magique, quatre habitudes. Un document de conventions tenu à jour dans le dépôt, lisible par l'équipe comme par l'assistant. Des tests qui touchent la vraie base plutôt qu'un substitut. Des pull requests courtes, parce que la relecture est devenue le goulot. Et une répartition des modèles selon la tâche — les plus capables à la conception et à la synthèse, les autres à l'implémentation et à la correction — parce que le débit se paie aussi en jetons.
Le détail de cette méthode, paradigme par paradigme, est dans notre premier retour d'expérience sur BuyStep. Les captures citées ici viennent de la rétrospective illustrée du projet.
Si vous vous demandez ce que l'IA peut apporter à votre équipe sans en faire une boîte noire, notre approche est décrite ici — et nous vous dirons franchement quand elle n'apporte rien. Premier échange offert.



