L'IA accélère la surface. Elle ne décide pas du sous-sol.

Les agents écrivent du code plus vite que vos équipes ne peuvent le relire. J'aide les équipes techniques à décider ce que les agents peuvent toucher, ce qui reste humain, et ce qui doit être écrit avant qu'ils commencent.

Coupe : le code en surface repose sur trois couches de décisions, construire, arbitrer et cadrer, qui restent identiques. Le code s'y dépose en lamines fines, de plus en plus nombreuses vers la droite, et passe au-dessus du niveau que l'équipe peut relire : la revue déborde. Plus une couche est profonde, plus la décision est ancienne, d'aujourd'hui à trois ans. âge des décisions aujourd'hui 3 mois 3 ans q code c construire j arbitrer t cadrer ce que l'équipe relit la revue déborde

Le code ne coûte presque plus rien. Les décisions, si.

Un agent ne devine pas. Un développeur expérimenté comble ce qui n'est écrit nulle part : la convention que tout le monde respecte, la contrainte métier qu'on ne rappelle plus, la décision prise il y a deux ans pour une bonne raison. Un agent exécute ce qui est écrit et invente le reste. Tout ce qui était implicite devient un risque.

Un agent va vite, y compris dans la mauvaise direction. Sans décisions solides en dessous, il produit de la dette au rythme où il produit du code. Le problème n'apparaît pas tout de suite : il apparaît quand on essaie de modifier ce qui a été produit.

L'IA ne rend pas le cadrage et l'arbitrage moins nécessaires. Elle les rend obligatoires.

Ce que je rencontre, en général.

  • cadrer

    Des licences achetées pour toute l'équipe, et personne ne sait dire ce qu'elles ont changé.

  • cadrer

    Une direction qui demande « où en est-⁠on avec l'IA ? » et une équipe qui n'a pas de réponse chiffrée.

  • arbitrer

    Un usage qui varie d'un développeur à l'autre, sans règle commune.

  • arbitrer

    Une sécurité ou un service juridique qui bloque, faute de savoir ce qui sort de l'entreprise.

  • arbitrer

    Une revue de code devenue le goulot : on produit plus vite qu'on ne relit.

  • construire

    Du code fusionné que son auteur n'est plus capable d'expliquer.

Aucun de ces problèmes ne se règle avec un outil de plus. Chacun se règle avec une décision.

Trois couches, appliquées aux agents.

  1. Cadrer.

    Où l'IA rapporte vraiment, et où elle ne fait que déplacer le problème.

    Je cartographie votre chaîne de développement telle qu'elle fonctionne, pas telle qu'elle est décrite : du besoin à la mise en production, avec ses vrais goulots. Je mesure le point de départ (délais, retours en arrière, temps de revue) pour que le gain, s'il existe, puisse se constater plutôt que se ressentir. Je fais remonter ce que vos développeurs savent par cœur et que personne n'a écrit : c'est exactement ce qu'un agent ignorera.

    Ce que ça vous évite : accélérer l'étape qui n'était pas le goulot.

  2. Arbitrer.

    Ce que les agents peuvent toucher. Ce qui reste humain.

    Je pose les options sur la table : quels outils, pour quels usages, avec quel degré d'autonomie. Je fixe avec vous les limites : ce qu'un agent peut modifier seul, ce qui exige une relecture, ce qui ne sort jamais de l'entreprise. Je chiffre ce qu'on accepte (coût des outils, temps de revue, part du code que l'équipe connaîtra moins finement) et je nomme explicitement ce qu'on reporte.

    Ce que ça vous évite : une adoption qui se décide par défaut, développeur par développeur.

  3. Construire.

    La chaîne dans votre dépôt, avec vos équipes.

    J'écris avec vos équipes le contexte dont les agents ont besoin : conventions, décisions d'architecture, contraintes métier, versionnés avec le code et relus comme lui. Je pose les points de contrôle : des tests qui servent de contrat, une revue concentrée là où le risque est réel, une mesure qui continue après mon départ. Je transmets la façon de faire évoluer la chaîne, parce que les outils auront changé dans six mois et que vos décisions, elles, doivent tenir.

    Ce que ça vous gagne : une équipe qui pilote ses agents, au lieu de les subir.

Deux engagements.

Indépendant des éditeurs. Je ne revends aucune licence et n'ai de partenariat avec aucun éditeur d'outils. Quand je recommande un outil, ou aucun, votre contexte est le seul critère.

Pas de promesse en pourcentage. Je ne vous annoncerai pas un gain de productivité avant d'avoir regardé votre chaîne. Je vous promets un point de départ mesuré et des décisions tranchées ; le gain se constate ensuite, ou pas, et on le saura.

L'IA en production, sur le terrain.

Ce cas porte sur l'IA dans un produit, pas dans une chaîne de développement. Le raisonnement est le même : ce qu'on confie au modèle, ce qu'on lui refuse, ce qu'on garde remplaçable.

  • code : la situation
  • construire : la conséquence
  • arbitrer : la décision
  • pointillé : l'option écartée

Cas 04

Ce qu'on confie au modèle, et ce qu'on lui refuse.

La situation. Une plateforme de messagerie qui traite des milliers de conversations par jour. Les conseillers qualifient, répondent et résument chaque échange à la main.

La conséquence. Des fonctionnalités d'IA en production (qualification par étiquettes, réponses rapides, résumés), et un nombre de conversations traitées par conseiller nettement plus élevé, en simultané comme sur la journée.

La décision. Quelles tâches confier au modèle, et lesquelles laisser aux conseillers. L'équipe technique a comparé plusieurs solutions en conditions réelles, par tests A/B, et a mis les résultats sous les yeux de la direction et des responsables des conseillers : coût des appels au modèle contre temps réellement gagné. Ce sont eux qui ont tranché.

Les options écartées. Entraîner un modèle maison, qui n'était ni le métier ni la compétence de l'équipe ; à la place, une couche interne qui permet de brancher et de remplacer les modèles sans toucher au reste du code. Et des agents conversationnels entièrement autonomes, refusés : le conseiller reste dans la boucle.

Le coût accepté. Du temps de R&D, et du temps de conseillers testeurs pour affiner l'outil sur le terrain.

Trois autres décisions, hors IA, sur l'accueil

Corentin Le Gal

Corentin Le Gal

Éditeur de logiciel, plateforme temps réel, applications métier. J'ai construit en interne, dans des équipes de trois à quinze personnes : la taille d'une équipe produit, y compris au sein d'une ETI. Toujours du côté de ceux qui livrent.

Onze ans en interne, pas en missions de trois mois. J'ai vu vieillir mes propres arbitrages : ceux qui ont tenu, ceux que j'ai payés.

Je code toujours, chaque semaine. C'est ce qui me permet de savoir ce qu'une décision coûte réellement à ceux qui l'appliquent.

Basé à Angers. J'interviens à distance et sur site.

Questions fréquentes.

Faut-⁠il déjà utiliser des outils d'IA pour commencer ?

Non. L'audit sert aussi à décider par où commencer. Certaines équipes gagnent plus à clarifier leurs conventions avant d'introduire le moindre agent.

Recommandez-⁠vous un outil en particulier ?

Aucun par défaut. Les outils évoluent tous les trimestres ; le choix dépend de votre code, de vos contraintes de confidentialité et de ce que vous voulez confier aux agents.

Notre code peut-⁠il être envoyé à un fournisseur d'IA ?

C'est une décision, pas une évidence. Elle dépend des contrats des fournisseurs, de l'hébergement des modèles et de la sensibilité de chaque partie du code. Il existe plusieurs réponses intermédiaires entre « tout » et « rien », et l'audit les examine avec votre sécurité.

Comment savoir si l'IA améliore vraiment notre façon de développer ?

C'est le premier geste de Cadrer : mesurer délais, retours en arrière, temps de revue et incidents avant de changer quoi que ce soit. Sans cette mesure, on ne compare que des impressions.

Vous formez nos développeurs ?

Pas sous forme de formation catalogue. La transmission fait partie de la mise en place : vos équipes construisent la chaîne avec moi et repartent capables de la faire évoluer seules.

Et l'IA dans nos produits, pas seulement dans le développement ?

Même méthode : où elle rapporte, ce qu'elle coûte réellement par usage, ce qu'on refuse de lui confier. Le cas 04 en est un exemple.

Trois semaines pour savoir quoi décider sur l'IA.

Entretiens menés séparément avec l'équipe technique et la direction, lecture du code et de votre chaîne réelle, puis une note de décision de 12 à 15 pages : l'enjeu reformulé, ce qui tient et ce qui est fragile, les décisions qui engagent, ce qui peut attendre, la séquence des 90 prochains jours. La restitution se tient en présence des personnes qui décident. L'audit livre les deux couches du bas : cadrer, puis arbitrer. Construire la chaîne avec vos équipes vient ensuite, si vous le souhaitez.

  1. Appel de cadrage 45 min
  2. Immersion 2 semaines
  3. Restitution 90 min

Au forfait. Ce n'est pas un audit de sécurité : on décide ce qui peut sortir de l'entreprise, avec votre sécurité.

Le déroulé complet de l'audit

Le premier pas : un appel de cadrage de 45 minutes, sans engagement.

Réserver l'appel de cadrage (nouvel onglet)

Ou par email : contact@cernix.fr. Réponse sous 24 h ouvrées.

Une décision en vue ?

Réservez l'appel de cadrage directement dans mon agenda, ou écrivez-moi en deux lignes : le projet, la décision qui bloque.

Réponse sous 24 h ouvrées.

Cabinet
Cernix, conseil en architecture et cadrage technique
Siège
Angers
Terrain
À distance ou sur site · Ouest & Paris