Travailler avec une équipe AI Engineering sans être ingénieur

Ce que vous n'avez pas à faire

Commençons par retirer une pression inutile. Vous n'avez pas à choisir un modèle, à arbitrer entre deux approches de récupération d'information, à évaluer une architecture ou à juger de la qualité d'une implémentation. Ces décisions appartiennent à l'équipe, et les reprendre à votre compte crée le pire scénario : une solution imposée de l'extérieur dont vous restez responsable devant le métier.

En revanche, personne ne fera à votre place le travail de définir le problème, de dire ce qui est acceptable, d'apporter des cas réels et de trancher les arbitrages métier. Une équipe AI Engineering privée de ces éléments les invente — et elle les invente mal, non par incompétence, mais parce qu'elle n'a pas accès au terrain.

La bonne frontière n'est pas « métier d'un côté, technique de l'autre ». Elle est : vous décrivez ce qui doit être vrai, l'équipe décide comment le rendre vrai, et vous discutez ensemble de ce que cela coûte.

Arriver avec un problème, pas avec une solution

La demande arrive presque toujours déjà habillée en solution. Elle circule dans l'organisation sous une forme technique, souvent reprise d'une démonstration vue ailleurs, et elle ferme la discussion avant qu'elle ne commence.

La seconde formulation ne demande aucune compétence technique. Elle contient pourtant tout ce dont l'équipe a besoin : le besoin, les utilisateurs, la nature des données, les contraintes, les risques et un début de critère de réussite. Elle laisse ouverte la possibilité qu'une solution beaucoup plus simple qu'un agent réponde au problème.

Reformuler une demande déjà habillée en solution

Quand la demande arrive sous forme technique — et elle arrivera — la reformulation se fait en six questions, posées sans agressivité : quel travail humain cherche-t-on à alléger, qui le fait aujourd'hui, sur quelles données, quelles actions le système aurait-il le droit d'entreprendre, qu'est-ce qui serait grave, et comment saurons-nous que cela fonctionne ? Ce sont les six angles que l'équipe reprendra de toute façon.

Décrire le comportement attendu

Sur un système IA, la spécification ne peut pas énumérer toutes les entrées possibles. Elle décrit un comportement : ce que le système fait en situation normale, ce qu'il fait quand il n'est pas sûr, ce qu'il ne fait jamais. Cette description n'a pas besoin d'être technique, mais elle doit être observable — quelqu'un doit pouvoir regarder une sortie et dire si elle respecte la règle.

• Périmètre : quels cas sont traités, quels cas sont explicitement exclus, et l'exclusion est-elle visible pour l'utilisateur.
• Comportement nominal : ce que le système produit, dans quel format, avec quelles références ou justifications.
• Comportement en cas de doute : s'abstenir, proposer une réponse partielle, demander une précision, escalader vers un humain.
• Interdits absolus : ce que le système ne doit jamais produire, quelles que soient les circonstances.
• Place du contrôle humain : à quel moment du parcours, par qui, et avec quelle information pour décider.

Erreurs acceptables et erreurs inacceptables

C'est la contribution la plus utile d'un profil métier, et celle qui est le plus souvent oubliée. Aucun système IA n'est exempt d'erreurs ; la question n'est donc pas « combien d'erreurs » mais « lesquelles ». Une équipe technique ne peut pas trancher cette question à votre place : elle relève du risque métier, du contrat, de la relation client, parfois de la réglementation.

• Une erreur acceptable : une réponse incomplète que l'utilisateur repère immédiatement et corrige sans coût.
• Une erreur coûteuse : une réponse plausible mais fausse, que l'utilisateur ne peut pas distinguer d'une bonne réponse.
• Une erreur inacceptable : un engagement, une promesse, une donnée personnelle exposée, une décision présentée comme validée alors qu'elle ne l'est pas.
• Une asymétrie assumée : il est souvent préférable que le système se taise dix fois à tort plutôt qu'il affirme une fois à tort.

Formuler ces trois catégories transforme immédiatement la conversation technique : elle oriente les garde-fous, les seuils, la place du contrôle humain et la façon dont le système se comporte quand il n'est pas sûr.

Apporter des cas réels, y compris ceux qui dérangent

Un jeu de cas réels est l'apport le plus précieux d'un profil métier, et souvent le seul que l'équipe ne peut pas produire seule. Vingt cas issus du terrain valent mieux qu'un document de spécification de vingt pages, parce qu'ils portent des ambiguïtés que personne n'aurait pensé à écrire.

• Des cas ordinaires, représentatifs du volume quotidien.
• Des cas pénibles : demandes mal formulées, informations manquantes, plusieurs questions en une seule.
• Des cas limites : situations rares mais à fort enjeu, où l'erreur coûte cher.
• Des cas hors périmètre, pour vérifier que le système les refuse proprement.
• Pour chaque cas, ce qu'une bonne réponse humaine aurait été — c'est cette référence qui rend l'évaluation possible.

Ces cas doivent être anonymisés et respecter les règles de traitement des données de l'organisation. C'est un point à traiter au début, pas au moment où l'équipe attend le jeu de tests.

Participer à la définition de l'évaluation

L'évaluation est le point de rencontre entre le métier et l'engineering. L'équipe sait comment mesurer, comparer deux versions et automatiser des vérifications. Elle ne sait pas, en revanche, ce qui compte : quel écart est tolérable, quelle dimension prime sur les autres, quel seuil autorise une mise en production.

• Dire ce que « bonne réponse » veut dire dans votre métier, sur des exemples précis, pas dans l'absolu.
• Hiérarchiser : exactitude, exhaustivité, ton, format, rapidité — tout ne peut pas être prioritaire.
• Fixer des seuils avec l'équipe : ce qui déclenche une mise en production, ce qui déclenche un retour arrière.
• Accepter de relire des sorties : une revue humaine régulière sur un échantillon reste la mesure la plus fiable au démarrage.
• Prévoir la répétition : l'évaluation n'est pas un jalon, c'est un dispositif rejoué à chaque changement.

Prototype et production : deux conversations différentes

Beaucoup de tensions viennent d'un malentendu sur le statut de ce qui est montré. Une démonstration réussie prouve qu'un comportement est possible sur des cas choisis. Elle ne dit rien de la stabilité sur des cas non choisis, du coût à volume réel, du comportement en cas de panne d'une dépendance, ni de la charge de maintenance.

Le rôle d'un profil produit ou projet est de nommer cette différence au moment où elle est encore gratuite : avant que la démonstration n'ait été présentée à un comité qui la prendra pour une livraison. La question à poser à l'équipe n'est pas « quand est-ce prêt ? » mais « qu'est-ce qui manque entre ce que vous montrez et quelque chose que nos utilisateurs peuvent utiliser sans nous ? ».

Comprendre les dépendances de données, sans devenir Data Engineer

La qualité d'un système IA dépend d'abord de ce à quoi il a accès. Vous n'avez pas à comprendre les pipelines, mais quelques questions relèvent directement du métier et personne d'autre ne peut y répondre.

• Quelles sources sont nécessaires, qui en est propriétaire, et sous quelles conditions elles peuvent être utilisées.
• À quelle fréquence elles changent, et ce que devient une réponse fondée sur une version périmée.
• Qui a le droit de voir quoi : un assistant ne doit jamais élargir les droits de son utilisateur.
• Ce qui manque : les informations que les humains connaissent mais qui ne sont écrites nulle part.
• Ce qui est conservé, combien de temps, et ce qui peut être exposé à un tiers.

Discuter latence, coût et qualité comme un arbitrage produit

Ces trois dimensions sont liées : améliorer la qualité allonge souvent le temps de réponse et augmente le coût par usage. Une équipe technique peut décrire les options ; elle ne peut pas décider seule laquelle sert le mieux les utilisateurs. C'est un arbitrage produit, et le formuler comme tel évite qu'il soit tranché par défaut.

• Latence : quel délai reste acceptable dans le parcours réel, pas en moyenne mais dans le pire cas courant.
• Coût : quel coût par usage reste tenable si le volume double, et qui suit cette évolution.
• Qualité : à partir de quel niveau le service est utile, et au-delà de quel niveau l'effort supplémentaire n'apporte plus rien à l'utilisateur.
• Ce qu'on accepte de sacrifier en premier si les trois ne sont pas atteignables ensemble.

Ce qui relève du produit, ce qui relève de l'engineering

Une frontière explicite évite l'essentiel des frictions. Elle mérite d'être posée une fois, au début, plutôt que renégociée à chaque désaccord.

• Produit : le problème, les utilisateurs, le périmètre, le comportement attendu, les interdits, les priorités, les seuils d'acceptation, la place du contrôle humain.
• Engineering : l'architecture, le choix des composants, la stratégie de récupération d'information, l'implémentation de l'évaluation, la performance, l'exploitation.
• À deux : la définition de ce qu'on mesure, l'arbitrage qualité / latence / coût, le découpage en versions, la décision de mise en production.
• Personne : ce qui n'est écrit nulle part finit tranché implicitement, souvent au pire moment.

Documenter les décisions, pas les discussions

Sur un projet IA, le comportement du système résulte d'une accumulation de petites décisions : un périmètre restreint ici, un seuil relevé là, un cas écarté parce qu'il était trop rare. Six semaines plus tard, personne ne se souvient pourquoi, et la question revient à l'identique.

Une trace courte suffit : la décision, la date, la raison, et ce qu'on a accepté de perdre. Ce document n'est pas une formalité administrative — c'est ce qui permet de répondre à un utilisateur qui conteste un comportement, et d'éviter de refaire trois fois le même débat.

Les questions à poser en review

Une bonne question en review ne porte pas sur l'implémentation. Elle porte sur ce qui a été décidé implicitement et sur ce qui se passera quand la situation ne sera pas idéale.

• Sur quels cas avez-vous vu le comportement se dégrader ?
• Que fait le système quand l'information n'existe pas dans les sources ?
• Qu'est-ce qui a changé depuis la dernière version, et comment savons-nous que c'est mieux ?
• Quels cas avons-nous décidé de ne pas traiter, et est-ce visible pour l'utilisateur ?
• Qu'est-ce qui vous inquiète le plus si nous mettons cela entre les mains d'utilisateurs réels ?
• De quoi avez-vous besoin de notre côté pour avancer ?
• Qu'est-ce qui dépend d'un fournisseur externe, et que se passe-t-il s'il change ?

La dernière question de la liste — « de quoi avez-vous besoin de notre côté ? » — est celle qui déplace le plus de choses. Elle fait apparaître ce que l'équipe attend depuis trois semaines sans l'avoir demandé formellement.

Éviter le micro-management technique

La ligne est simple à énoncer : questionner un résultat est légitime, prescrire une implémentation ne l'est pas. Demander pourquoi le système répond ainsi sur trois cas précis est une contribution ; suggérer de changer de modèle, d'ajuster une formulation ou d'ajouter une étape technique est une intrusion, même quand l'intention est bonne.

Il reste un cas où insister est justifié : quand vous ne comprenez pas une réponse dont vous serez responsable devant le métier. Demander une explication supplémentaire n'est alors pas du micro-management, c'est une condition pour tenir votre rôle. La formulation qui fonctionne est directe : « je dois pouvoir expliquer ce comportement à un utilisateur ; peux-tu me le reformuler dans des termes que je pourrai reprendre ? ».

Une équipe AI Engineering travaille mieux avec un interlocuteur produit qui pose des questions difficiles sur le comportement qu'avec un interlocuteur silencieux qui découvre le résultat en production. La collaboration ne demande pas de compétence d'ingénieur ; elle demande de la précision, des cas réels et une frontière claire.

• AI Engineering
• Évaluation
• AI Product