Le résultat d’abord
L’organisation Unmanaged-Bytes regroupe plusieurs projets C11 pour Linux : des bibliothèques et des outils en ligne de commande, chacun dans son propre dépôt. Au total, plus de 22 000 lignes de production. 97 000 lignes de tests. 100% de couverture lignes et branches. Zéro fuite Valgrind. Zéro erreur ASAN, UBSAN, TSAN. Ratio test/code : 4.3 pour 1.
Deux outils publiés : bc-count (jusqu’à 18x plus rapide que GNU wc) et bc-duplicate (3,7x plus rapide que jdupes, 28,8x plus rapide que fdupes). Mêmes standards de qualité, même pipeline.
Je n’ai pas écrit une seule ligne de ce code.
Tout a été implémenté par Claude Code, l’outil en ligne de commande d’Anthropic. Mon rôle : architecte et superviseur. J’ai conçu les API, défini les règles de codage, structuré le pipeline de qualité, et pris chaque décision de design. L’IA a exécuté.
Ce n’est pas un article sur “comment utiliser Claude Code”. C’est un article sur ce que signifie architecturer un système où une IA produit du code de qualité production — et pourquoi cette compétence est probablement plus importante que savoir écrire du C.
Pour le détail du cycle TDD (RED → GREEN, rapports inter-agents, walkthrough concret), voir Mon code C a 100% de couverture. Je n’ai pas écrit un seul test.
Le problème avec “l’IA écrit du code”
Quand on dit “l’IA a écrit le code”, la plupart des gens imaginent un prompt du type "écris-moi une bibliothèque C" suivi de 20 000 lignes de code générées en un bloc. Ce n’est pas du tout ce qui s’est passé.
Claude Code, comme tout LLM, est un outil probabiliste. Sans cadre, il produit du code qui “a l’air correct” — qui compile, qui passe un test de base, et qui cache ses bugs derrière des cas limites non testés. Le genre de code qui fonctionne en démo et qui casse en production à 3h du matin.
Le problème n’est pas l’IA. Le problème, c’est l’absence d’architecture autour de l’IA.
L’architecture : 6 agents, un pipeline, des contrats
Pour ces projets, j’ai construit un pipeline multi-agents structuré dans Claude Code. Pas un seul prompt monolithique — un système de spécialistes qui collaborent via des rapports écrits, chacun avec un rôle précis et des limites claires.
Les agents
| Agent | Rôle | Contrainte |
|---|---|---|
| c-researcher | Explore le code source et le web, identifie les structures et les risques | Lecture seule |
| c-architect | Propose des alternatives, choisit, écrit la spec technique | Pas de bash — pure conception |
| c-tester | Écrit les tests cmocka depuis la spec, crée le stub RED | Ne touche jamais au code source |
| c-developer | Implémente le minimum pour passer les tests (GREEN) | Ne touche jamais aux tests |
| c-reviewer | Vérifie les conventions de codage | Lecture seule, ne corrige rien |
| c-security-auditor | Audit sémantique + pipeline complet validate.sh | Lecture seule, ne corrige rien |
Chaque agent produit un rapport Markdown lu par l’agent suivant. Le researcher ne code pas. Le tester ne modifie pas le source. Le developer ne décide pas du scope. C’est de la séparation des responsabilités appliquée à des agents IA.
Le pipeline
Demande
→ c-researcher (exploration codebase + web)
→ c-architect (spec technique + alternatives)
→ c-tester (tests RED — compilent, échouent)
→ c-developer (implémentation GREEN — tests passent)
→ c-reviewer + c-security-auditor (en parallèle)
→ SUMMARY (résumé, merge)
Quand le developer échoue à atteindre 100% de couverture, il reçoit le rapport d’erreur et réessaie. Quand le security-auditor trouve une faille, le developer corrige et l’audit reprend. Le pipeline boucle jusqu’à ce que tous les critères soient remplis — ou signale un blocage.
Les règles : 991 lignes de contrats
L’IA ne “sait” pas ce que signifie “du bon code C” dans mon contexte. Il faut le lui dire. En détail.
J’ai rédigé 991 lignes de règles réparties en 5 fichiers :
Conventions de codage — nommage (bc_<module>_<action>()), ordre des includes, en-têtes SPDX, pas de short options, pas de --threads (détection automatique).
Conventions de tests — setjmp.h avant cmocka.h (obligatoire sous glibc), --wrap pour les seam tests, couverture des conditions composées (A && B : tester A=false, A&&B=false, A&&B=true séparément).
Build — 7 configurations de build séparées (debug, release, coverage, valgrind, asan, tsan, cppcheck), chacune dans son propre répertoire, jamais mélangées.
Leçons — 32 principes numérotés (P2 à P39), chacun issu d’un vrai échec. P7 : “glibc remappe open vers open64 au link time — utiliser --wrap=open64 dans les tests”. P12 : “Pour SIMD, créer 4 binaires de test séparés (scalar, SSE2, AVX2, AVX-512)”. P14 : “Couvrir les conditions composées — un test pour A=false, un pour A&&B=false, un pour A&&B=true”.
Ces 32 principes n’existent dans aucun tutoriel. Ce sont des heures de debug condensées en phrases. Sans eux, l’IA répéterait les mêmes erreurs à chaque module.
La validation : 8 étapes, 3 groupes de sévérité
Le pipeline de validation comporte 8 étapes organisées en 3 groupes. Si un groupe échoue, les suivants ne s’exécutent pas.
Groupe A — Statique
clang-format— vérification du formatagecppcheck— analyse statique- Audit des conventions (21 vérifications automatisées)
Groupe B — Fonctionnel 4. Build debug + tests unitaires 5. Valgrind memcheck — fuites mémoire, accès invalides
Groupe C — Sécurité et couverture
6. ASAN + UBSAN — sécurité mémoire + comportement indéfini
7. TSAN — détection de data races (comprend les atomics C11)
8. gcovr — 100% lignes ET branches, sans exception
C’est un pipeline que beaucoup d’équipes professionnelles n’ont pas. Et il tourne sur chaque module, à chaque itération.
Les scripts : 13 médiateurs par projet
Un détail crucial : l’IA n’exécute jamais directement meson, ninja, valgrind ou gcovr. Chaque outil est enveloppé dans un script bash dédié qui gère le répertoire de build, les flags, le nettoyage, et les codes de retour.
Pourquoi ? Parce qu’un LLM qui exécute valgrind directement va oublier de recréer le répertoire de build, va mélanger les configurations, va ignorer un code de retour non-zéro. En passant par des scripts, le comportement est déterministe et reproductible, indépendamment de l’agent qui les appelle.
C’est le même principe que dans n’importe quel système distribué : ne pas faire confiance aux acteurs individuels, mais au protocole.
Ce que j’ai appris
L’architecture coûte plus cher que le code
Construire ce pipeline — les agents, les règles, les scripts, les leçons — a pris plus de temps que si j’avais écrit le code à la main. Significativement plus.
Mais le pipeline est réutilisable. Le deuxième outil (bc-count, un compteur de lignes avec SIMD et parallélisme) a été produit beaucoup plus vite, avec la même qualité. Le troisième (bc-duplicate, détection de fichiers en double) encore plus vite.
C’est le calcul fondamental de l’architecture : investir dans le système, pas dans l’exécution.
Les règles sont le produit
Les 991 lignes de règles sont plus précieuses que les 22 000 lignes de code. Le code peut être régénéré. Les règles encodent des décisions qui ont pris des années d’expérience à formuler.
Un junior avec Claude Code et mes 991 lignes de règles produirait du code de meilleure qualité qu’un senior sans elles. Ce n’est pas l’IA qui fait la différence — c’est la spécification.
La supervision est un métier
Superviser une IA qui code, ce n’est pas “appuyer sur entrée et attendre”. C’est lire chaque rapport. Vérifier que le c-architect n’a pas sur-spécifié une tâche triviale. S’assurer que le c-developer n’a pas ajouté des #pragma pour forcer la couverture. Rattraper le moment où le c-security-auditor signale un faux positif qui mènerait à une régression.
C’est du travail d’architecte. Et ça demande de comprendre le code en profondeur — on ne peut pas superviser ce qu’on ne comprend pas.
Les chiffres
| Métrique | Valeur |
|---|---|
| Lignes de production (total) | ~22 000 |
| Lignes de tests (total) | ~97 000 |
| Ratio test/code | 4.3:1 |
| Couverture lignes | 100% |
| Couverture branches | 100% |
| Fuites Valgrind | 0 |
| Erreurs ASAN/UBSAN | 0 |
| Data races (TSAN) | 0 |
| Dépendances externes | 0 |
| Lignes de règles (codifiées) | 991 |
| Principes issus d’échecs (P2-P39) | 32 |
| Agents dans le pipeline | 6 |
| Scripts de validation | 13 par projet |
Et maintenant ?
bc-count et bc-duplicate sont sur GitHub sous licence MIT. Le code est lisible, testé, et reproductible.
Pour comprendre comment un cycle TDD concret se déroule dans ce pipeline — du stub RED au GREEN, en passant par les rapports inter-agents — voir Mon code C a 100% de couverture. Je n’ai pas écrit un seul test.
Ce que je retiens de cette expérience : en 2026, la valeur d’un ingénieur ne se mesure plus en lignes de code écrites par jour. Elle se mesure en qualité du système qu’il est capable de concevoir, de contraindre, et de superviser — que l’exécutant soit humain ou artificiel.
Les fondamentaux ne changent pas. La manière de les appliquer, si.
Lis. Comprends. Maîtrise. Recommence.