Djamel Bougouffa | Blog

L'IA écrit le code maintenant, raison de plus pour maîtriser l'architecture

Thu, 16 Jul 2026 00:00:00 GMT

Pendant l’essentiel de ma carrière, être un bon développeur voulait dire être bon pour produire du code. Vite, juste, idiomatique. Cette compétence compte toujours, mais elle a discrètement cessé d’être celle qui te distingue. Un agent produit désormais du code vite, juste et idiomatique, à la demande. La partie du métier devenue rare, et donc précieuse, c’est celle qui décide ce qu’il faut produire et quelle forme lui donner.

Ce n’est pas un petit glissement. Il déplace l’endroit où vit la valeur d’un développeur : du clavier vers la conception. Et il a une implication inconfortable pour toute une catégorie de développeurs qui ont bâti leur identité sur la vitesse d’implémentation. Voici pourquoi l’architecture et le craft sont les compétences qui viennent de prendre de la valeur, et pourquoi les développeurs « classiques » ont intérêt à s’y former maintenant plutôt que plus tard.

L’IA est douée exactement pour la partie qui n’a jamais été la difficile

Voici ce qu’on ne dit pas assez : écrire une fonction a rarement été le point dur du logiciel. Savoir quelle fonction, où elle doit vivre, ce qu’elle doit ou ne doit pas toucher, et comment elle s’imbrique dans le reste du système : ça, ça a toujours été le point dur. L’IA est spectaculaire sur le premier et structurellement faible sur le second.

Un agent génère du code localement plausible. Demande-lui une feature et il produira quelque chose qui a l’air juste, et qui souvent marche. Ce qu’il n’a pas, c’est le goût au niveau système : le sens de ce qu’il faut protéger, du couplage qui te fera mal dans six mois, de l’endroit où placer une frontière, de ce que le domaine signifie vraiment sous les tickets. Il optimise pour « faire passer cette tâche », pas pour « garder ce système cohérent ». (J’ai vu cet écart précis casser une règle métier vieille de dix ans en production.)

La capacité n’a donc pas disparu. Elle s’est inversée. Ce qui était cher est devenu abondant. Ce qui était rare, le jugement sur la structure, est devenu le goulet d’étranglement. Et c’est dans les goulets que se concentre la valeur.

L’architecture, c’est le volant

Voici la raison pratique pour laquelle ce n’est pas de la philosophie de carrière abstraite. Si tu ne sais pas décrire la forme que tu veux, tu ne peux pas diriger un agent. Tu peux seulement accepter ce qu’il te tend.

Bien travailler avec un agent de code est un acte de direction. Tu lui dis : mets la logique métier dans un cœur pur, garde l’appel Slack derrière un port, ne laisse pas la couche de persistance fuir dans le domaine. Cette instruction ne t’est accessible que si tu comprends les ports et adaptateurs, le couplage, la cohésion, où placer les frontières et pourquoi. L’architecture est ce qui rend un agent sûr et rapide, mais seulement entre les mains de quelqu’un qui sait nommer la cible.

Le développeur qui connaît l’architecture traite l’agent comme un implémenteur très rapide de sa conception. Celui qui ne la connaît pas traite l’agent comme un oracle, accepte sa sortie, et accumule lentement un système que plus personne ne comprend. Même outil. Résultats opposés. Le facteur différenciant, c’est entièrement la culture de conception de l’humain.

C’est le renversement : l’IA n’a pas remplacé le jugement de l’architecte. Elle a fait de ce jugement l’interface par laquelle tout le reste se construit.

La partie inconfortable pour le développeur « classique »

Je veux être direct, parce que l’optimisme vague n’aide personne à planifier une carrière.

Si ta valeur pour une équipe, c’était implémenter des tickets que quelqu’un d’autre a conçus (transformer vite une tâche bien spécifiée en code fonctionnel), c’est précisément la couche que l’IA absorbe le plus vite. Non parce que tu n’es pas bon ; parce que c’est la part du travail la plus compressible en « génère du code plausible pour une spec claire ». L’implémenteur qui ne fait qu’implémenter se tient exactement là où l’eau monte.

Ce n’est pas une prophétie catastrophiste. C’est un panneau de direction. Le mouvement, c’est monter d’une couche : de « je sais construire ce qu’on me demande » à « je sais décider ce qu’il faut construire et comment le structurer ». D’implémenteur à concepteur. D’écrivain de code à directeur de code. Et les compétences qui t’y amènent, ce n’est pas plus de vitesse de frappe ni un framework de plus : ce sont les compétences durables et peu glamour que l’industrie sous-estime depuis des années parce qu’elles font une mauvaise démo.

Ceux qui ont passé la dernière décennie à railler les « astronautes de l’architecture » et le « craft, c’est du luxe, livre et c’est tout » vont découvrir que le luxe, c’était les douves.

Ce que « se former au craft » veut dire concrètement (pas des buzzwords)

« Mets-toi au craftsmanship » est facile à dire et facile à transformer en liste de lecture qu’on n’applique jamais. Concrètement, voici ce qui prend de la valeur :

Frontières et couplage. Ports et adaptateurs, sens des dépendances, ce qui appartient au domaine par rapport aux bords. C’est le vocabulaire avec lequel tu diriges un agent. Commence là.
Le test comme outil de conception, pas comme corvée. Pas la course à la couverture, mais se servir des tests pour figer le comportement et attraper les changements silencieux d’un agent. Le test qui aurait attrapé la règle métier cassée est une compétence de conception, pas une tâche de QA.
La modélisation du domaine. Comprendre le métier assez profondément pour nommer les choses correctement. L’ubiquitous language n’est pas de la cérémonie ; c’est la carte que toi et l’agent suivez tous les deux.
Lire et relire le code de façon critique. La compétence la plus importante dans un workflow saturé d’IA, c’est distinguer le bon code du code plausible. Si tu ne repères pas un diff confiant mais faux, la vitesse de l’agent est un handicap, pas un levier.
La pensée système. Comment un changement se propage. Ce qu’il faut protéger. Ce que « cohérent » veut dire pour cette codebase précisément. C’est le goût que l’IA n’a pas, et il s’apprend : par l’exposition, la lecture de grandes codebases, et l’erreur volontaire dans des endroits sans enjeu.

Rien de tout ça n’est la nouvelle mode. Tout ça, c’est ce que les ingénieurs seniors ont toujours fait, discrètement. La différence, c’est que ce n’est plus la part cachée du métier derrière l’acte visible de taper. C’est le métier, désormais.

La version optimiste (parce qu’elle l’est)

Je ne pense pas que ce soit un mauvais moment pour être développeur. Je pense que c’est le meilleur moment pour être un développeur qui sait architecturer, et un moment stressant pour celui qui ne fait qu’implémenter. Et ce sont deux phrases très différentes.

Pour qui veut monter en compétence, le levier est extraordinaire. Un développeur cultivé en architecture, avec un bon agent, fait le travail d’une petite équipe : il conçoit, l’agent implémente, il relit, il oriente. Le plafond de ce qu’une seule personne peut construire vient de bondir, mais seulement pour ceux dont la compétence est de décider la forme, pas de la remplir.

Alors si je devais donner un seul conseil de carrière à un développeur « classique » aujourd’hui, il serait court : arrête de concurrencer l’agent sur ce qu’il fait mieux que toi. Il tape plus vite que toi et ne fatigue jamais. Va sur ce qu’il ne sait pas faire : tenir tout le système en tête, savoir quoi protéger, décider la structure, et distinguer le bon du plausible. Apprends l’architecture. Apprends le craft. Pas parce que c’est vertueux, mais parce que c’est la part de ton métier qui vient de devenir tout le métier.

Si tu veux la version concrète de « structure ton code pour qu’un agent y prospère », j’ai écrit pourquoi l’architecture hexagonale est le plus beau cadeau à faire à un agent IA. Et pour l’histoire vraie derrière tout ça, voici comment l’IA a cassé notre code de production, et la règle de craftsmanship qui aurait tout évité.

L'architecture hexagonale est le plus beau cadeau à faire à un agent IA

Wed, 08 Jul 2026 00:00:00 GMT

On a adopté l’architecture hexagonale pour les humains qui reliraient le code plus tard. Il se trouve qu’on l’a aussi bâtie pour un lecteur qu’on n’avait pas vu venir : l’agent IA qui travaille sur la codebase aujourd’hui.

Je ne l’ai pas planifié. Je l’ai constaté. Le même agent de code, face au même type de tâche, se comportait de façon radicalement différente selon la forme du code dans lequel il atterrissait. Dans une codebase emmêlée, c’était un danger. Dans une codebase proprement structurée, il était réellement rapide et réellement sûr. La différence, ce n’était ni le modèle, ni le prompt, ni l’outillage. C’était l’architecture.

Voici pourquoi les ports et adaptateurs sont le plus beau cadeau à faire à un agent IA, et les limites honnêtes de cette affirmation.

La même tâche, deux codebases

Donne à un agent cette tâche : « Ajoute une notification Slack quand une commande est expédiée. »

Dans un service emmêlé, la logique d’expédition, la persistance et les appels sortants vivent dans une seule classe de 600 lignes. L’agent la lit, décide que l’endroit naturel pour se brancher est juste après la mise à jour du statut, et édite là. Ça marche. Ça déplace aussi discrètement une ligne, change le moment où le timestamp shippedAt est fixé, et voilà qu’une règle de facturation vieille de dix ans, indexée sur ce timestamp, se déclenche un jour trop tôt. Aucun test ne l’a attrapé, parce que le test vérifiait « un email est envoyé », pas « le timestamp est intact ». Ça remonte en production. (Si ce mode de défaillance te dit quelque chose, c’est parce que j’ai vu un agent casser en silence une règle métier non documentée en production : une autre règle, la même forme d’erreur.)

Dans une codebase hexagonale, la même tâche est ennuyeuse dans le meilleur sens du terme. Il existe une interface NotificationPort. L’agent implémente un SlackNotificationAdapter, le branche, et ne touche jamais au domaine. La règle métier sur shippedAt vit dans un cœur pur que l’agent n’avait aucune raison d’ouvrir. Le rayon de destruction du changement était borné par l’architecture, avant même que l’agent ne tape un caractère.

C’est toute la thèse. La suite du billet détaille pourquoi la seconde histoire arrive à dessein, et non par chance.

Pourquoi l’hexagonal marche pour un agent en particulier

L’architecture hexagonale n’a rien de neuf pour les humains. Ce qui est neuf, c’est que ses propriétés exactes se trouvent être celles dont un agent IA a le plus besoin.

1. Elle borne le rayon de destruction

Le pire mode de défaillance d’un agent n’est pas d’écrire du code faux : c’est d’écrire du code plausible au mauvais endroit. Il optimise localement pour « faire marcher la tâche » et n’a aucun instinct de ce qu’il met en péril trois couches plus loin.

Les ports et adaptateurs répondent à ça structurellement. Le domaine n’a aucune dépendance vers l’extérieur ; tout ce qui est volatil (HTTP, base de données, API tierces, files de messages) vit dans des adaptateurs, à la périphérie. Ainsi, la surface où l’agent doit travailler (les adaptateurs) est physiquement séparée de celle qu’il ne devrait presque jamais toucher (le cœur métier). Tu n’espères pas que l’agent respecte une frontière. La frontière est porteuse.

2. Le cœur est testable en isolation, donc l’agent a une boucle de feedback rapide

Un domaine pur, sans I/O, se teste sans démarrer une base de données ni un serveur web. Ça compte plus pour un agent que pour toi, parce que toute la boucle de travail de l’agent c’est éditer → lancer → lire le résultat → corriger. Plus cette boucle est rapide et ciblée, meilleur est l’agent.

Quand la logique métier est un cœur pur, l’agent peut écrire un test, le lancer en quelques millisecondes, et obtenir un signal sans ambiguïté : « la règle tient toujours » ou « non ». Quand la logique est étalée dans une classe couplée à l’infra, le seul moyen de la tester est un test d’intégration lent, instable et vague sur ce qui a cassé. Une bonne architecture donne à l’agent un oracle de vérité. Une mauvaise lui donne un haussement d’épaules.

3. Les ports nomment le travail dans la langue du domaine

Un port PaymentGateway avec authorize(Payment) et capture(Payment) dit à l’agent ce que fait le système en termes métier. Un fouillis d’appels HttpClient et de mapping de DTO ne lui dit rien, sinon comment la plomberie se trouve câblée cette semaine.

Les LLM sont exceptionnellement bons pour suivre une intention bien nommée et facilement perdus dans la complexité accidentelle. Les ports sont, de fait, une interface curée sur laquelle un agent peut raisonner, la même raison pour laquelle l’ubiquitous language aide un humain à embarquer. Tu n’organises pas seulement le code ; tu tends à l’agent une carte écrite dans le bon vocabulaire.

Ce que ça donne en Java

Voici la version emmêlée qu’un agent abîmera avec plaisir :

// OrderService.java : tout au même endroit
public void ship(Long orderId) {
    Order order = jpaRepository.findById(orderId).orElseThrow();
    order.setStatus(SHIPPED);
    order.setShippedAt(Instant.now());        // la facturation s'indexe là-dessus
    jpaRepository.save(order);
    // l'agent ajoute sa feature juste ici, à côté d'un timestamp qu'il ne comprend pas
    emailClient.send(order.getCustomerEmail(), "Votre commande est expédiée");
}

Et la version hexagonale, où la même feature a un foyer évident et sûr :

// Cœur du domaine : pur, sans framework, sans I/O
public final class ShipOrder {
    private final OrderRepository orders;      // un port
    private final NotificationPort notifier;   // un port

    public void handle(OrderId id) {
        Order order = orders.byId(id);
        order.markShipped();                   // la règle du shippedAt vit dans Order
        orders.save(order);
        notifier.orderShipped(order);          // l'agent étend derrière ce port
    }
}

// Adaptateur : le seul fichier que l'agent a besoin d'ajouter
public final class SlackNotificationAdapter implements NotificationPort {
    public void orderShipped(Order order) { /* appel Slack */ }
}

Le domaine n’a pas bougé. markShipped() possède toujours la règle du timestamp, scellée à l’intérieur de l’agrégat. L’agent ajoute un adaptateur, implémente une méthode, et il n’a jamais existé de chemin pour qu’il perturbe l’invariant. Non parce qu’il a été prudent, mais parce que l’architecture ne lui a jamais tendu la corde.

Les limites honnêtes

Une thèse aussi propre mérite d’être bousculée, alors cadrons-la avant de la surappliquer. Trois réserves auxquelles je tiens :

L’hexagonal a un coût de cérémonie. Pour un petit script ou un service jetable, la surcharge ports-et-adaptateurs est de la pure friction, et un agent qui bosse dans un projet de deux fichiers n’en a pas besoin. Ça paie sur de vrais domaines, avec des règles qui méritent d’être protégées, pas partout.
Des ports poreux laissent fuir la protection. Si ton « port » est en réalité une entité JPA ou un objet de réponse HTTP déguisé, le domaine n’est pas isolé, et le rayon de destruction de l’agent non plus. L’architecture aide exactement à la mesure de son honnêteté. À moitié hexagonal, tu n’as que la moitié du garde-fou.
Elle réduit le rayon de destruction ; elle ne le supprime pas. Un agent peut toujours écrire une règle métier fausse à l’intérieur d’un cœur parfaitement pur. Les bonnes frontières rendent les mauvais changements contenus et visibles, pas impossibles. Tu relis toujours. Tu restes propriétaire de la sortie.

Le basculement qu’il faut nommer

Pendant vingt ans, on a justifié les frontières propres par un argument sur le futur : quelqu’un devra maintenir ça. La récompense était toujours différée, et c’est bien pour ça que la discipline était la première chose sacrifiée sous la pression des délais.

L’agent IA écrase cette temporalité. Le mainteneur pour qui tu construisais travaille désormais dans ton dépôt cet après-midi, et l’architecture du code détermine directement si cet agent est un accélérateur ou un danger. Une bonne structure a cessé d’être un cadeau à un hypothétique ingénieur futur. C’est du levier que tu encaisses aujourd’hui.

La conclusion surprenante est donc le conseil le moins surprenant du métier, avec des enjeux nouveaux : isole ton domaine. Pas parce qu’un livre l’a dit, mais parce que la chose qui écrit désormais la moitié de ton code performe exactement aussi bien que tes frontières le permettent. L’architecture hexagonale a toujours été du bon craftsmanship. C’est maintenant aussi l’interface à travers laquelle tes agents font leur meilleur travail.

Ça rejoint deux choses que j’ai écrites : pourquoi la discipline d’architecture compte plus, pas moins, quand l’IA écrit le code, et comment je fais passer une codebase Java legacy du ticket à la pull request avec un agent.

Pourquoi j'ai quitté l'IDE IA pour le terminal, et l'outillage que j'ai dû construire

Wed, 01 Jul 2026 00:00:00 GMT

Pendant environ un an, mon assistant de code a vécu dans mon éditeur. L’autocomplétion dans la marge, un panneau de chat à droite, des diffs en ligne que j’acceptais d’une touche. C’était bien. Puis un après-midi, je l’ai fermé, j’ai ouvert un terminal, et j’ai confié les mêmes tâches à un agent en ligne de commande.

Je pensais revenir en arrière sous une semaine. Je ne l’ai pas fait. Des mois plus tard, l’IDE est toujours là. Je ne lui demande simplement plus de réfléchir. Voici le compte rendu honnête de pourquoi le terminal l’a emporté pour moi, ce qu’il perd encore, et l’outillage que j’ai dû construire pour que le changement soit réellement rentable.

Le jour où j’ai fermé le panneau

Ce qui m’a fait basculer n’était pas une fonctionnalité. C’était une impression qui revenait : l’assistant de l’IDE était un passager dans mon éditeur, et l’agent du terminal était un collègue à mon bureau.

Dans l’IDE, l’assistant suggérait, surtout. Il proposait un diff, je l’acceptais ou le rejetais, et la boucle s’arrêtait là. Tout ce qui dépassait l’édition d’un fichier (lancer les tests, consulter l’historique git, reproduire un bug, appeler une API interne), c’était mon boulot. L’assistant regardait.

Dans le terminal, l’agent agit. Il lit les fichiers, lance le build, analyse l’échec, modifie, relance les tests, et ne revient vers moi que quand il a quelque chose à montrer ou une décision à demander. L’unité de travail n’était plus « un diff » mais « une tâche ».

C’est cette différence qui a tout fait tenir. Le reste n’est que ma tentative de me l’expliquer.

Pourquoi ça a tenu (et non, pas parce que le terminal est plus cool)

Trois raisons, par ordre d’importance réelle.

1. La composabilité

C’est la vraie. Le terminal est le seul endroit où tous les outils qu’un développeur utilise déjà parlent la même langue : du texte en entrée, du texte en sortie. Dès que l’agent y vit, il peut se composer avec tout, sans que personne n’écrive d’intégration.

Il lance git directement. Il pipe la sortie du build dans un grep. Il appelle mes propres CLIs. Il dialogue avec des systèmes externes via MCP. Rien de tout cela n’a demandé un plugin, une API d’extension ou la bénédiction d’un éditeur. L’assistant de l’IDE, lui, ne pouvait faire que ce que sa surface d’extension autorisait : un jardin clos, aussi joli soit le mur.

Un IDE est un produit. Le terminal est un protocole. On peut bâtir sur un protocole.

2. Un contexte qui survit à la session

Sur une vraie codebase, surtout legacy, l’essentiel du travail, c’est comprendre avant de modifier. L’agent du terminal traite tout le dépôt comme son espace de travail : il greppe, suit les chaînes d’appels, lit ce dont il a besoin, et garde ce contexte sur une longue session. Je ne réexplique pas la structure du projet toutes les cinq minutes.

Dans l’IDE, le contexte était implicitement « les fichiers que j’ai ouverts ». Puissant pour la fonction sous mon curseur, faible pour « trace comment cette valeur traverse huit couches de services ». Le terminal a inversé ça, et tracer des flux, c’est l’essentiel du travail sur du legacy.

3. Le contrôle

Dans le terminal, je vois exactement ce que l’agent s’apprête à faire, je peux l’interrompre et le réorienter. La boucle est lisible. Quand l’agent compose de vraies commandes plutôt que de piloter une API d’éditeur cachée, je peux le superviser au lieu de lui faire confiance. Pour tout ce qui touche au code de production, cette lisibilité vaut plus que le confort.

Le compromis honnête

Si je ne te racontais que les gains, ce serait un argumentaire commercial, pas un compte rendu. L’IDE fait encore plusieurs choses mieux, et prétendre le contraire serait malhonnête.

La navigation visuelle. Aller à la définition, trouver les références, la hiérarchie d’appels, un vrai debugger avec points d’arrêt et fenêtre de surveillance : c’est meilleur dans l’IDE, point. Quand je dois dérouler du code pas à pas, je reviens dans l’éditeur.
Les éditions locales et serrées. Pour un petit changement bien cadré dans un fichier que je regarde déjà, l’autocomplétion en ligne est plus rapide que de décrire la tâche à un agent. Tout changement ne mérite pas une phrase.
La découvrabilité. L’IDE te montre ce qui est possible. Le terminal suppose que tu sais. C’est une vraie barrière, et j’y reviens.
Les artefacts visuels. Rendre un composant, inspecter une UI, lire un flame graph : le terminal est le mauvais outil, et je ne fais pas semblant du contraire.

Donc ce n’est pas « le CLI bat l’IDE ». J’utilise toujours les deux. La version exacte : le terminal est là où l’agent doit réfléchir ; l’IDE est là où je vais encore regarder.

Ce que le terminal a débloqué (et m’a forcé à construire)

Voici la partie que la plupart des billets « j’ai switché vers le terminal » sautent. La composabilité est une promesse, pas une fonctionnalité. Le terminal te permet de composer des outils ; il ne te les offre pas. Une fois l’agent devenu un véritable acteur à mon bureau, les manques sont apparus vite, et j’ai dû construire la couche qui rend le changement rentable.

Trois problèmes ont surgi presque immédiatement.

La sortie était trop bruyante. Les agents lisent la sortie des outils comme des tokens, et la sortie brute d’un développeur est surtout du bruit : codes de couleur ANSI, JSON verbeux, frames de pile dupliquées. L’agent payait, en contexte et en dollars, pour lire de la camelote. J’ai donc construit trimcp, un proxy MCP en Rust qui s’intercale entre l’agent et ses outils et compresse ce qui revient : il retire l’ANSI, minifie le JSON et déduplique les blocs répétitifs avant même que l’agent ne les voie. Même information, une fraction des tokens.

Les commandes étaient trop coûteuses. Beaucoup d’opérations de dev courantes produisent bien plus de sortie que ce dont l’agent a besoin. Celui-là, je n’ai pas eu à le construire : RTK (Rust Token Killer) est un proxy CLI open source qui réécrit de façon transparente les commandes usuelles pour ne renvoyer que le signal. Je l’ai branché via les hooks de Claude Code, donc sans surcoût dans le prompt et sans rien à retenir de ma part.

Trouver le bon code était trop lent. Sur un gros dépôt, un agent peut gâcher la moitié d’une session juste à redécouvrir la structure. semtree fait de la recherche de code sémantique en local (parsing tree-sitter, embeddings locaux, index HNSW, zéro clé d’API) pour que l’agent demande « où est la logique qui fait X ? » et obtienne le code pertinent, pas mille résultats de grep.

Au-dessus, il y a les pièces ennuyeuses mais essentielles : un CLAUDE.md par projet qui encode les conventions et les pièges (le fichier au plus fort effet de levier que je maintiens ; j’en ai parlé ailleurs), et quelques skills maison pour les workflows que je répète.

Rien d’exotique là-dedans. C’est de la plomberie. Mais une plomberie que l’IDE ne m’a jamais laissé construire, parce que je ne possédais pas les tuyaux. C’est tout l’argument en une phrase : le terminal a gagné parce que j’ai pu construire autour.

Pour qui c’est, et pour qui ça ne l’est pas

Je me méfie des conseils universels, alors cadrons.

Ce setup convient à un ingénieur sénior et autonome qui connaît déjà assez la codebase pour superviser un agent et juger sa production. Si tu sais distinguer le bon travail du travail qui a l’air bon, le terminal te démultiplie. La composabilité et le contrôle sont du levier entre des mains expérimentées.

Il convient particulièrement au legacy et au back-end, où le travail est surtout comprendre, tracer et modifier avec prudence, et où l’outillage visuel compte moins.

Il convient moins bien si tu vis toute la journée dans le debug visuel et l’UI, ou si tu es assez tôt dans ta carrière pour ne pas encore repérer les erreurs assurées d’un agent. Les garde-fous et la découvrabilité de l’IDE y ont une vraie valeur, et « le terminal suppose que tu sais » cesse d’être une bizarrerie pour devenir un mur.

À retenir

L’opposition « IDE IA vs agent en terminal » est un peu un piège. Ce n’est pas vraiment le CLI contre l’IDE ; c’est la composabilité contre le verrouillage. Je ne suis pas passé au terminal parce qu’il est minimaliste ou nostalgique. J’y suis passé parce que c’est le seul environnement où l’agent peut atteindre tous les outils que j’utilise, où je vois ce qu’il fait, et, surtout, où je peux construire moi-même les pièces manquantes.

L’IDE est toujours ouvert dans une autre fenêtre. J’ai juste arrêté de lui demander de réfléchir.

trimcp et semtree, l’outillage Rust que j’ai construit, font partie de rustkit-ai. Je détaillerai les chiffres de tokens derrière trimcp dans un prochain article.

Déployer une app RAG Rust sur AWS avec Terraform : pourquoi j'ai choisi EC2 plutôt que Bedrock

Sat, 30 May 2026 00:00:00 GMT

Quand j’ai commencé à construire un système RAG en Rust pour documenter automatiquement des codebases legacy, la première question de production n’était pas sur le modèle ni sur les embeddings. C’était : où est-ce que je fais tourner ça ?

La réponse évidente en 2026, c’est AWS Bedrock. C’est managé, ça scale, et AWS le pousse fort. J’ai choisi EC2. Cet article explique pourquoi, et détaille l’infrastructure Terraform que j’ai construite pour que ça tourne correctement.

Pourquoi pas Bedrock ?

Bedrock est le bon choix pour beaucoup d’équipes. Mais pas pour moi, pour trois raisons.

J’avais besoin de Qdrant. L’application utilise Qdrant comme base de données vectorielle, un moteur de recherche de similarité haute performance écrit en Rust. Le store vectoriel natif de Bedrock, c’est Amazon OpenSearch Serverless ou pgvector. Migrer vers l’un ou l’autre aurait signifié réécrire la logique de requêtes principale et perdre des fonctionnalités dont je dépendais : collections nommées, filtrage de payload, métriques de distance fine.

Je fais tourner un binaire Rust, pas du Python. La plupart des tutos Bedrock supposent LangChain + Python. Mon backend est un binaire Rust compilé. L’overhead d’adapter l’architecture à Lambda (cold starts, taille du binaire, async runtime) ne valait pas le coup pour un outil interne à trafic prévisible.

La prédictibilité des coûts comptait. Bedrock facture au token consommé. Pour un outil qui indexe des codebases Java entières (parfois des millions de tokens par projet), la facturation devient imprévisible. Un EC2 t3.medium à ~30€/mois est plus facile à raisonner.

La stack

Avant d’entrer dans Terraform, voici ce que je déploie :

Backend : binaire Rust packagé en image Docker, faisant tourner le moteur RAG, l’API HTTP et le serveur MCP
Frontend : app Angular servie via nginx dans un second conteneur Docker
Store vectoriel : Qdrant, en conteneur Docker sur la même instance
Base de données : SQLite pour les métadonnées de projets (pas de RDS, ça garde les coûts bas)
LLM provider : OpenRouter (appelle Claude, GPT-4, etc. via une seule API)

Tout tourne sur une instance EC2 derrière un Application Load Balancer. Pas de microservices. Pas de Kubernetes. Une instance avec Docker Compose.

L’infrastructure

Voici la vue complète de ce que Terraform provisionne :

Internet
    │
    ▼
ALB (HTTPS:443 / HTTP:80→301)
    │
    ▼
EC2 t3.medium (Amazon Linux 2023)
    ├── conteneur nginx    (port 3000 → frontend)
    ├── conteneur backend  (port 8080 → API Rust)
    └── conteneur qdrant   (port 6333 → vector DB)
         │
         ▼
    Volume EBS gp3 (/data persistant)
         ├── qdrant_storage/
         └── bases SQLite

Tous les secrets (clés API LLM, credentials OAuth) vivent dans AWS Secrets Manager et sont injectés dans l’instance EC2 au démarrage via user_data.

Les images sont stockées dans ECR et tirées à chaque déploiement.

Les décisions Terraform clés

Le remote state d’abord

Avant terraform apply, il faut un endroit pour stocker le state. Deux commandes AWS CLI :

aws s3 mb s3://my-app-tfstate --region eu-west-1
aws dynamodb create-table \
  --table-name my-app-tflock \
  --attribute-definitions AttributeName=LockID,AttributeType=S \
  --key-schema AttributeName=LockID,KeyType=HASH \
  --billing-mode PAY_PER_REQUEST \
  --region eu-west-1

Puis l’init avec le backend :

terraform init \
  -backend-config="bucket=my-app-tfstate" \
  -backend-config="key=prod/terraform.tfstate" \
  -backend-config="region=eu-west-1" \
  -backend-config="dynamodb_table=my-app-tflock"

La table DynamoDB fournit le state locking, ce qui est critique si plusieurs ingénieurs ou pipelines CI exécutent Terraform en parallèle.

Le problème du stateful : Qdrant sur EBS

C’est la décision architecturale la plus importante. Qdrant stocke les collections vectorielles sur disque. Si on laisse Terraform détruire et recréer l’instance EC2 (ce qui arrive lors de mises à jour d’AMI ou de changements de type d’instance), on perd toutes les données indexées. Réindexer une grande codebase prend des heures.

La solution : un volume EBS séparé avec prevent_destroy :

resource "aws_ebs_volume" "data" {
  availability_zone = var.availability_zones[0]
  size              = var.data_volume_size_gb
  type              = "gp3"
  encrypted         = true

  lifecycle {
    prevent_destroy = true
  }
}

resource "aws_volume_attachment" "data" {
  device_name  = "/dev/xvdf"
  volume_id    = aws_ebs_volume.data.id
  instance_id  = aws_instance.app.id
  force_detach = false
}

Le prevent_destroy = true signifie que Terraform refusera d’exécuter tout plan qui supprimerait ce volume. C’est un garde-fou contre un terraform destroy accidentel. Si j’ai vraiment besoin de le supprimer, je retire le bloc lifecycle, j’applique, puis je détruis.

Sur l’instance, /data est monté depuis ce volume au démarrage via user_data. Les bases SQLite et les collections Qdrant vivent toutes là. L’instance est remplaçable ; le volume de données ne l’est pas.

J’ai aussi mis en place des sauvegardes AWS Backup quotidiennes :

resource "aws_backup_plan" "daily" {
  name = "${local.prefix}-backup-daily"

  rule {
    rule_name         = "daily-7days"
    target_vault_name = aws_backup_vault.main.name
    schedule          = "cron(0 2 * * ? *)"

    lifecycle {
      delete_after = 7
    }
  }
}

Sept jours de snapshots quotidiens. Si quelque chose corrompt le storage Qdrant, je restaure depuis la sauvegarde de la nuit précédente.

Secrets Manager pour les clés LLM

Ne jamais mettre des clés API dans terraform.tfvars ou dans des variables d’environnement dans user_data. J’utilise Secrets Manager :

resource "aws_secretsmanager_secret" "openrouter_api_key" {
  name                    = "${local.prefix}/openrouter-api-key"
  recovery_window_in_days = 7
}

resource "aws_secretsmanager_secret_version" "openrouter_api_key" {
  secret_id     = aws_secretsmanager_secret.openrouter_api_key.id
  secret_string = "PLACEHOLDER_SET_ME"

  lifecycle {
    ignore_changes = [secret_string]
  }
}

Le ignore_changes = [secret_string] est essentiel : Terraform crée le secret avec un placeholder, puis je mets la vraie valeur via CLI. Les terraform apply suivants n’écraseront pas ce que j’ai défini manuellement.

aws secretsmanager put-secret-value \
  --secret-id arn:aws:secretsmanager:eu-west-1:...:secret:prod/openrouter-api-key \
  --secret-string "sk-or-v1-..."

L’instance EC2 a un rôle IAM avec la permission de lire ces secrets. Le user_data les récupère au démarrage et les injecte comme variables d’environnement dans le stack Docker Compose.

ALB avec TLS automatique

L’ALB gère la terminaison TLS. Si je fournis un domain_name et un zone_id Route 53, Terraform crée et valide automatiquement un certificat ACM :

resource "aws_acm_certificate" "main" {
  count             = local.has_domain ? 1 : 0
  domain_name       = var.domain_name
  validation_method = "DNS"

  lifecycle {
    create_before_destroy = true
  }
}

Le HTTP sur le port 80 redirige vers HTTPS avec un 301. La politique TLS est ELBSecurityPolicy-TLS13-1-2-2021-06, qui impose TLS 1.3 et 1.2 uniquement.

Sans domaine, la stack fonctionne quand même : j’obtiens un endpoint DNS ALB en HTTP uniquement. Pratique pour les environnements de staging.

CI/CD sans credentials long-lived

L’approche classique pour GitLab CI → AWS consiste à créer un utilisateur IAM, générer des access keys et les stocker dans les variables CI. Ça marche, mais vous vous retrouvez avec des credentials statiques qui n’expirent jamais et sont stockés dans les paramètres GitLab pour toujours.

La meilleure approche : la fédération OIDC. GitLab génère un JWT signé pour chaque exécution de pipeline. AWS vérifie le JWT auprès du provider OIDC de GitLab et émet des credentials temporaires. Aucune clé statique nulle part.

resource "aws_iam_openid_connect_provider" "gitlab" {
  url             = var.gitlab_url
  client_id_list  = [var.gitlab_url]
  thumbprint_list = [var.gitlab_oidc_thumbprint]
}

resource "aws_iam_role" "gitlab_ci" {
  name                 = "${local.prefix}-gitlab-ci"
  assume_role_policy   = data.aws_iam_policy_document.gitlab_ci_assume.json
  max_session_duration = 3600
}

La trust policy restreint quels pipelines peuvent assumer le rôle : uniquement la branche main et les tags du projet spécifique :

condition {
  test     = "StringLike"
  variable = "<votre-gitlab-host>:sub"
  values = [
    "project_path:<votre-groupe>/<votre-projet>:ref_type:branch:ref:main",
    "project_path:<votre-groupe>/<votre-projet>:ref_type:tag:ref:*",
  ]
}

Dans .gitlab-ci.yml, le job demande un token OIDC et l’échange contre des credentials AWS :

deploy:
  id_tokens:
    AWS_OIDC_TOKEN:
      aud: https://<votre-gitlab-host>
  script:
    - >
      export $(aws sts assume-role-with-web-identity
      --role-arn $OIDC_ROLE_ARN
      --web-identity-token $AWS_OIDC_TOKEN
      --role-session-name gitlab-ci
      --query 'Credentials.[AccessKeyId,SecretAccessKey,SessionToken]'
      --output text | awk '{print "AWS_ACCESS_KEY_ID="$1"\nAWS_SECRET_ACCESS_KEY="$2"\nAWS_SESSION_TOKEN="$3}')
    - docker build -t $ECR_BACKEND_IMAGE .
    - docker push $ECR_BACKEND_IMAGE
    - aws ssm send-command --instance-ids $INSTANCE_ID --document-name AWS-RunShellScript --parameters 'commands=["cd /app && docker compose pull && docker compose up -d"]'

Le rôle CI a uniquement la permission de pusher vers ECR et de déclencher des commandes SSM sur l’instance EC2. Rien d’autre.

Ce que je referais différemment

ECS Fargate pour les conteneurs applicatifs, EC2 pour Qdrant. Les conteneurs applicatifs (backend, frontend) sont stateless : ils sont parfaits pour Fargate. La seule raison pour laquelle j’ai tout gardé sur EC2, c’était la simplicité opérationnelle au départ. Avec Fargate pour l’app et une instance EC2 dédiée pour Qdrant, on obtient des déploiements rolling et une meilleure isolation des pannes.

RDS PostgreSQL plutôt que SQLite pour les métadonnées. SQLite fonctionne bien pour une instance unique, mais crée des problèmes dès qu’on veut scaler horizontalement ou faire du blue/green deployment. Le coût de migration est faible ; le gain en flexibilité future est élevé.

Mettre en place les alarmes CloudWatch dès le premier jour. J’ai ajouté le monitoring après le premier incident en production. L’alarme sur le compteur d’hôtes unhealthy de l’ALB devrait être la première chose qu’on crée, pas la dernière.

Conclusion

Choisir EC2 plutôt que Bedrock n’était pas idéologique. C’était une réponse pragmatique à trois contraintes : Qdrant comme store vectoriel, un binaire Rust compilé, et la prédictibilité des coûts pour une charge d’indexation variable.

L’infrastructure Terraform décrite ici (environ 500 lignes réparties sur huit fichiers) provisionne un déploiement production avec TLS, sauvegardes quotidiennes, CI/CD sans credentials, et stockage persistant protégé. Ce n’est pas le setup le plus simple, mais chaque élément justifie sa présence.

Si vous faites tourner une application AI self-hosted avec des contraintes similaires, le pattern EC2 + EBS + Secrets Manager vaut le coup d’être considéré. La charge opérationnelle est réelle, mais le contrôle et le profil de coût le justifient souvent.

Le template Terraform complet de cet article, généralisé et prêt à forker, est disponible sur github.com/Strawbang/terraform-aws-ai-stack.

Comment la standardisation d'une stack technique a réduit les cycles de création de 80%

Tue, 05 May 2026 00:00:00 GMT

Quand j’ai rejoint l’équipe produit de METRO France en tant que consultant via Wemanity Group, l’organisation d’ingénierie avait un problème qui n’était pas évident de l’extérieur : chaque produit était construit en silo.

Les différentes équipes avaient fait des choix technologiques différents. Certains produits utilisaient un framework, d’autres un autre. Pas de librairie de composants partagée, pas de conventions API communes, pas de stratégie de déploiement unifiée. Un ingénieur qui passait d’un produit à l’autre devait repartir de zéro. Chaque nouvelle fonctionnalité impliquait de réinventer des décisions déjà prises ailleurs.

Le résultat était prévisible : onboarding lent, effort dupliqué, déploiements fragiles, et un sentiment croissant que l’organisation d’ingénierie ne pouvait pas suivre le rythme du business.

Voici comment nous avons résolu le problème, et ce que j’ai appris sur le vrai coût de la fragmentation technique.

Le problème avec la diversité “suffisante”

Il existe un argument séduisant pour laisser les équipes choisir leurs outils : l’autonomie stimule la créativité, et chaque équipe connaît mieux son problème. Ce n’est pas entièrement faux. Mais à une certaine échelle, cette autonomie devient une taxe.

Chez METRO France, la taxe se manifestait de trois façons :

Latence à l’onboarding. Un nouvel ingénieur rejoignant une équipe ne pouvait pas contribuer pendant des semaines, car il devait apprendre une stack propre au produit depuis zéro. Il n’existait aucune connaissance fondamentale transférable.

Pas de réutilisation. Un composant construit par une équipe pour résoudre un problème UX ne pouvait pas être utilisé par une autre, même quand le problème était identique. Chaque équipe réinventait les mêmes solutions.

Fragilité des déploiements. Sans patterns d’infrastructure partagés, chaque produit avait ses propres particularités de déploiement. Un correctif dans un pipeline n’aidait pas les autres. Les incidents étaient isolés mais fréquents.

L’impact business était clair : construire un nouveau produit prenait des mois. Itérer sur un produit existant prenait plus de temps que nécessaire. La dette technique s’accumulait silencieusement dans chaque codebase.

Choisir un standard qui tient dans le temps

La première décision, et la plus politiquement délicate, était de choisir la stack.

Nous avons retenu TypeScript, React, Node.js, TypeORM et GraphQL pour le développement applicatif, GCP et Kubernetes pour l’infrastructure, et GitHub Actions pour la CI/CD.

Ce n’était pas un choix arbitraire. Chaque technologie a été sélectionnée pour une raison précise :

TypeScript plutôt que JavaScript seul : typage fort, meilleur support IDE, et un contrat partagé entre les équipes front-end et back-end.
React pour le front-end : écosystème large, réutilisation de composants, et un vivier de talents suffisamment profond pour recruter.
Node.js + GraphQL pour la couche API : interface de requête unifiée, typage fort avec génération de code, et capacité à agréger des sources de données sans sur-récupération.
GCP + Kubernetes : déjà partiellement en place, bien documenté, et scalable jusqu’aux 93 entrepôts.

L’insight clé : un standard ne tient que s’il est réellement meilleur pour les équipes, pas seulement sur le papier. Nous avons choisi des technologies avec lesquelles il était genuinement productif de travailler, pas les plus à la mode ni les plus théoriquement correctes.

Implémentation : adoption avant obligation

La plus grande erreur des organisations qui standardisent est de rendre la conformité obligatoire avant de démontrer la valeur.

Nous avons fait l’inverse. Avant de demander à quelque équipe que ce soit de changer sa stack, nous avons construit une implémentation de référence : un vrai petit produit avec le nouveau standard, déployé en production. Il fallait que ça marche, pas juste que ça soit beau en démo.

Une fois cette référence existante, l’adoption s’est propagée plus vite que prévu. Les ingénieurs pouvaient voir les patterns en action. Ils pouvaient poser des questions avec de vrais exemples en main. Le nouveau standard n’était pas un document de politique. C’était du code fonctionnel.

À partir de là, nous avons introduit des outils partagés : un design system avec des composants React réutilisables, des configs TypeScript communes, des règles ESLint encodant les décisions architecturales, et un template de pipeline CI/CD que les équipes pouvaient copier et adapter.

Les nouveaux produits démarraient sur la nouvelle stack par défaut. Les produits existants migraient progressivement, pas d’un coup pour éviter les perturbations, mais module par module, au fil des nouvelles fonctionnalités ou des refactorisations.

Le produit de gestion des primes : une étude de cas dans l’étude de cas

L’exemple le plus concret de ce qu’a permis cette standardisation est le produit de gestion des primes employés.

Les 93 entrepôts de METRO France géraient les primes via des tableurs. Les responsables de rayons saisaient les données manuellement, les RH consolidaient avec un décalage significatif, et les erreurs étaient fréquentes. Le processus était chronophage, non auditable, et une source récurrente d’insatisfaction des employés.

Construire ce produit dans l’ancien monde aurait nécessité des mois de mise en place, des outils custom, et une équipe qui n’aurait pas pu être réutilisée ailleurs ensuite.

Dans le nouveau monde, nous l’avons construit sur la stack standardisée dès le départ. Nous avons réutilisé des composants partagés pour l’UI. L’API GraphQL suivait les patterns établis. Le pipeline de déploiement était templaté. L’équipe qui l’a construit avait déjà travaillé sur d’autres produits dans la nouvelle stack et a été opérationnelle immédiatement.

Le produit a été déployé sur les 93 entrepôts à l’échelle nationale. Le calcul des primes est passé des tableurs à un système digital auditable. Les responsables ont signalé un traitement plus rapide. Les RH ont libéré du temps significatif. Les scores de satisfaction employé dans les entrepôts se sont améliorés de façon mesurable.

Mais au-delà du produit lui-même, le résultat le plus significatif était ce qu’il démontrait : la stack standardisée était devenue un multiplicateur. Construire ce produit avait pris une fraction du temps qu’il aurait fallu avant.

Les 80%

L’accélération de 80% des cycles de création de produits que nous avons mesurée n’était pas de la magie : c’était la somme de plusieurs effets qui se composent :

Pas de délibération sur le choix de stack. Les équipes commençaient à construire immédiatement, sans débat sur les technologies.
Les composants partagés réduisaient le travail UI de 40 à 60% sur les nouveaux produits.
Les pipelines CI/CD templatés éliminaient des semaines de mise en place d’infrastructure par projet.
Le transfert de connaissance inter-équipes signifiait que les ingénieurs pouvaient contribuer à n’importe quel produit dès le premier jour.
Moins d’incidents grâce à des patterns d’infrastructure mieux compris et mieux documentés.

Chacun de ces effets seul aurait été significatif. Ensemble, ils ont transformé la capacité de l’organisation à livrer.

Ce que les leaders techniques devraient savoir

Si vous envisagez un effort de standardisation dans votre organisation, voici ce que je retiens de cette expérience :

Partez de la douleur. L’argument pour la standardisation doit être ancré dans des problèmes réels, pas dans l’élégance théorique. Montrez le coût de l’onboarding. Montrez l’effort dupliqué. Montrez les incidents de déploiement. Rendez visible le coût de l’état actuel.

Construisez avant d’imposer. Une implémentation de référence vaut dix documents de stratégie. Livrez quelque chose de réel en production, puis montrez pourquoi la nouvelle façon est meilleure.

Standardisez les décisions, pas les outils. L’objectif n’est pas l’uniformité pour elle-même : c’est réduire la fatigue décisionnelle et permettre la réutilisation. Une config TypeScript partagée est plus précieuse qu’un framework imposé, parce qu’elle supprime une décision de bas niveau sans contraindre l’architecture de plus haut niveau.

Attendez-vous à une migration progressive. Tout réécrire d’un coup casse les choses et épuise les ingénieurs. Migrez incrémentalement, produit par produit, module par module. Les nouveaux projets adoptent le standard par défaut ; les existants migrent au fil de leur évolution.

Mesurez le résultat, pas le processus. La métrique qui compte est la vélocité de livraison, pas le “pourcentage de produits sur la nouvelle stack”. Suivez ce qui vous importe vraiment.

Standardiser une stack technique est, dans le fond, un pari que l’infrastructure partagée crée plus de valeur que l’autonomie individuelle. Chez METRO France, ce pari a clairement payé : livraison plus rapide, meilleurs produits, et une équipe d’ingénierie capable de travailler ensemble plutôt qu’en silos parallèles.

Les 80% sont réels, mais ce qu’ils représentent est plus important : quand les ingénieurs arrêtent de réinventer les mêmes décisions encore et encore, ils peuvent passer ce temps à construire des choses qui comptent vraiment pour les utilisateurs.

C’est ça, le vrai point.

L'IA a cassé notre code de production. Voilà la règle du Craftsmanship qui aurait tout évité

Mon, 04 May 2026 00:00:00 GMT

Quand des outils capables de générer du code à grande échelle deviennent courants, on est tenté de penser que les anciennes règles ne s’appliquent plus. Pourquoi se battre sur le nommage si l’IA comprend n’importe quel nom de variable ? Pourquoi écrire des tests si l’IA va de toute façon réécrire la fonction ? Pourquoi refactorer quand générer une nouvelle implémentation est plus rapide que nettoyer l’ancienne ?

Ce raisonnement est dangereux. Et dans mon expérience, les codebases qui souffrent le plus du développement assisté par IA sont ceux qui ont abandonné la discipline en premier.

Ce qu’est vraiment le Software Craftsmanship

Le Software Craftsmanship, formalisé dans le manifeste de 2009, est un ensemble de standards professionnels : code propre, développement piloté par les tests, refactoring continu, design simple, et ownership collectif. Il traite le code comme un artisanat : quelque chose dont on est fier, quelque chose qu’on entretient.

Ce n’est pas une quête de perfection. C’est une responsabilité professionnelle.

Les principes qui ont survécu

Après avoir travaillé avec des outils IA sur des codebases de production pendant plus d’un an, voici ce que j’ai constaté : les principes du craftsmanship ne disparaissent pas. Ils deviennent porteurs.

1. Les tests sont votre seul filet de sécurité

C’était vrai avant l’IA. C’est critique maintenant.

L’IA génère du code rapidement mais sans compréhension profonde de l’intention. Elle peut produire du code qui passe la revue manuelle et casse silencieusement une règle métier qui n’a jamais été écrite. Les tests sont le seul moyen systématique de détecter ça.

Je l’ai vécu directement. Sur une codebase Java legacy sans couverture de tests, un agent IA a refactorisé en toute confiance un calcul qui tournait depuis des années. Le changement semblait correct, passait le linter, et introduisait une régression silencieuse sur une règle métier que personne n’avait documentée. Il n’y avait aucun test pour l’attraper. Ça a remonté en production. C’est cette session qui m’a fait arrêter de traiter le craftsmanship comme optionnel avec l’IA. J’ai commencé à le traiter comme une précondition.

Le TDD en particulier change la dynamique : écrire le test en premier vous force à définir ce que “correct” signifie avant que l’IA ne propose une implémentation. L’IA a alors une cible à atteindre. Sans cette cible, vous relisez du code en espérant qu’il soit juste. Ce n’est pas de l’ingénierie, c’est de l’optimisme.

J’ai arrêté de traiter la couverture de tests comme une métrique. Je la traite comme une précondition. Si l’IA fait un changement qui n’est pas couvert par des tests, soit les tests passent en premier, soit le changement n’a pas lieu.

Certains dans la communauté craftsmanship avancent que le TDD ne s’applique plus de la même façon quand c’est l’IA qui écrit le code, et ils ont raison sur un point : la mécanique change. Le cycle classique Rouge → Vert → Refactoring était conçu pour un humain qui écrit à la fois le test et l’implémentation, où l’acte de coder est lui-même une activité de design.

Avec l’IA, cette partie change. Mais le contrat que crée le test, lui, ne change pas.

Le test écrit avant l’implémentation définit toujours ce que “correct” signifie. Il vous force toujours à réfléchir au comportement attendu avant de générer quoi que ce soit. L’IA écrit le Vert, mais vous possédez le Rouge. Et le Refactoring reste entièrement le vôtre. Ce qui disparaît, c’est la boucle de feedback design-par-implémentation. Ce qui reste, et ce qui compte le plus sur des codebases legacy avec l’IA, c’est le contrat de sécurité.

Concrètement, avant de demander à une IA de toucher de la logique métier, j’écris d’abord un test de caractérisation :

// Étape 1 : écrire le test qui définit ce que "correct" signifie
@Test
void shouldApplyReducedVatRateForB2bGermanOrders() {
    Order order = Order.builder()
        .amount(new BigDecimal("1000"))
        .customerType(CustomerType.B2B)
        .country("DE")
        .build();

    BigDecimal vat = vatService.calculateVat(order);

    // Allemagne B2B : 19%, pas le taux standard de 20%
    assertThat(vat).isEqualByComparingTo(new BigDecimal("190"));
}

// Étape 2 : maintenant l'IA a une cible, et un filet de sécurité

Sans ce test, l’IA aurait refactorisé calculateVat() pour utiliser une constante VAT_RATE = 0.20 : propre, cohérent, et silencieusement faux pour toutes les commandes B2B allemandes.

2. La lisibilité, c’est pour le prochain humain

L’IA peut parser n’importe quel code. Les humains, non.

L’argument “l’IA le comprend, donc le nommage n’a pas d’importance” confond l’outil et le processus. Quand un bug remonte à 2h du matin, ce n’est pas l’IA qui est réveillée. Quand un nouveau développeur rejoint l’équipe, il lit le code dans une revue de PR, pas dans une fenêtre de chat. Quand votre tech lead remet en question un choix d’architecture, il a besoin de comprendre l’intention, pas seulement la mécanique.

Le code propre est une documentation qui ne vieillit jamais mal. Dans le développement assisté par IA, où le volume de code généré augmente, la lisibilité devient une propriété plus précieuse, pas moins.

Une variable nommée result est de la dette technique. Une variable nommée facturesEligiblesAuRecouvrement est autodocumentée. L’IA s’en fiche. Votre équipe, non.

// Ce que l'IA génère souvent : correct, illisible
BigDecimal r = o.getA().multiply(getR(o.getC(), o.getT()));

// Ce que le craftsmanship exige
BigDecimal montantTVA = commande.getSousTotal()
    .multiply(resolveurTauxTVA.resoudre(commande.getPays(), commande.getTypeClient()));

La deuxième version ne fait pas que mieux paraître. Quand le bug TVA remonte à 2h du matin, votre collègue trouve la bonne classe en 10 secondes plutôt qu’en 10 minutes.

3. Des changements petits, réversibles par défaut

Les outils IA adorent générer de grands changements. Une seule invite peut toucher 20 fichiers, renommer 3 abstractions et restructurer 2 modules. C’est genuinement utile, et genuinement dangereux.

Le principe du craftsmanship ici est : gardez les changements petits et réversibles. Un concept par commit. Les tests avant le refactoring. Un diff qu’un collègue peut relire en 15 minutes sans perdre le contexte.

C’est aussi là que la règle du Boy Scout prend tout son sens : laissez le code un peu meilleur que vous l’avez trouvé. Pas complètement redesigné. Pas entièrement modernisé. Juste un peu plus propre. Cette discipline évite le problème “l’IA a fait un gros refactoring en corrigeant un bug” qui transforme une PR de routine en une session de revue de 3 heures.

# Ce que l'IA tend à produire : un commit massif impossible à relire
git log --oneline
# a3f9c12 refactor order processing
# (touche : OrderService, VatCalculator, InvoiceGenerator,
#  PaymentProcessor, OrderRepository, OrderMapper : 847 lignes modifiées)

# Ce que le craftsmanship donne
# 1f2a3b4 PROJ-421: extraire VatRateResolver de OrderService
# 8c9d0e1 PROJ-421: ajouter taux TVA B2B pour DE, AT, CH
# 2e3f4a5 PROJ-421: couvrir VatRateResolver avec des tests unitaires
# 7b8c9d0 PROJ-421: corriger taux TVA incorrect sur les commandes B2B allemandes

Le deuxième historique est relisible, bisectable et réversible. Le premier est un pari.

4. Le refactoring est une pratique continue, pas un sprint

Le code généré par IA tend vers la duplication. Demandez à une IA d’implémenter une fonctionnalité, et elle créera souvent une nouvelle version de quelque chose qui existe déjà à proximité. Ce n’est pas faux. Elle répond au problème immédiat sans connaître toute la codebase.

La discipline, c’est l’étape de refactoring qui suit. Avant de merger, posez-vous la question : est-ce que ça duplique quelque chose ? Est-ce que ça appartient ici ? Y a-t-il une meilleure abstraction ?

Ce n’est pas le travail de l’IA. C’est le vôtre. L’IA est bonne pour exécuter. Elle n’est pas bonne pour savoir quand quelque chose est déjà fait correctement ailleurs dans une codebase de 200k lignes. C’est la connaissance institutionnelle. C’est le craftsmanship.

// L'IA a généré ça dans OrderService : correct en isolation
private BigDecimal appliquerRemise(BigDecimal montant, String typeClient) {
    if ("B2B".equals(typeClient)) return montant.multiply(new BigDecimal("0.90"));
    return montant;
}

// Mais ça existait déjà dans PricingService, depuis 3 ans
public BigDecimal appliquerRemiseClient(BigDecimal prixBase, TypeClient type) {
    return prixBase.multiply(configRemise.getTauxPour(type));
}

Deux implémentations de la même logique, divergeant silencieusement. L’IA ne savait pas. Vous, si, à condition de regarder.

5. L’ownership collectif exige des standards explicites

Le principe le plus sous-estimé du manifeste craftsmanship est l’ownership collectif du code : l’idée que toute l’équipe est responsable de toute la codebase, pas seulement de “ses” modules.

Les outils IA rendent ça plus difficile par défaut. Tout le monde utilise ses propres prompts, son propre modèle, son propre style. Sans standards partagés explicites, le développement assisté par IA accélère la divergence : conventions de nommage différentes, styles de tests différents, niveaux d’abstraction différents dans le même service.

La solution est explicite : un CLAUDE.md, un CONTRIBUTING.md, des règles de linting sans exceptions, des templates de PR qui imposent la checklist de revue. Ce n’est pas de la bureaucratie. C’est l’échafaudage qui rend l’ownership collectif possible quand une partie de l’équipe est une IA.

# CLAUDE.md (extrait)

## Règles non négociables
- Ne jamais modifier `LegacyOrderMapper` sans tests de caractérisation d'abord
- Toutes les valeurs monétaires en **centimes (Long)**, jamais BigDecimal en base de données
- Les taux de TVA vivent dans `VatRateConfig` : ne jamais les coder en dur
- Ne PAS ajouter `@Transactional` aux jobs du scheduler : ils maintiennent des connexions pendant des minutes

## Avant tout refactoring
1. Écrire des tests qui décrivent le comportement actuel
2. Confirmer que les tests passent sur le code non modifié
3. Refactoriser
4. Confirmer que les tests passent toujours

Ce fichier est le contrat partagé. Chaque développeur le lit. L’agent IA le lit. Les standards cessent d’être des habitudes individuelles et deviennent de l’infrastructure d’équipe.

Mais le CLAUDE.md est une contrainte douce : l’IA le respecte si vous le configurez. Les règles de linting sont des contraintes dures : le CI casse si quiconque, humain ou IA, les viole.

Pour l’architecture hexagonale en particulier, eslint-plugin-boundaries impose l’isolation des couches au niveau des imports :

// .eslintrc : les frontières architecturales comme règles de linting
"boundaries/element-types": ["error", {
  default: "disallow",
  rules: [
    // Le domaine est pur : aucun import externe autorisé
    { from: "domain", allow: [] },
    // La couche application ne dépend que du domaine
    { from: "application", allow: ["domain"] },
    // Seuls les adapters peuvent toucher l'infrastructure
    { from: "adapters", allow: ["application", "domain"] },
  ]
}]

Si l’IA génère import { PrismaClient } from '@prisma/client' à l’intérieur de votre domaine, le pipeline échoue immédiatement, avant la revue, avant le merge, avant la production. L’architecture s’applique d’elle-même.

En Java, vous avez trois options selon jusqu’où vous souhaitez aller :

ArchUnit : appliqué comme assertion de test, utile sur les codebases legacy où restructurer n’est pas une option :

@Test
void domainShouldNotDependOnInfrastructure() {
    noClasses().that().resideInAPackage("..domain..")
        .should().dependOnClassesThat()
        .resideInAPackage("..infrastructure..")
        .check(importedClasses);
}

Multi-module Maven/Gradle : contrainte structurelle. Si domain ne déclare pas infrastructure comme dépendance, l’import ne peut physiquement pas compiler :

<!-- domain/pom.xml : infrastructure n'est tout simplement pas là -->
<dependencies>
    <!-- pas de dépendance infrastructure = aucun import possible -->
</dependencies>

JPMS (Java 9+) : l’option la plus native. module-info.java déclare exactement ce que chaque module peut voir. Pas de requires infrastructure = erreur de compilation, point final :

// domain/src/main/java/module-info.java
module com.example.domain {
    exports com.example.domain.model;
    exports com.example.domain.port;
    // pas de 'requires infrastructure' : l'import est une erreur de compilation
}

Sur un projet greenfield, multi-module ou JPMS est la bonne réponse. ArchUnit brille sur les codebases legacy où vous ne pouvez pas encore restructurer mais avez besoin du garde-fou immédiatement.

C’est la différence entre les guidelines et la gouvernance. Le CLAUDE.md dit à l’IA quoi faire. Le linter, ou le compilateur, rend impossible de faire autrement.

Ce que l’IA change vraiment

Pour être honnête : l’IA change bien certaines choses.

L’exploration est plus rapide. Comprendre une nouvelle codebase, tracer un flux de données, trouver où vit un bug. L’IA compresse ça de plusieurs heures à quelques minutes. C’est genuinement bon. La partie archéologie du travail logiciel est de toute façon la moins porteuse de valeur artisanale.

Le boilerplate a disparu. Écrire un endpoint CRUD, un DTO, un mapper : ces choses ne nécessitent plus de craft. Elles nécessitent une spec claire. C’est un gain net : ça déplace le focus là où le jugement compte vraiment.

Le craft est dans les contraintes. La compétence n’est plus dans la frappe. Elle est dans la définition de ce qui est correct avant de générer. La spécification, le test, le CLAUDE.md, la revue : ce sont les surfaces du craft. Elles ont toujours été les parties les plus importantes. L’IA ne fait que le rendre évident.

Le risque se multiplie sans discipline. Un développeur sans rigueur écrit du mauvais code lentement. Un développeur sans rigueur avec l’IA écrit du mauvais code vite. Le volume d’output augmente, mais la surface des régressions silencieuses, du couplage caché, et des règles métier cassées par un modèle confiant qui n’avait aucun test pour le corriger, augmente avec lui.

La responsabilité reste la vôtre

Voici où j’en suis arrivé : l’IA ne réduit pas la responsabilité d’un développeur senior. Elle la déplace en amont.

Avant : écrire le code, relire le code, tester le code.
Avec l’IA : définir ce que correct signifie, contraindre la génération, valider l’output.

La deuxième boucle demande autant de discipline. Peut-être plus. Parce que le volume d’output est plus élevé, la surface de revue est plus large, et les raccourcis cognitifs sont plus faciles à prendre.

Le Software Craftsmanship est la discipline qui vous garde honnête dans cette boucle.

Les principes n’ont pas été remplacés. Ils sont devenus le travail.

Et si vous managez une équipe, votre responsabilité est double : pratiquer ces standards vous-même, mais aussi en faire le socle commun depuis lequel tout le monde, humain et IA, opère.

Points clés à retenir

Les tests sont une précondition, pas une métrique. Si l’IA fait un changement sans couverture de tests, soit les tests passent en premier, soit le changement n’a pas lieu.
La lisibilité est pour les humains, pas les modèles. L’IA peut parser n’importe quoi. Votre équipe, non. Le code propre est une documentation qui ne vieillit jamais mal.
Gardez les changements petits et réversibles. L’IA génère de grands diffs par défaut. Votre discipline est de la contraindre : un concept par commit, relisible en 15 minutes.
Le refactoring est votre travail, pas celui de l’IA. L’IA ne sait pas ce qui existe déjà ailleurs dans une codebase de 200k lignes. Vous, si.
Les standards explicites permettent l’ownership collectif. Sans CLAUDE.md, sans CONTRIBUTING.md, sans linting appliqué, le développement assisté par IA accélère la divergence dans votre équipe.
Le risque se multiplie sans discipline. Une équipe sans rigueur avec l’IA n’écrit pas du mauvais code lentement : elle en écrit vite.

Comment j'utilise Claude Code et Jira MCP pour moderniser les codebases legacy

Tue, 28 Apr 2026 00:00:00 GMT

Le code legacy, c’est le squelette de chaque entreprise qui a réussi. Il gère la facturation, traite les commandes, et contient des règles métier que personne ne comprend plus vraiment depuis des années. Il ne va nulle part et c’est précisément pour ça que le moderniser est essentiel.

Depuis plusieurs mois, j’utilise Claude Code avec le Jira MCP et un CLAUDE.md soigneusement rédigé pour naviguer et implémenter des changements dans des codebases Java legacy. Cet article est un retour concret sur ce workflow comment ça se passe, pourquoi ça fonctionne, et où ça échoue encore.

Le problème avec le code legacy

Avant de parler du setup, il faut nommer le vrai problème. Le code legacy n’est pas difficile parce qu’il est vieux. Il est difficile à cause de tout ce qui l’entoure :

Aucune documentation (ou pire, une doc qui ment)
Règles métier implicites enfouies dans des conditions que personne n’ose toucher
Pas de tests qui confirmeraient que ton changement ne casse rien
Les auteurs originaux sont partis, leur connaissance est partie avec eux
La peur, le vrai tueur de vélocité sur les projets legacy

L’approche classique c’est de lire le code, poser des questions, et faire des changements prudents. Ça marche, mais c’est lent. Un agent IA ne résout pas tout ça, mais il réduit drastiquement le temps passé sur la phase d’archéologie.

Le stack

Mon setup comporte trois éléments :

1. Claude Code

Claude Code est l’outil de coding agentique d’Anthropic. Il tourne dans ton terminal, a accès à ton système de fichiers, peut exécuter des commandes, et itère de lui-même. Contrairement à une interface de chat, il ne se contente pas de suggérer du code il lit des fichiers, fait des modifications, lance des tests, et corrige des erreurs.

Ce qui le rend puissant pour le travail legacy, c’est sa capacité à naviguer une large codebase sans que je lui dicte chaque étape. Je lui donne une tâche et du contexte, il détermine quels fichiers lire.

2. CLAUDE.md Le manuel du projet

Chaque projet reçoit un CLAUDE.md à la racine. Ce fichier, c’est le document d’onboarding de Claude Code. Il indique à l’agent ce qu’il doit savoir avant de toucher quoi que ce soit.

Voici le type de contenu que je mets dans un CLAUDE.md pour un projet Java enterprise typique :

## Vue d'ensemble

Application Spring Boot multi-modules Maven, Java 17.
Deux bases de données : PostgreSQL (données applicatives) + Oracle (ERP legacy, lecture seule).
Tous les services tournent en Docker en local.

## Commandes du quotidien

### Environnement
docker compose up -d          # démarre tous les conteneurs
docker compose logs -f api    # suit les logs de l'API
docker compose down           # arrête tous les conteneurs

### Build & run
./mvnw clean install -DskipTests   # build complet
./mvnw -pl api spring-boot:run     # lance uniquement le module api
./mvnw test -pl api                # lance les tests unitaires du module api

### Base de données
# PostgreSQL localhost:5432, base: appdb, user: appuser
./scripts/db-reset.sh              # drop + recréation + seed en local
./scripts/db-load-dump.sh prod     # charge un dump prod anonymisé (~5min)

# Oracle (ERP legacy) lecture seule, localhost:1521
# Ne jamais écrire directement utiliser le wrapper OracleService dédié

## Architecture
- api/          Contrôleurs REST + logique métier
- domain/       Entités, repositories (Spring Data JPA)
- integration/  Adaptateurs vers l'ERP Oracle (polling via Apache Camel)
- scheduler/    Jobs batch (Spring Batch)
- common/       DTOs, utils, constantes partagées

## Points sensibles
- L'ERP Oracle est en lecture seule ne jamais tenter d'écriture, ça corrompt les données en aval
- OrderService.createOrder() n'est PAS idempotent toujours vérifier les doublons avant
- LegacyCodeMapper utilise la réflexion, ajouter des champs casse silencieusement sans tests
- Ne PAS ajouter @Transactional aux jobs scheduler ils gardent les connexions ouvertes des minutes

## Git
Branches : main (prod), develop (intégration), PROJ-XXXX-description-courte (feature)
Commits : toujours préfixer avec le ticket "PROJ-123: ajout calcul TVA commandes EU"
Push : --force-with-lease uniquement, jamais --force

Ce fichier fait la différence entre Claude Code qui fait un changement correct et confiant, et un agent qui casse quelque chose par ignorance. Plus tu es précis, meilleurs sont les résultats.

La section points sensibles est la plus précieuse. Ce sont les choses qu’un nouveau développeur mettrait des semaines à découvrir. Les écrire une fois protège tout le monde y compris l’agent des régressions douloureuses.

3. Jira MCP

Le Jira MCP expose ton projet Jira comme un ensemble d’outils que Claude Code peut appeler. Concrètement, ça signifie que Claude Code peut :

Lire la description du ticket, les critères d’acceptance et les commentaires
Comprendre le contexte complet avant d’écrire la moindre ligne
Référencer les tickets liés et les sous-tâches
Poster un commentaire avec un résumé de ce qui a été fait

Mais la chose la plus puissante que j’ai construite par-dessus, c’est un skill custom dans CLAUDE.md :

## Skills disponibles

| Commande                    | Description                                                  |
|-----------------------------|--------------------------------------------------------------|
| `/tester-ticket <PROJ-XXXX>`| Lance les tests Playwright des critères d'acceptance Jira    |
| `/mr-push [app\|connector]` | Amend + rebase + force-push with lease                       |
| `/mr-comment [répondre\|poster]` | Lit et répond aux commentaires de MR GitLab             |
| `/build [app\|connector]`   | Build l'app ou le connecteur                                 |
| `/sonar [app\|connector]`   | Analyse SonarQube locale                                     |

Le skill /tester-ticket est celui qui a changé ma façon de travailler. Je lui donne une référence de ticket, Claude Code lit les critères d’acceptance depuis Jira, identifie les fichiers Playwright correspondants, les lance, et rapporte les résultats. La boucle complète écrire le code, tester contre le ticket réel sans quitter le terminal.

Mise en garde honnête cependant : il brûle beaucoup de tokens par exécution. Lire le ticket, naviguer les fichiers de test, lancer Playwright, interpréter les résultats tout ça s’accumule. Sur un ticket complexe avec plusieurs critères d’acceptance, une seule exécution de /tester-ticket peut coûter plus que tout le reste de la session réunis. Je l’utilise encore, mais de façon sélective pas comme étape par défaut à chaque changement.

Le workflow : du ticket à l’implémentation

Voici à quoi ressemble une session type.

Étape 1 Démarrer avec une référence de ticket

J’ouvre un terminal à la racine du projet et je lance Claude Code avec un prompt simple :

Lis le ticket JIRA PROJ-4821 et implémente le changement demandé.
Utilise CLAUDE.md pour le contexte du projet avant de toucher des fichiers.

C’est tout. Claude Code lit d’abord CLAUDE.md, puis appelle le Jira MCP pour récupérer le ticket, lit la description et les critères d’acceptance, et commence à explorer la codebase.

Étape 2 Claude Code explore la codebase

À partir du contenu du ticket, l’agent recherche les fichiers pertinents. Pour un ticket comme “Corriger le calcul de TVA incorrect pour les commandes B2B en Allemagne”, il va :

Chercher TVA, tax, germany, B2B dans toute la codebase
Lire les fichiers de service et de modèle concernés
Suivre la chaîne d’appels pour comprendre ce qui alimente le calcul
Vérifier s’il existe des tests pour ce flux

C’est la phase d’archéologie. La faire manuellement prend 30 à 60 minutes sur une codebase inconnue. Claude Code le fait en 2-3 minutes.

Étape 3 Implémentation avec des guardrails

Claude Code propose des changements basés sur ce qu’il a trouvé. Parce que CLAUDE.md établit les contraintes (pas de Lombok, montants en centimes, ne pas toucher les tables legacy_), les changements respectent les conventions existantes du projet.

Si l’agent est incertain, il demande. S’il trouve quelque chose de suspect dans le code qui pourrait être lié au ticket, il le signale.

Étape 4 Review et itération

Je review le diff, lance les tests, et itère. Claude Code ne remplace pas la review il compresse le temps passé avant la review.

Ce qui fonctionne vraiment bien

Après plusieurs mois d’utilisation de ce workflow, voici ce qui apporte de la valeur de manière constante :

Comprendre les flux de données : tracer comment une valeur passe de la base de données à la réponse API à travers 8 couches de services est fastidieux. Claude Code le fait bien.

Écrire des tests pour du code non testé : c’est sous-estimé. Avant de faire un changement, je demande à Claude Code d’écrire des tests de caractérisation pour le code concerné. Il lit le comportement existant et écrit des tests qui le décrivent. Ces tests détectent les régressions pendant le changement.

Faire remonter le code associé : l’agent trouve souvent du code lié au ticket mais non mentionné dedans. Logique dupliquée, code mort, une fonction similaire dans un autre module. Cette connaissance s’accumule avec le temps.

Traduire le langage du ticket en code : les parties prenantes métier rédigent des tickets en langage business. Les développeurs doivent traduire mentalement. Claude Code comble ce fossé plus efficacement que je ne l’aurais anticipé.

Ce qui ne fonctionne pas encore

L’honnêteté s’impose ici. Ce workflow n’est pas magique.

Les règles métier implicites : si la règle n’est pas écrite (dans CLAUDE.md, les commentaires, ou les tests), Claude Code ne l’inférera pas depuis les patterns du code. Une codebase legacy pleine d’hypothèses silencieuses le reste.

Les modules fortement couplés : quand tout dépend de tout, l’agent a du mal à faire un changement ciblé sans trop toucher. La solution, c’est l’architecture, pas le prompt.

Le coût en tokens des boucles de test automatisées : automatiser le cycle complet test-contre-ticket est techniquement impressionnant mais coûteux. Plus le contexte que l’agent doit charger est important (ticket + fichiers de test + output Playwright), plus ça brûle de tokens. Certaines automatisations qui semblent parfaites sur le papier ne survivent pas au contact d’une vraie facture mensuelle.

L’opération 100% autonome : Claude Code est un junior développeur senior. Il est rapide, minutieux, et suit bien les instructions. Mais il a toujours besoin d’un humain pour définir ce que “correct” signifie et valider le résultat. Le traiter comme un agent totalement autonome mène à de mauvais résultats.

Les préoccupations transversales : sécurité, performance, observabilité. Elles requièrent un jugement qui dépasse l’implémentation de ce que le ticket demande. Je les revois toujours séparément.

Le CLAUDE.md est le vrai débloquant

Si je devais nommer la partie la plus impactante de ce setup, c’est le CLAUDE.md pas le modèle, pas les outils.

Un bon CLAUDE.md capture la connaissance institutionnelle qui vit normalement uniquement dans la tête des personnes qui ont le plus travaillé sur le projet. L’écrire te force à articuler des choses qui sont habituellement implicites. Et une fois qu’il existe, n’importe quel développeur (humain ou IA) s’onboard plus vite.

Je le mets à jour chaque fois que je découvre quelque chose qui m’a surpris pendant une session. Avec le temps, il devient la documentation vivante que le projet n’a jamais eue.

Conclusion

La combinaison Claude Code, Jira MCP et un CLAUDE.md bien maintenu n’élimine pas les parties difficiles de la modernisation legacy. Elle compresse le temps passé sur les parties mécaniques lire du code, tracer des flux, écrire du boilerplate pour que plus de ton temps aille au jugement, à l’architecture, et à la vraie résolution de problèmes.

Ce décalage vaut plus que n’importe quelle fonctionnalité individuelle des outils.

Si tu travailles sur une codebase legacy et que tu n’as pas essayé ce workflow, commence par le CLAUDE.md. Même sans Claude Code, te forcer à écrire ce que le projet nécessite que les nouveaux venus sachent est les 30 minutes les mieux investies de ta semaine.

Model Context Protocol (MCP) : exposer un CLI Rust dans votre IDE

Wed, 11 Mar 2026 00:00:00 GMT

Réponse rapide : Le Model Context Protocol (MCP) permet à un agent IA, dans votre IDE, d’appeler directement vos propres outils, sans plugin spécifique. Vous gardez votre CLI Rust comme moteur, vous l’enveloppez dans un petit serveur MCP TypeScript qui déclare ses capacités, et n’importe quel host compatible MCP (Claude Code, Cursor, Windsurf) peut alors exécuter de vraies actions sur votre codebase au lieu de simplement les suggérer.

Le Model Context Protocol (MCP) permet d’exposer des outils internes à un agent IA directement dans l’IDE, sans plugin spécifique, sans intégration ad hoc. Plutôt que de donner des suggestions, l’agent peut exécuter de vraies actions sur votre codebase.

Le problème que MCP résout

Les agents IA intégrés aux IDE sont excellents pour comprendre le contexte : analyser du code, expliquer des erreurs, suggérer des refactors. Mais dès qu’il faut exécuter une action réelle (lancer un script interne, déclencher une logique métier, valider des sorties), une boucle inefficace apparaît : l’agent propose → on exécute ailleurs → on recolle la sortie dans le chat. À chaque fois.

MCP comble ce fossé en fournissant un standard pour exposer des capacités (CLIs, APIs, services internes) via un contrat structuré directement consommable par un IDE ou un assistant IA.

MCP vs REST : pas juste une API de plus

La différence n’est pas dans le format des messages, elle est dans le modèle d’intégration :

REST expose des endpoints. L’orchestration est écrite côté client, le client est connu à l’avance, rien ne standardise l’usage par un agent.
MCP expose des capacités déclarées (tools, resources, prompts). Le host les découvre dynamiquement, l’agent décide comment les enchaîner, les réponses sont structurées pour être interprétables et replanifiables.

REST expose des services. MCP expose des actions pilotables par des agents.

Architecture : moteur / façade / cockpit

Dans notre implémentation chez Ippon :

CLI Rust = le moteur : logique métier, performances, source de vérité. Rien ne change ici.
Serveur MCP TypeScript = la façade : le contrat, la validation des paramètres, l’exposition des capacités via le SDK MCP.
IDE/agent = le cockpit : l’orchestration et l’expérience utilisateur.

Une cible d’intégration unique remplace N plugins spécifiques à chaque IDE. Exposer un outil est étonnamment concis :

server.tool("analyze_module", {
  inputSchema: { type: "object", properties: { module: { type: "string" } }, required: ["module"] }
}, async ({ module }) => {
  const result = await runCli(["analyze", module]);
  return JSON.parse(result);
});

Pourquoi pas un plugin VSCode ?

L’approche “plugin intelligent” se heurte rapidement à des problèmes structurels : l’effet N-IDE (chaque host devient une cible), la duplication de logique métier qui diverge du CLI, le parsing fragile de stdout qui transforme des logs en API implicite, et le lock-in IDE. MCP inverse la posture : on part des capacités, pas de l’interface.

3 principes de design pour des outils agent-ready

Outputs orientés décision : ne pas dumper de l’état, renvoyer ce dont l’agent a besoin pour agir.
Erreurs actionnables : code + message + recoveryHint structurés pour que l’agent puisse se corriger sans intervention humaine.
Tools atomiques et composables : analyze_module() → generate_patch() → apply_patch() → run_tests(). Un outil, une intention. L’agent orchestre.

Rendre un CLI agent-ready (3 changements)

JSON-first sur stdout : sortie machine stable et prévisible ; les logs humains vont sur stderr.
Logs séparés : ne pas mélanger résultat et logs de diagnostic.
Erreurs catégorisées : code d’erreur + message + hint de recovery.

Questions fréquentes

Qu’est-ce que le Model Context Protocol (MCP) ?

MCP est un standard ouvert qui permet à un agent IA de découvrir et d’appeler des capacités externes (CLIs, APIs, services internes) via un contrat structuré. Le host découvre dynamiquement les outils déclarés, et l’agent décide comment les enchaîner : le même outil fonctionne ainsi dans n’importe quel IDE ou assistant compatible MCP.

En quoi MCP diffère-t-il d’une API REST ?

REST expose des endpoints et laisse l’orchestration à un client connu à l’avance. MCP expose des capacités déclarées (tools, resources, prompts) qu’un host découvre à l’exécution, et renvoie des réponses structurées qu’un agent peut interpréter et replanifier. REST expose des services ; MCP expose des actions pilotables par un agent.

Faut-il réécrire son CLI Rust pour le rendre agent-ready ?

Pas de réécriture, trois ajustements. Émettre du JSON lisible par machine sur stdout et envoyer les logs humains sur stderr, séparer résultat et diagnostic, et renvoyer des erreurs catégorisées (code, message, hint de recovery) pour que l’agent se corrige sans intervention humaine.

Cet article a d’abord été publié sur le blog Ippon Technologies.

Spec-Driven Development : de la spécification au code avec l'IA

Wed, 18 Feb 2026 00:00:00 GMT

Cet article a été co-écrit et publié sur le blog Ippon Technologies.

Le Spec-Driven Development (SDD) propose un changement simple mais radical : la spécification devient la source de vérité du projet. Avant d’écrire du code, on décrit précisément ce que le système doit garantir. Ces garanties guident directement l’architecture, l’implémentation et les tests.

L’idée centrale

Le SDD est une approche où la spécification formalisée (exigences, critères d’acceptation, invariants) devient l’artefact central du projet. Elle est versionnée avec le code et sert de référence pour le design, l’implémentation et les tests.

Ce qui définit réellement une approche Spec-Driven, ce n’est pas la présence d’un document « requirements ». Ce sont trois principes :

La spec agit comme un contrat : si une implémentation s’en écarte, c’est un défaut, pas une variante acceptable.
Chaque décision est traçable : un composant répond à une exigence, un test vérifie un critère d’acceptation, une validation protège un invariant.
La spec est vivante : elle évolue au même rythme que le code, versionnée dans le même repository et intégrée au même cycle de revue.

Le cycle SDD

Le cycle est itératif : Spécifier → Planifier → Développer & Tester → Itérer.

La discipline clé est de séparer le quoi du comment : on s’accorde sur les comportements attendus avant de débattre de la meilleure façon de les implémenter. Cela évite que l’architecture ne dicte accidentellement le produit.

SDD vs BDD vs PDD

BDD formalise le comportement via des tests (Given/When/Then). Le SDD organise tout le projet autour de la spec. Les deux peuvent coexister.
PDD (Prompt-Driven Development) optimise l’échange avec l’IA via des prompts : efficace pour prototyper, mais le prompt est éphémère. Le SDD utilise les prompts comme outil, la spec reste la référence.

Ce que l’IA change vraiment

Des outils comme Kiro permettent aujourd’hui d’organiser le travail autour de Requirements → Design → Tasks, rendant la spec un artefact actif plutôt qu’un document statique.

L’IA peut désormais :

transformer une intention produit en exigences structurées
dériver un design cohérent
générer des tâches d’implémentation
produire des tests alignés sur les critères d’acceptation
vérifier que le code respecte toujours la promesse initiale

La spécification cesse d’être un poids. Elle devient un accélérateur.

Retrouvez l’article complet sur le blog Ippon : Spec-Driven Development : de la spécification au code avec l’IA

Créer un portfolio ultra-rapide avec Astro et le déployer sur Netlify

Mon, 24 Jul 2023 00:00:00 GMT

Introduction

Dans cet article, nous allons voir comment créer un portfolio ultra-rapide avec Astro et son thème Portfolio, puis le déployer facilement sur Netlify. Avec cette combinaison puissante, vous pouvez mettre votre portfolio en ligne rapidement et impressionner clients et recruteurs.

Qu’est-ce qu’Astro ?

Astro est un générateur de sites statiques moderne qui combine les meilleures caractéristiques des générateurs traditionnels avec la puissance des frameworks contemporains. Son approche unique compile votre site en une application JavaScript entièrement optimisée, offrant des performances exceptionnelles et une expérience utilisateur fluide. De plus, Astro supporte les frameworks populaires comme React, Vue et Svelte, permettant aux développeurs de créer des applications web complexes en toute simplicité.

Le thème Portfolio

Ce thème inclut les fonctionnalités essentielles comme les sections projets. Il constitue une excellente base pour mettre en valeur votre travail et vos réalisations efficacement.

Démarrer avec Astro et le thème Portfolio

Suivez ces étapes pour créer votre portfolio rapide avec Astro et le thème Portfolio :

Étape 1 : Configurer votre environnement de développement

Assurez-vous d’avoir Node.js et npm installés sur votre système. Vous pouvez vérifier leur présence en exécutant les commandes suivantes dans votre terminal :

node -v
npm -v

Étape 2 : Créer un nouveau projet Astro avec le template portfolio

Ouvrez votre terminal et créez un nouveau projet Astro avec la commande suivante :

npm create astro@latest -- --template portfolio

Étape 3 : Personnaliser votre portfolio

Remplacez le contenu par défaut du répertoire src par vos propres projets, images et informations. Vous pouvez facilement modifier les composants et mises en page du thème Portfolio pour qu’ils correspondent à votre style et vos préférences.

Étape 4 : Tester votre portfolio en local

Pour visualiser votre portfolio en local, lancez le serveur de développement :

npm run dev

Votre portfolio sera accessible à l’adresse http://localhost:4321.

Déployer avec Netlify

Netlify simplifie considérablement le processus de déploiement, offrant une expérience fluide pour les sites statiques. Suivez ces étapes pour déployer votre portfolio Astro sur Netlify :

Étape 1 : Créer un compte Netlify

Si vous n’en avez pas encore, inscrivez-vous gratuitement sur Netlify à netlify.com.

Étape 2 : Installer la CLI Netlify

Installez la CLI Netlify globalement sur votre machine pour interagir avec Netlify depuis la ligne de commande :

npm install netlify-cli -g

Étape 3 : Builder votre portfolio

Avant de déployer, buildez votre projet Astro pour générer les fichiers optimisés :

npm run build

Étape 4 : Initialiser Netlify

Naviguez vers le répertoire de votre projet dans le terminal et lancez :

netlify init

Suivez les instructions pour lier votre compte Netlify et sélectionner le projet à déployer.

Étape 5 : Déployer votre portfolio

Enfin, déployez votre portfolio avec la commande suivante :

netlify deploy --prod

Votre portfolio sera automatiquement déployé sur Netlify, et vous recevrez une URL unique où votre portfolio ultra-rapide sera accessible par tous, partout dans le monde.

Conclusion

Créer un portfolio rapide et impressionnant n’a jamais été aussi simple grâce à Astro et son thème Portfolio. L’approche orientée performance d’Astro et son intégration fluide avec les frameworks modernes vous permettent de construire un portfolio de qualité sans effort. De plus, déployer votre portfolio sur Netlify garantit qu’il soit accessible au monde entier en quelques clics. Alors, pourquoi attendre ? Créez votre portfolio avec Astro et mettez en valeur vos compétences auprès de la communauté tech mondiale dès aujourd’hui !

Full-Remote Bliss : l'avantage du jet lag pour les devs fullstack

Wed, 21 Jun 2023 00:00:00 GMT

Mon expérience

À l’ère numérique, le concept de travail a profondément évolué, transcendant les espaces de bureau traditionnels. Le travail à distance a gagné en popularité, offrant aux professionnels la liberté de travailler depuis n’importe où. En tant que développeur fullstack pleinement ancré dans ce mode de vie, j’ai découvert un avantage inattendu : utiliser le jet lag comme levier de productivité et de croissance personnelle. Dans cet article, je partage mon expérience et comment transformer ce qui semble être un inconvénient en véritable atout.

La liberté du full-remote

L’un des aspects les plus séduisants du travail fullstack à distance, c’est la liberté qu’il procure. En s’affranchissant des contraintes d’un bureau physique, j’ai la flexibilité de travailler depuis n’importe quel endroit, à n’importe quelle heure. Cette autonomie me permet de concevoir mon environnement de travail selon mes préférences et d’atteindre un équilibre sain entre vie professionnelle et vie personnelle. Que ce soit depuis chez moi, un café animé ou une plage paisible, choisir où et comment je travaille a considérablement amélioré mon bien-être et ma satisfaction professionnelle.

Tirer parti du jet lag

Le jet lag, souvent perçu comme un désagrément inévitable lors de voyages longue distance, peut en réalité se transformer en avantage pour les travailleurs à distance. Lorsqu’on travaille sur plusieurs fuseaux horaires, il devient un outil puissant pour booster productivité et développement personnel.

Exploiter les fuseaux horaires pour maximiser l’efficacité

La beauté du travail à distance réside dans la possibilité de collaborer avec des collègues ou des clients aux quatre coins du monde. En planifiant stratégiquement mes horaires de travail en fonction des fuseaux de mon équipe, j’optimise la communication et la collaboration. Par exemple, basé en Europe et travaillant avec une équipe en Asie, je mets à profit le décalage horaire pour avancer sur mes tâches tôt le matin, pendant qu’ils dorment encore. Cela me permet de leur fournir mises à jour et rapports d’avancement avant même leur réveil, favorisant efficacité et fluidité de travail.

Concentration et focus décuplés

Le jet lag perturbe nos habitudes de sommeil, mais il crée aussi des opportunités uniques pour une concentration accrue. En exploitant les heures calmes du petit matin ou de la nuit, quand la plupart des gens dorment encore, je peux m’immerger dans un travail profond sans interruption. Ce temps préservé s’est avéré précieux pour attaquer des défis de code complexes, déboguer et résoudre des problèmes créatifs.

Croissance personnelle et ouverture culturelle

Travailler à distance sur différents fuseaux horaires nous expose à des cultures et des perspectives variées. En tant que développeur fullstack, c’est une expérience enrichissante qui élargit ma compréhension des marchés mondiaux, des comportements utilisateurs et des avancées technologiques. Collaborer avec des collègues de fuseaux différents favorise la coopération interculturelle, développe les réseaux professionnels et ouvre des portes à des opportunités d’apprentissage uniques, difficilement accessibles dans un cadre de bureau traditionnel.

Maintenir l’équilibre et gérer les défis

Si les avantages du full-remote et de l’optimisation du jet lag sont substantiels, il est essentiel de préserver un équilibre sain et d’anticiper les défis potentiels.

Établir une routine

Pour optimiser la productivité et atténuer les effets négatifs du jet lag, une routine cohérente est indispensable. Construire un emploi du temps qui tient compte à la fois des engagements personnels et professionnels apporte une structure bénéfique pour l’efficacité au travail et le bien-être global.

Prioriser le soin de soi

Le travail à distance peut brouiller les frontières entre vie professionnelle et vie personnelle, rendant l’auto-soin encore plus crucial. Faire des pauses, pratiquer une activité physique et maintenir des liens sociaux sont essentiels pour la santé mentale et physique. Face au jet lag, veiller à un repos suffisant et à une bonne hygiène du sommeil devient encore plus important pour éviter le burn-out.

Communication et collaboration efficaces

Le travail à distance repose largement sur une communication et une collaboration efficaces. Adopter des outils numériques (plateformes de gestion de projet, messagerie instantanée, visioconférence) est indispensable pour maintenir des interactions fluides avec des collègues répartis sur différents fuseaux. Des canaux de communication clairs et transparents permettent d’établir les attentes, d’assurer l’alignement et de créer une cohésion d’équipe.

Conclusion

En tant que développeur fullstack pleinement ancré dans le mode de vie full-remote, les bénéfices ont été transformateurs. La flexibilité de travailler depuis n’importe où, combinée à l’exploitation stratégique du jet lag, m’a permis d’atteindre des niveaux de productivité plus élevés, de m’ouvrir à des cultures diverses et de trouver un meilleur équilibre vie pro/perso. En maintenant une routine, en priorisant le soin de soi et en favorisant une communication efficace, le parcours full-remote peut devenir une expérience remarquable, propice à la croissance personnelle et au succès professionnel. Dans un monde qui embrasse de plus en plus le travail à distance, tirer parti de ces avantages peut s’avérer décisif pour les développeurs et professionnels de tous horizons.