L'IA produit. Je décide, je vérifie, je livre.
Mes applications sont écrites par des assistants IA, mais aucun d'eux n'a les clés. Chacun travaille dans un espace isolé, et rien n'arrive chez vous sans que je l'aie relu et que vous l'ayez validé. Cette méthode a un nom : Medivh. Je la maîtrise de bout en bout, car c'est moi qui l'ai conçue et construite.
Medivh est l'environnement dans lequel des agents Claude Code ou des LLM locaux développent, chacun dans un conteneur jetable, avec des droits GitHub d'une heure limités à votre produit, sans écriture sur main et sans possibilité de merge. Je tire parti de la vitesse de l'IA, sans courir le risque de lui donner les clés du code, de l'infrastructure ni, pire, d'un produit d'un autre client. Je maîtrise parfaitement la chaîne de production du code, car c'est moi qui l'ai conçue et construite.
Plusieurs fonctionnalités en même temps, chacune dans son couloir.
Plusieurs fonctionnalités en même temps, chacune dans son worktree.
Un worktree et un conteneur par fonctionnalité, une PR par ticket.
Nous précisons ensemble ce que la fonctionnalité doit faire, et je l'écris noir sur blanc : quoi, pourquoi, et comment on saura que c'est réussi. C'est souvent la partie la plus utile.
Votre projet avance en toute transparence.
Chaque fonctionnalité de votre projet est découpée en quelques cartes sur un tableau auquel vous accédez quand vous voulez. Elles avancent de colonne en colonne automatiquement au cours de la réalisation, et vous savez toujours où en est votre projet sans avoir à me demander.
J'ai un board GitHub Projects par produit (client), mis à jour par les agents (création des tickets, passage en In Progress) puis par l'automate n8n pour le traitement des PRs. Vous y avez un accès en lecture et commentaire ; chaque carte renvoie à son issue, sa PR et ses commits.
Les repos du produit vivent dans mon organisation GitHub dédiée, avec les ADR et le code d'infrastructure.
L'IA n'a jamais les clés.
- Chaque assistant IA travaille dans un espace isolé et jetable, sans accès à votre production, à vos secrets ni aux projets d'autres clients.
- Rien ne passe en production sans ma relecture et votre validation. Ce n'est pas une habitude, c'est une règle que l'outil impose.
- Chaque modification est tracée : qui l'a demandée, qui l'a écrite, qui l'a approuvée, quand elle a été mise en ligne.
- On peut toujours revenir en arrière, et le code, l'infrastructure et la documentation vous appartiennent.
- Quand l'IA se trompe, et ça arrive, je le vois à la relecture, je fais corriger, ou je refuse. C'est mon travail, et c'est pour ça que vous me payez.
J'utilise principalement Claude. Il est aussi possible d'utiliser des LLM locaux si vous ne souhaitez pas qu'Anthropic dispose des conversations.
Avant de travailler dans le cloud, j'ai passé dix ans chez Safran à valider des résultats produits par des machines de calcul. Piloter une IA qui code, c'est le même métier : savoir ce qu'on lui demande, et vérifier ce qu'elle rend.
- Isolation : un conteneur par ticket, une image par produit, une session d'agent par produit, des tokens GitHub d'une heure renouvelés toutes les 30 minutes et limités aux repos du produit. Aucun secret durable dans le conteneur ; sortie réseau en white list (GitHub, registres de paquets, Anthropic).
- Garde-fous imposés par GitHub : pas d'écriture sur main, PR et approbation obligatoires, l'agent ne peut pas approuver sa propre PR ; fichiers de gouvernance de l'environnement refusés en écriture sur toutes les branches.
- Garde-fous par consigne : lint et tests avant la PR, périmètre du ticket, s'arrêter et demander plutôt qu'inventer. Ils sont suivis, mais c'est ma relecture qui les vérifie : je ne vous vendrai pas un test vert comme une preuve.
- Traçabilité : issue → branche → PR → commits attribués au bot de l'agent ; ADR pour l'architecture ; mes interventions consignées dans GitHub. Retour arrière par revert et redéploiement.
- Infrastructure as code : Terraform (VM, key vault, private network, Service Bus, Azure Functions). Plan dans l'espace de l'agent. Apply en CI après merge.
Dépendances assumées : GitHub, Azure, Anthropic, sinon LLM locaux. L'agent ne navigue pas sur le web : un projet qui appelle des API tierces pendant le développement demande d'étendre la white list.
Avant de travailler dans le cloud, j'ai passé dix ans chez Safran Aircraft Engines, expert méthodes, à qualifier des codes de simulation et leurs résultats avant qu'un bureau d'études s'y fie. Relire ce qu'une IA produit relève exactement de cette discipline : critères d'acceptation écrits avant, vérification après, et refus quand ce n'est pas satisfaisant.
Le sur-mesure au prix du standard, expliqué.
Aujourd'hui, une IA bien cadrée code très bien la plupart des fonctionnalités. Ce qu'elle ne sait pas faire, c'est décider ce qu'il faut construire et vérifier que c'est juste d'un point de vue métier.
Dans une équipe classique, un développeur passe environ 20 % de son temps à relire le code de ses collègues. Ici, je relis 100 % de ce qui est produit : mathématiquement, c'est comme si je relisais le travail de cinq développeurs, remplacés par mes assistants IA. Le temps de développement devient marginal ; le temps de cadrage, de relecture et de décision reste. C'est pour ça que c'est moins cher.
Pas cinq fois moins cher, pour autant : la relecture, la recette et la mise en production ont un coût incompressible, et c'est précisément là que se joue la qualité.
Constat : une IA correctement cadrée (contexte produit, critères d'acceptation, périmètre d'un ticket) code aujourd'hui la grande majorité des fonctionnalités métier au niveau d'un développeur expérimenté. Mais elle n'apporte pas : l'arbitrage, la revue et la décision de mise en production.
Ordre de grandeur habituel : un développeur consacre environ 20 % de son temps à la revue de code de ses pairs. Ici, je relis 100 % du code produit, soit l'équivalent de la revue de cinq développeurs, et la production, elle, est parallélisée : un worktree et un conteneur par ticket, plusieurs agents en conversation simultanée, chacun sur sa branche, les dépendances explicites dans les tickets. Tout ce qui est répétitif est automatisé : conteneurs, tokens, règles GitHub, découpage, suivi du kanban, déploiement par la CI. La courbe de coût change de forme : le développement devient marginal, le cadrage, la revue, la recette et l'exploitation deviennent l'essentiel.
D'où un sur-mesure au prix du standard, mais pas une division par cinq : ce qui reste est incompressible, et c'est là que se joue la qualité.
Un projet documenté, reproductible, qui vieillit bien.
Une documentation qui existe vraiment. Chaque fonctionnalité commence par une fiche écrite : ce que fait la fonctionnalité, pourquoi, et comment on saura que c'est réussi. Le code est ensuite produit à partir d'elle. La documentation n'est pas rédigée après coup, quand il reste du temps : elle est le point de départ, et elle évolue avec l'application.
Des décisions tracées. Quand un choix structurant est pris, par exemple comment stocker vos données ou gérer les droits d'accès, il est consigné dans une fiche de décision : ce qu'on a choisi, pourquoi, et ce qu'on a écarté. Dans deux ans, vous ou votre prochain prestataire saurez pourquoi l'application est faite ainsi.
Une infrastructure reproductible. Vos serveurs, votre réseau, vos sauvegardes sont décrits dans des fichiers, pas réglés à la main. On peut les recréer à l'identique en quelques minutes, sur un autre compte ou chez un autre hébergeur.
Documentation d'abord. Le contexte produit est lu par tous les agents. Les spécifications sont lues par fonctionnalité, avec le quoi, le pourquoi, le découpage, les critères d'acceptation et les dépendances. Un repo contient la documentation, versionnée et relue au même titre que le code. Le code est généré à partir de la doc et la doc est mise à jour par le même flux de tickets : les deux ne divergent jamais.
ADR, Architecture Decision Records. Une fiche par décision d'architecture, livrée en PR et relue comme du code : contexte, options, décision, conséquences. Une ADR acceptée ne se modifie pas ; une nouvelle décision en remplace une ancienne et l'historique reste lisible.
Infrastructure as code. Terraform pour l'infrastructure des produits comme pour Medivh lui-même : plan en PR, apply en CI après fusion. Reproductible, auditable, réversible.