Claude en entreprise, de l’architecture à la production.

Pourquoi Claude, et pourquoi maintenant#

Mon attachement à Claude ne tient pas de la magie. Il tient de l’amplitude. Le même assistant qui débat d’un compromis d’architecture le matin relit une migration Java avant midi, rédige un runbook l’après-midi et lit une stack trace en fin de journée. Un travail qui attendait qu’un des quatre spécialistes trouve une heure de libre commence désormais par une bonne question.

J’aime aussi son tempérament. Claude lit avant d’écrire. Il demande quelle est la contrainte au lieu de supposer qu’il n’y en a pas. Et il accepte qu’on lui dise qu’il a tort, ce qui n’est pas le cas de tous les outils ni de tous les ingénieurs, moi compris les mauvais jours.

Architecture : un sparring partner qui lit tout#

L’architecture en entreprise est surtout de l’archéologie. Avant de dessiner la cible, il faut comprendre des années de logique métier accumulée, des décisions à moitié documentées et des dépendances que personne ne se souvient d’avoir créées. Claude est le premier outil que j’utilise capable de tout lire, le code comme les documents, et de tout tenir dans une seule conversation.

Notre façon de l’utiliser est volontairement adversariale : propose trois options, puis attaque chacune. Où casse-t-elle sous la charge ? Que coûte-t-elle à exploiter ? Que suppose-t-elle du système legacy qui est faux ? Un modèle qui défend brillamment la mauvaise option est dangereux, donc la décision reste toujours chez nous. Ce que Claude supprime, c’est la page blanche et les angles morts, pas la responsabilité.

Code : le legacy d’abord, le greenfield ensuite#

Le débat public sur le code assisté par IA est obsédé par les projets neufs. L’essentiel de la valeur en entreprise se trouve à l’opposé : des applications établies qui doivent continuer à tourner pendant qu’on les modernise. C’est là que Claude m’a le plus surpris.

Monter de version un framework sur toute une application, démêler une classe que trois générations de développeurs ont étendue, écrire les tests qu’un module n’a jamais eus avant d’y toucher : c’est un travail patient et minutieux, exactement ce pour quoi un assistant infatigable excelle. L’ingénieur fixe la direction et les invariants ; Claude fait la longue marche à travers les fichiers ; le diff est relu comme n’importe quel autre diff.

Revue, tests et livraison#

Une seconde paire d’yeux qui ne fatigue jamais change l’économie de la qualité. Notre habitude est simple : Claude relit d’abord, les humains relisent avec ses conclusions en main. Le relecteur humain cesse de brûler son attention sur la couche mécanique, le nommage, les bugs évidents, les cas limites oubliés, et la consacre à ce qui le requiert vraiment : ce changement fait-il ce qu’il faut pour le produit ?

• Demander une revue avant d’ouvrir la pull request, pas après
• Faire écrire ou challenger les tests par l’assistant, puis les faire juger par l’auteur
• Le laisser lire le pipeline : jobs instables et étapes lentes sont des motifs, et il est bon avec les motifs

Production : incidents et runbooks#

C’est en production que l’affection est devenue sérieuse. Pendant un incident, la ressource la plus rare est un lecteur calme. Claude lit la stack trace, les changements récents et les logs sans paniquer, et propose des hypothèses par ordre de vraisemblance. Ensuite, il rédige le postmortem pendant que les détails sont encore chauds, et écrit le runbook que tout le monde jugeait nécessaire et que personne n’avait le temps d’écrire.

$ claude "lis cette stack trace et les trois derniers
déploiements. classe les causes probables."

Garde-fous : ce qu’exige un environnement réglementé#

Nous construisons des plateformes pour des institutions financières et des organisations du secteur public. Ici, la confidentialité n’est pas une préférence, c’est le produit. Utiliser Claude dans ce contexte est tout à fait possible, à condition que les règles existent avant l’enthousiasme.

• Les données confidentielles et clients restent hors des prompts, sans exception
• Un outillage et des comptes approuvés, pour ne pas découvrir plus tard du shadow AI
• La même exigence de revue pour chaque changement, tapé ou généré
• Un humain porte tout ce qui part en production, avec son nom dessus

L’adoption est un travail de management#

Les outils ne s’adoptent pas tout seuls. Ce qui a fonctionné chez nous n’a rien de spectaculaire : commencer avec les ingénieurs curieux, les laisser montrer de vraies sessions aux autres, et rester honnête sur les échecs autant que sur les réussites. Le jour où un sceptique regarde un collègue démêler en un après-midi ce qui aurait pris une semaine, la conversation change d’elle-même.

Ma conclusion, après avoir vécu avec Claude sur tout le cycle de vie, est simple. L’important n’est pas qu’il écrive du code. L’important, c’est que chaque étape du cycle gagne un second cerveau, et que l’équipe décide, délibérément, où ce cerveau est le bienvenu. Cette décision, c’est ça le leadership d’ingénierie aujourd’hui.