Agents IA autonomes en équipe .NET :
mesures réelles après 6 mois,
sans la hype

En octobre 2025, j'ai introduit des agents IA autonomes dans l'équipe .NET sur laquelle j'interviens en mission — une plateforme enterprise avec Clean Architecture, DDD, CQRS, MassTransit, Reqnroll. Pas un POC en sandbox, pas une démo LinkedIn : une intégration réelle dans un pipeline de livraison avec des contraintes de production, des SLA et des code reviews formels. Six mois plus tard, voici les chiffres bruts, les décisions que je referais et celles que je ne referais pas.

Les chiffres avant/après — la table qui compte vraiment

Avant de parler d'architecture ou de tooling, voici ce qui a changé sur les métriques qui comptent pour un DSI ou un CTO :

Ces chiffres sont issus de Jira (cycle time par ticket), Azure DevOps (review thread lifetime) et nos dashboards Grafana. Ils ne sont pas parfaits — il y a un biais de sélection des sprints comparés — mais l'ordre de grandeur est représentatif.

"Un agent ne remplace pas un développeur. Il supprime la friction sur les tâches à faible valeur cognitive, ce qui libère cette énergie pour les décisions à haute valeur. L'erreur est de croire que la friction disparaît — elle se déplace."

Matrice de capacités : ce que les agents font bien, ce qu'ils cassent

Après 6 mois d'utilisation intensive, j'ai une vision précise de là où déléguer à un agent crée de la valeur et là où ça crée du risque. Voici la matrice telle qu'elle s'est stabilisée sur notre stack :

L'histoire d'échec que je n'aurais pas cru avant de la vivre

Début décembre 2025. L'agent implémente une feature de réaffectation de commandes entre centres de coût. Le code compile. Les 14 tests passent. La PR est approuvée. La feature est déployée. Trois semaines plus tard, un client signale des anomalies comptables.

Le root cause : notre agrégat Order avait un invariant implicite — une commande validée (status Approved) ne peut être réaffectée qu'avec un montant identique, jamais avec recalcul de TVA. Cet invariant n'était documenté nulle part. Il était dans la tête des deux développeurs historiques de la feature. L'agent avait implémenté la réaffectation en recalculant la TVA sur la nouvelle base — comportement raisonnable, syntaxiquement correct, fonctionnellement cohérent avec les specs rédigées, mais violant un invariant domaine non écrit.

Ce qui m'a le plus frappé : nos tests passaient parce qu'ils testaient le comportement décrit dans la spec, pas l'invariant. Le test couvrant la réaffectation vérifiait que le nouveau centre de coût était bien affecté. Il ne vérifiait pas que le montant HT restait identique.

Ce que j'ai changé suite à cet incident :

• Les invariants de domaine sont maintenant documentés dans un INVARIANTS.md par agrégat, référencé dans le CLAUDE.md
• Un skill dédié domain-invariant-guard génère automatiquement des tests d'invariants à chaque nouvelle feature touchant un agrégat existant
• Règle dans le CLAUDE.md : toute modification d'un agrégat existant nécessite une relecture humaine des invariants documentés avant le premier commit

## Règles domaine — NON-NÉGOCIABLE
# Ajouté après l'incident de décembre 2025

- Avant toute modification d'un agrégat existant :
  1. Lire src/Domain/[Aggregate]/INVARIANTS.md
  2. Vérifier que chaque invariant est couvert par un test explicite
  3. Jamais de recalcul fiscal sans validation humaine explicite

- Les agrégats suivants ont des invariants critiques :
  Order, Invoice, CostCenter, EmployeeBenefit

- Un test d'invariant a la forme :
  [Fact]
  public void [Invariant]_WhenViolated_ThrowsDomainException()
  // Pas de test comportemental — test de règle métier pure

Le coût réel de configuration : ce qu'on ne vous dit pas

La plupart des articles sur les agents IA passent sous silence la phase de setup. C'est là que j'ai perdu le plus de temps. Voici la décomposition honnête des 3 premières semaines :

Trente heures de configuration avant de voir un ROI stable. Si vous estimez à 2h le retour par semaine en phase initiale, le seuil de rentabilité de la configuration seule est à 15 semaines. C'est pour ça que les équipes qui "testent les agents en deux jours" et concluent que ça ne vaut pas le coup ont raison — pour deux jours de test.

Voici un extrait représentatif de ma configuration de hooks :

// .claude/settings.json — hooks de workflow (extrait)
{
  "hooks": {
    "PreToolUse": [
      {
        "matcher": "Bash",
        "hooks": [
          {
            "type": "command",
            "command": "rtk git status --short",
            "description": "Vérifie qu'aucun fichier non stagé traîne avant exécution"
          }
        ]
      }
    ],
    "PostToolUse": [
      {
        "matcher": "Edit|Write",
        "hooks": [
          {
            "type": "command",
            "command": "rtk dotnet build --no-restore -v quiet",
            "description": "Build silencieux après chaque modification de fichier source"
          }
        ]
      }
    ],
    "Stop": [
      {
        "hooks": [
          {
            "type": "command",
            "command": "rtk dotnet test --no-build --logger 'console;verbosity=minimal'",
            "description": "Tests obligatoires avant que l'agent rende la main"
          }
        ]
      }
    ]
  }
}

Le hook Stop est le plus important. Il force l'exécution des tests avant que l'agent considère sa tâche terminée. Sans ça, vous avez du code "fonctionnel selon l'agent" qui n'a jamais été compilé dans son contexte final.

Le calcul ROI pour un CTO

Les chiffres qui intéressent un DSI ou un CTO ne sont pas les miens — ils sont ceux de leur équipe. Voici le modèle de calcul que j'utilise quand j'évalue l'investissement pour un client :

Hypothèses de base :

• Coût d'un développeur senior .NET : 800 €/j (TJM marché 2026, Île-de-France)
• Soit ~17 600 €/mois sur 22 jours ouvrés
• Gain de temps estimé (phase stable, après 2 mois) : 1,5h/jour par développeur sur les tâches couvertes par les agents
• Sur 8h de travail effectif : 19 % de gain de capacité
• Équipe de 4 développeurs seniors

Calcul :

• Gain mensuel par développeur : 0,19 × 17 600 € = 3 344 €/mois
• Gain équipe (4 devs) : 13 376 €/mois
• Coût de setup initial (30h × 800 €/j ÷ 8h) : 3 000 €
• Coût licences Claude Code (4 devs × 100 $/mois) : ~370 €/mois
• Coût récurrent total : 370 €/mois
• Seuil de rentabilité du setup : 3 000 / (13 376 − 370) = 0,23 mois

En théorie, le setup est rentabilisé en moins d'une semaine de phase stable. En pratique, ajoutez 6 à 8 semaines pour atteindre la phase stable. Le vrai breakeven se situe entre le mois 2 et le mois 3 — pas le mois 6 que j'entends souvent citer.

"La question n'est pas 'est-ce que les agents IA valent leur coût ?' — ils le valent. La question est 'avons-nous les prérequis pour en tirer parti ?' La réponse est souvent non, et c'est là que l'investissement réel se trouve."

Les prérequis non-négociables avant d'investir

Un agent est un multiplicateur. Si votre base de code est propre, vos conventions documentées et vos tests en place, un agent vous rend deux fois plus efficace. Si votre base de code est du spaghetti sans tests, un agent vous rendra deux fois plus efficacement en train de produire du spaghetti sans tests.

Les prérequis que j'impose avant d'introduire des agents dans une équipe :

• TDD en place — pas "on fait des tests", mais cycle Red/Green/Refactor respecté systématiquement
• Architecture explicite — les couches sont définies, les dépendances documentées, les boundaries clairs
• Conventions codifiées — pas dans la tête de l'équipe, dans un fichier que l'agent peut lire
• Pipeline CI vert — si le build est rouge avant l'agent, il sera rouge après
• Définition des invariants de domaine — au moins les agrégats critiques documentés

Ce que je referais différemment

L'exercice de rétrospective honnête, six mois après :

J'aurais commencé par les skills de test, pas les skills de scaffolding. Le gain le plus immédiat et le moins risqué est la génération de tests unitaires sur des handlers existants. C'est là que le ratio valeur/risque est le plus favorable. J'ai perdu deux semaines sur le scaffolding alors que les tests auraient eu un impact plus visible sur la qualité.

J'aurais documenté les invariants de domaine avant le premier commit agent. L'incident de décembre était prévisible. Un agrégat avec 4 ans d'historique et deux développeurs qui sont partis — évidemment que les invariants n'étaient pas dans les tests. L'audit des invariants avant d'introduire l'agent aurait dû être une condition bloquante.

J'aurais mis le hook Stop dès le premier jour. Les deux premières semaines sans ce hook ont produit du code que l'agent considérait "terminé" mais qui ne compilait pas dans le contexte de l'application complète. Chaque rollback coûtait 30 à 45 minutes.

J'aurais formé l'équipe sur ce que l'agent ne fait pas. Les développeurs juniors ont eu tendance à faire confiance au code généré parce qu'il "ressemble à du bon code". La formation sur les angles morts des agents — invariants implicites, décisions architecturales, contexte métier — aurait dû précéder l'accès aux outils.

Voici un extrait du skill de génération de tests d'invariants, tel qu'il existe aujourd'hui dans notre configuration :

# skills/domain-invariant-guard/SKILL.md (extrait)

## Objectif
Générer les tests d'invariants de domaine pour un agrégat modifié.

## Protocole
1. Lire src/Domain/[Aggregate]/INVARIANTS.md
2. Pour chaque invariant listé, vérifier qu'un test existe
3. Si absent, générer le test avec la forme :
   [Fact]
   public void [Invariant]_WhenViolated_ThrowsDomainException()
   [Fact]
   public void [Invariant]_WhenRespected_DoesNotThrow()
4. Ne jamais modifier le code de l'agrégat — tests uniquement
5. Committer avec préfixe red: avant toute implémentation

## Exemples d'invariants à couvrir
- Transitions d'état interdites (ex: Approved → Draft)
- Contraintes de montant (ex: réaffectation sans recalcul fiscal)
- Unicité au sein de l'agrégat (ex: une seule ligne par code produit)
- Règles de cohérence temporelle (ex: date fin > date début)

La vraie question pour un CTO

Après six mois, la question n'est plus "est-ce que les agents IA fonctionnent ?" — ils fonctionnent, sur un périmètre précis, avec des gardes-fous précis. La vraie question est : votre organisation est-elle prête à tirer parti de ce qui fonctionne, et à protéger ce qui ne doit pas être délégué ?

Les équipes qui réussissent cette transition ont une caractéristique commune : elles traitent l'agent comme un nouveau membre d'équipe qui a besoin d'un onboarding sérieux, pas comme un outil qu'on branche et qui fonctionne. Le CLAUDE.md est son contrat de travail. Les skills sont ses procédures opérationnelles. Les hooks sont ses filets de sécurité. Et les invariants documentés sont la connaissance métier qu'on lui transfert avant de lui faire confiance sur les domaines critiques.

Si vous envisagez ce type d'investissement pour votre équipe, commencez par l'audit des prérequis. La question n'est pas le budget — c'est la maturité de votre base de code et de vos pratiques. C'est là que se gagne ou se perd le ROI.