Je n'utilise pas Claude Code pour écrire davantage de code. Je l'utilise pour augmenter ma capacité d'architecte : analyser, implémenter, tester, relire, documenter, déployer et surveiller, avec des garde-fous qui empêchent l'automatisation de devenir une boîte noire.
Je suis indépendant, entre la Belgique et le Maroc, avec plus de 30 ans de terrain en architecture de données et en IT au service de PME (SQL Server, C# et .NET, ETL). Mon point de départ, tiré de mon expérience : un problème de PME est rarement seulement technique ou seulement humain, il est les deux, vus sous deux angles. L'IA ne change pas cela. Elle change ce qu'un architecte peut faire pour chacun de ses clients.
Concrètement, je mène aujourd'hui un projet de données pour une PME, avec un produit logiciel, un framework partagé, plusieurs sites web et un dépôt de gouvernance interne, tout en restant seul responsable des décisions.
Pourquoi ce système ? L'informatique m'accompagne depuis mes 10 ans. Deux épuisements m'ont appris ce que coûte le fait de vouloir tout porter seul, et m'ont conduit au coaching, certifié en 2019. Aujourd'hui, le système porte la mémoire, les règles et les contrôles. La responsabilité reste la mienne. Le temps qu'il me rend va à mes clients : comprendre leur métier et livrer ce qui marche. Pour eux, ça veut dire des corrections vérifiées avant la production, et une trace écrite de chaque choix.
Qui décide, qui exécute ?
Tout repose sur une frontière claire : je tranche les décisions métier, l'agent exécute, contrôle et documente.
À moi
- La décision métier et l'arbitrage
- La responsabilité et l'architecture
- La validation finale, surtout avant toute écriture en production
À l'agent
- L'exploration du code et des données
- L'implémentation et les tests
- La relecture, la documentation et les déploiements courants
- La surveillance répétitive, chaque nuit
L'agent peut proposer, implémenter, relire et documenter. La responsabilité reste humaine et ne se délègue pas. Ces règles valent pour qui exécute, agent ou développeur.
Comment une demande va-t-elle de l'issue à la production ?
Chaque demande, qu'elle arrive par mail, par appel ou par message, devient d'abord une issue GitHub. Rien ne s'écrit sans issue. Chaque issue reçoit un score, selon la méthode décrite dans l'encadré : plus l'argent en jeu et le nombre d'enregistrements touchés sont grands, plus elle passe devant.
Un cas d'école : une anomalie qui touche 250 enregistrements en production, avec un enjeu financier, et une journée de travail. Valeur 5 × impact 5 × risque 3 × production 2, divisé par un effort de 3 : score 50.
Comment l'agent garde-t-il la mémoire du portefeuille ?
- Projet de données
- La production : intégration de données fournisseurs vers un système de gestion, avec contrôles de cohérence.
- Produit
- Le produit : un moteur de recherche par références croisées, neutre vis-à-vis du métier, avec API et tableau de bord.
- Framework
- Le socle : mon ensemble de bibliothèques .NET, réutilisables d'un projet à l'autre.
- Branding
- Les vitrines web de mes activités.
- Pilotage
- Le journal de bord : décisions, ADR, journal commun à tous les dépôts, relevés d'audit.
Le dépôt de pilotage joue le rôle de mémoire : ses décisions et son journal sont chargés dans chaque session. L'agent ne repart jamais de zéro.
Quels garde-fous encadrent l'agent ?
La vitesse d'un agent ne vaut que si elle est encadrée. Mes règles permanentes sont lues à la fois par l'agent qui code et par celui qui relit. Elles s'améliorent à chaque itération : une erreur repérée devient une consigne.
- Un cahier des charges, puis une conception de dix lignes avant le code pour tout choix structurant. Les choix métier remontent à moi, jamais tranchés en douce.
- Une auto-relecture avec preuve par mutation : chaque correction a un test qui échoue sans elle.
- Toute la suite de tests après chaque correction, et une question écrite : qu'est-ce que cette correction peut casser ailleurs ?
- Une relecture indépendante avant toute fusion.
- Aucune erreur silencieuse, rien de deviné : une valeur absente est signalée, jamais remplacée par un zéro ou un ancien tarif.
- Test avant production : mon processus vise à n'écrire en production qu'après validation sur Test, et chaque geste de correction est journalisé.
Ces règles ne rendent pas l'agent infaillible. Elles rendent ses erreurs visibles tôt.
À quoi ressemble une vraie erreur d'agent ?
Il y a quelques semaines, des agents ont trié 226 demandes ouvertes et m'ont proposé d'en fermer 21. Je n'en ai fermé aucune sur parole. J'ai confié à trois autres agents la mission inverse : démontrer que chaque fermeture était fausse.
Un des cas : un tableau de bord affichait, sans prévenir, l'environnement par défaut au lieu de celui demandé. Le tri le disait corrigé. Le contrôleur a retrouvé le défaut dans le code.
Au total, 9 des 21 fermetures proposées ont été réfutées. Les 12 autres ont tenu, et je les ai fermées. Une proposition d'agent n'est pas une décision.
Que font les automates chaque nuit ?
Un automate commence en lecture seule : il observe, rapporte et propose avant d'obtenir le droit d'agir.
La routine du matin
Une session planifiée prépare mes matinées. Elle lit les journaux d'exécution de mes environnements de test et de production, rédige le rapport de nuit, relève les pull requests et les CI des cinq dépôts et propose la prochaine demande à traiter. Son unique écriture est une pull request contenant le rapport. Elle a d'abord tourné un jour « à blanc » : même travail, rien de poussé, et un bilan de ce qui avait manqué.
Un créateur de connecteurs en lecture seule
Un sous-agent construit un connecteur en lecture seule vers l'API d'une application métier. Sa contrainte est dure : uniquement des appels de lecture.
Coordination et traductions
Un workflow synchronise plusieurs sessions parallèles et repère les collisions. Un autre valide les traductions de ma vitrine par rétro-traduction en aveugle et vérification adversariale. Deux hooks régénèrent la version anglaise d'un prompt dès que je modifie le français et copient la documentation vers un dossier que mes conversations Claude peuvent lire.
Qu'est-ce que ça donne, en chiffres ?
| Commits | 2 048 |
|---|---|
| Jours actifs | 121 |
| Demandes triées en un seul passage | 226 |
| Décisions d'architecture documentées | 60+ |
| Bibliothèques .NET réutilisables | ~40 |
| Sources de données intégrées | 20+ |
| Part de code de test | 40 % |
Période mesurée : du 1er avril au 9 octobre 2026.
Je garde le nombre de lignes de code hors de ce tableau : c'est une mesure de volume, pas de valeur, et une partie vient de code généré.
Quelles sont les limites ?
- Environ un commit sur cinq est une correction. Changement d'avis venu du terrain ou vraie erreur, de moi comme de l'agent, le chiffre ne tranche pas. C'est la raison d'être des tests et des relectures.
- Le système a un coût d'entretien : 40 bibliothèques, des automates et un dépôt de pilotage demandent du temps.
- Il suppose de l'expérience. La méthode repose sur des décisions d'architecture que l'agent ne prend pas à ma place.
- Mes skills et mes hooks sont propres à Claude Code. Les règles, les grilles et les décisions, elles, se transportent.
L'IA n'a pas réduit la responsabilité. Elle a augmenté la capacité de pilotage.
Si vous voulez mettre des agents IA au travail sans perdre la maîtrise, parlons-en : un premier échange suffit pour voir ce qui se transpose chez vous.
Qu'est-ce qui se transposerait chez vous ? Discutons-en.
Parlons de votre projet