Solution · AI Operations

Former son équipe à opérer l'IA, ce n'est pas un cours de ChatGPT. C'est lui monter une fonction.

Face à l'IA en production, il y a trois routes : recruter l'équipe, la faire opérer par quelqu'un d'autre, ou la faire opérer par les gens que tu as déjà. La troisième démarre le plus vite et s'exécute le plus mal, parce qu'on la confond avec un atelier d'une journée. On conçoit la fonction, on forme tes équipes sur tes vrais systèmes, et on reste jusqu'à ce qu'elles la tiennent seules.

On le monte chez moi Voir comment ça marche

Le problème

L'IA est déjà en production. L'opérer n'est le travail de personne en particulier.

L'IA en production tient sur deux personnes qui n'ont jamais accepté ce travail : elles le font par-dessus le leur, sans créneau, sans critère écrit et sans que ça figure dans leur évaluation.
Quand une sortie est bizarre, chacun décide seul s'il la corrige, l'ignore ou la remonte. Sans critère commun, le même cas se règle de trois façons selon qui est là.
Les exceptions — ce que le système ne sait pas traiter — s'entassent dans un canal de chat au lieu d'une file avec un responsable et un délai, et se traitent dans l'ordre de qui insiste le plus.
Tu as fait une formation IA il y a des mois. Tes gens savent écrire des prompts et ne savent toujours pas quoi faire quand le système dérive un mardi à neuf heures.
Personne ne regarde la consommation avant l'arrivée de la facture, et là, la conversation devient comptable au lieu d'être opérationnelle.
À chaque fois que le fournisseur bouge le modèle, il y a une semaine étrange : la qualité change, personne ne sait si c'est le modèle, le prompt ou la donnée, et on tranche à l'intuition.

Le coût de ne rien changer

Tu as payé le système, pas l'exploitation. Tant que l'IA vise juste, ce trou est invisible ; le jour où elle dérive, c'est un client qui le trouve et tu le paies plein tarif. Et il y a un second coût, plus lent et plus cher : comme l'opérer n'est le travail de personne, l'améliorer non plus — le système reste donc exactement là où tu l'as laissé le jour de la mise en production pendant que le marché continue. Les deux autres sorties ne sont pas gratuites non plus : ouvrir un poste, c'est entrer dans un recrutement pour un titre largement gonflé, et sous-traiter la fonction entière, c'est laisser le jugement opérationnel de ton métier chez quelqu'un d'autre.

La solution

On conçoit la fonction, on forme tes gens à l'opérer, et on se retire par paliers

1On commence par la carte, pas par la salle de cours : quels systèmes d'IA sont vivants, quelles décisions ils prennent, ce qui se passe quand ils tombent, et qui bouche ce trou aujourd'hui sans que ça figure nulle part.
2On définit la fonction et on la répartit : qui contrôle les sorties et à quel taux d'échantillonnage, qui traite la file d'exceptions, qui remonte et à qui, qui tient les listes de contrôle qualité et qui surveille la consommation. Avec des noms, des créneaux et des délais — pas un organigramme théorique.
3On forme sur ton système, avec tes cas et tes vraies pannes. Aucun exercice de manuel : tes gens s'entraînent sur les sorties que ton IA a produites la semaine dernière, y compris les ratées, et apprennent à distinguer une panne de modèle d'une panne de donnée.
4On met le critère par écrit : ce qui se corrige, ce qui s'accepte, ce qui se remonte et ce qui arrête tout. Ce document, c'est ce qui transforme le jugement d'une personne en standard d'équipe — et c'est aussi ce qui évite qu'un remplacement remette l'apprentissage à zéro.
5On ajoute les deux pièces qui séparent opérer de regarder : versionner les prompts — pour qu'un changement soit testé avant d'être poussé et puisse être annulé — et lire les coûts en exploitation, pour que l'équipe repère la dépense étrange avant la finance.
6On accompagne en production et on se retire par paliers : d'abord on opère devant eux, ensuite ils opèrent devant nous, puis seuls — avec les métriques de la fonction sur leur propre tableau et une revue régulière avec nous.

Ce qui change

Ce que tu arrêtes de perdre

Opérer l'IA cesse d'être une faveur : ça devient un travail avec un responsable, un créneau et un critère écrit, porté par des gens qui connaissent déjà ton exploitation, tes clients et tes exceptions.
Mécanisme
Le critère cesse de vivre dans la tête de deux personnes : il est écrit, entraîné sur des cas réels, et il survit aux vacances, aux arrêts et aux remplacements.
Mécanisme
Le système se remet à progresser : dès que quelqu'un a le mandat d'y toucher et un moyen sûr de tester et d'annuler un changement, l'IA cesse de se figer au point où on l'a déployée.
Mécanisme
Ce qu'on mesure : % de sorties contrôlées au taux d'échantillonnage convenu, délai de traitement de la file d'exceptions, % de blocages remontés par le bon chemin, listes de contrôle qualité exécutées à l'heure, et écarts de consommation repérés par l'équipe avant la finance.
Ce qu'on mesure

Fiche technique

Travail supprimé: faire qu'opérer l'IA soit une faveur invisible de deux personnes : sans créneau, sans critère écrit, sans file d'exceptions et sans personne pour surveiller la qualité ni le coût
Mise en place habituelle: 6–10 semaines
Entrée: tes systèmes d'IA déjà en production, l'équipe que tu as aujourd'hui, et tout ce qui se fait à la main quand ça dérive
Sortie: une fonction opérationnelle répartie entre tes gens — contrôle, exceptions, escalade, listes qualité, versionnage des prompts et lecture des coûts —, avec critère écrit, métriques propres et capacité à la tenir sans nous
Compatible avec: OpenAIAnthropicAzure OpenAIGoogle Vertex AILangSmithLangfuseJiraLinearServiceNowNotionMicrosoft 365Google Workspace
Peut se connecter à: Tu cola de incidencias y tu proceso de guardia actualesTus registros de producción, de donde salen los casos reales de formaciónTu gestión de prompts y tu panel de consumoTu marco de gobierno de IA y tu inventario de sistemas
Ce qu’on mesure: % de sorties contrôlées au taux d'échantillonnage convenudélai de traitement de la file d'exceptions% de blocages remontés par le bon cheminlistes de contrôle qualité exécutées à l'heureécarts de consommation repérés par l'équipe avant la finance
Adapté pour: les entreprises qui ont déjà de l'IA en production et une équipe qui connaît l'exploitation — DSI, COO ou responsable IA — et qui préfèrent développer la capacité en interne plutôt qu'ouvrir un poste ou confier leur jugement opérationnel à un tiers
Pas adapté pour: ceux qui n'ont encore rien en production — là il n'y a pas de fonction à opérer, il y a un système à construire — ni ceux qui cherchent une formation IA générale pour tout l'effectif : ça, c'est de l'adoption, et c'est un autre service

Questions fréquentes

Ce sont les trois sommets du même triangle, et le choix n'est pas idéologique : c'est du temps, du coût et du contrôle. Monter l'équipe, c'est recruter les rôles manquants et leur donner un mandat : la voie si l'IA va être au cœur de ton métier et que tu peux attendre un recrutement. Externaliser, c'est confier l'exploitation à un autre sur ton stack : la voie s'il faut que ça marche maintenant et que tu préfères payer une capacité déjà constituée. Former, c'est la troisième : les gens qui connaissent déjà ton exploitation, tes clients et tes exceptions apprennent à opérer le système, et le jugement reste à la maison. C'est la moins chère en argent et la plus chère en attention de la direction, parce qu'elle exige que quelqu'un change vraiment de travail, pas qu'il assiste à un atelier. Beaucoup finissent en mixte : on forme l'équipe et on opère avec elle le temps que la capacité mûrisse.

Non, et la différence se voit dès le premier jour. Un cours apprend à utiliser l'outil : mieux écrire des prompts, connaître les fonctions, tirer parti du chat. Ici on apprend à tenir un système qui prend déjà des décisions avec des clients au bout : comment on échantillonne les sorties, quoi faire d'une sortie qui sent mauvais, quand on arrête tout, comment on traite une file d'exceptions avec un délai, comment on teste un changement avant de le pousser, comment on lit la consommation. Et ça ne finit pas par une attestation : ça finit par une fonction répartie, un critère écrit et des métriques que ton équipe regarde chaque jour. Si c'est la première chose qu'il te faut, c'est de l'adoption et c'est un autre service — on le fait aussi, on ne l'appelle simplement pas pareil.

L'essentiel de la fonction n'est pas de l'ingénierie : c'est du jugement opérationnel. Distinguer une bonne sortie d'une mauvaise dans ton métier, savoir quel cas mérite qu'on arrête et lequel se corrige et continue, comprendre quelle exception est ponctuelle et laquelle est un motif à régler en amont. Quelqu'un qui regarde tes processus depuis des années fait ça mieux que quelqu'un qui débarque avec un titre à la mode. Les deux parties techniques — versionner les prompts et lire les coûts — s'enseignent concrètement, sur tes outils, sans écrire une ligne de code. Là où un profil technique est vraiment nécessaire, on le dit et on l'inscrit dans la répartition au lieu de faire semblant que n'importe qui peut couvrir.

C'est pour ça que le livrable n'est pas la personne formée : c'est la fonction écrite. Le critère, la répartition, les délais, les listes de contrôle et les métriques sont documentés et vivants — un remplaçant arrive pour lire et s'entraîner, pas pour reconstruire. On répartit aussi toujours sur plus d'une personne et on définit un suppléant pour chaque pièce : une fonction qui dépend d'un nom propre n'est pas une fonction, c'est une dépendance. Et si le trou est gros, on le couvre le temps que le remplaçant monte en charge, sans arrêter l'exploitation.

On le monte chez toi ?

Tu as ciblé le problème. On livre la solution et on la laisse mesurée.

Voir le service