Claude Code en DSI d'assureur : retour d'expérience après 3 mois

Pourquoi j'ai voulu tester Claude Code en conditions réelles

Depuis que Claude Code est disponible, je l'utilise quotidiennement dans mes propres projets. Mais ce qui m'intéressait vraiment, c'est de savoir comment il se comporte dans une vraie DSI d'assureur — avec des contraintes IT réelles : codebase legacy, règles de sécurité strictes, équipes de 20+ développeurs, et procédures de validation du code avant tout déploiement.

J'ai eu l'occasion de déployer Claude Code pendant 3 mois dans une DSI que j'accompagne. Voici ce que j'ai observé.

Contexte : une DSI d'assureur en 2026

L'équipe : 22 développeurs répartis entre une équipe backend Java (SI de gestion sinistres), une équipe frontend React, et une équipe data (Python/Spark). Environnement hybride on-premise / cloud.

Contraintes principales :

Ce qui a vraiment changé : 3 usages à fort impact

1. La revue de code automatisée

Avant : les revues de code prenaient en moyenne 45 minutes par PR pour les développeurs seniors. Avec Claude Code, ils lancent un '/review' sur la PR avant de la soumettre. Claude identifie les problèmes potentiels de sécurité, les violations des conventions maison (via le CLAUDE.md), les cas limites non gérés.

Résultat mesuré sur 3 mois : le nombre de commentaires de revue de code par PR a baissé de 62%. Les PR passent plus vite en revue humaine parce qu'elles arrivent déjà "pré-revues". Le temps de revue humaine est passé de 45 à 18 minutes en moyenne.

2. La documentation du legacy Java

Problème historique dans cette DSI : des modules Java écrits entre 2008 et 2015, documentés a minima, avec un turnover important. Des développeurs passaient parfois 2 jours à comprendre un module avant de pouvoir le modifier.

Avec Claude Code, ils demandent une explication complète du module avant d'intervenir. Claude lit le code, identifie les patterns architecturaux, documente les flux de données, signale les zones à risque.

Ce qui m'a surpris : Claude est particulièrement bon sur du legacy — il reconnaît des patterns anciens, comprend les dialectes Java de l'époque, et explique le "pourquoi" probable derrière des choix techniques qui semblent obscurs aujourd'hui.

3. La génération de tests unitaires

L'équipe avait une couverture de tests autour de 42% sur le backend — en dessous des standards. Générer des tests unitaires est une tâche fastidieuse que les développeurs font à reculons.

Avec Claude Code : '/test' sur un fichier génère les tests unitaires correspondants en quelques secondes. L'équipe a fait passer sa couverture de 42% à 71% en 6 semaines, sans augmenter la charge de travail perçue.

Ce qui ne marche pas (ou moins bien)

Les architectures très spécifiques. Sur les modules les plus anciens avec des patterns maison non documentés, Claude fait parfois des hypothèses incorrectes. Il faut toujours valider humainement les suggestions sur le legacy critique.

La génération de code from scratch. Claude Code est excellent pour améliorer, documenter, tester du code existant. Il l'est moins pour concevoir from scratch une architecture complexe — ce n'est pas son rôle principal d'ailleurs.

La gestion des secrets. Bien que Claude Code soit configuré pour ne pas traiter les fichiers contenant des credentials, il faut être vigilant. Le CLAUDE.md doit explicitement lister les répertoires et fichiers interdits.

La question de la gouvernance : ce que nous avons mis en place

Politique d'usage Claude Code adoptée par la DSI avant tout déploiement :

Conclusion : ce que je recommande

Claude Code crée de la valeur réelle et mesurable dans une DSI d'assureur — à condition de l'encadrer correctement. Ce n'est pas un outil qu'on déploie en 5 minutes. C'est un assistant technique qui doit être configuré, gouverné et intégré dans les workflows existants.

Les deux prérequis non négociables : un compte Enterprise (pour la confidentialité des données) et un CLAUDE.md bien rédigé (pour que Claude respecte les règles de votre organisation).

Pour les DSI qui me lisent : commencez par un pilote sur une équipe volontaire de 3 à 5 développeurs, sur des projets non critiques. Mesurez. Puis étendez.