Comment cadrer un build IA

Le travail IA comporte plus d'incertitude inhérente que le logiciel ordinaire, donc un périmètre flou se compose plus vite. Quand « construire un assistant IA » est le périmètre, chaque partie comble les vides avec une hypothèse différente, et l'écart devient un litige dès l'arrivée de la facture.

Un bon périmètre n'élimine pas l'incertitude ; il la localise. Il dit exactement ce qui est construit, comment le succès est mesuré, et ce qui est explicitement hors champ — pour que les inconnues restantes soient petites et nommées.

1) Cible de flux — l'opération précise modifiée, pas une capacité. 2) Métrique de succès — une définition mesurable du terminé. 3) Inventaire des données — quelles données existent, où et dans quel état. 4) Points d'intégration — les systèmes exacts à connecter. 5) Contraintes — résidence des données, latence, budget, non-négociables. 6) Repère de calendrier — une date fixe qui rythme le travail.

Chacun correspond à du concret : la métrique de succès devient la suite d'evals ; l'inventaire des données détermine la faisabilité ; les points d'intégration sont là où se cache l'essentiel du coût caché.

Mauvais : « Utiliser l'IA pour améliorer le support client. » Bon : « Rédiger les premières réponses pour les tickets de facturation, notées sur un jeu de référence de 200 tickets, intégrées à notre service d'assistance, sans que les données client ne quittent notre cloud, en production en huit semaines. » Le second est constructible et chiffrable ; le premier est une invitation à facturer à l'heure.

Le test de toute ligne de périmètre : deux prestataires la chiffreraient-ils pareil ? Sinon, la ligne est trop vague pour s'y engager.

Les erreurs de cadrage fatales sont : définir une capacité au lieu d'un flux ; laisser le succès indéfini ; découvrir après signature que les données sont inutilisables ; et traiter l'intégration comme un détail. Chacune transforme une mission fixe en mission ouverte.

Un Diagnostic existe pour produire exactement ce périmètre — mais vous pouvez en faire une grande part vous-même d'abord, et arriver à la conversation avec les inconnues déjà réduites.

Le périmètre n'est pas une formalité d'achat qui précède la vraie ingénierie ; c'est le premier acte d'ingénierie, et chacun de ses six composants alimente directement l'un des quatre principes de la méthodologie. La métrique de succès devient la suite d'evals — les evals avant les fonctionnalités ne fonctionnent que si le périmètre nomme déjà à quoi ressemble le « fonctionnel » en chiffres. L'inventaire des données et les points d'intégration décident où la télémétrie doit être instrumentée, car on ne peut pas enregistrer la qualité sur un chemin que le périmètre n'a jamais tracé. Les contraintes — résidence des données, latence, budget — déterminent la forme de l'infrastructure possédée, puisqu'elles dictent quel cloud, quels comptes de modèle et quel stockage le système doit utiliser.

Le repère de calendrier est ce qui rend possible une pod légère sur une horloge fixe. Une pod de deux à trois personnes travaillant sur une horloge de huit semaines ne peut s'engager sur une date que si le périmètre a borné ce sur quoi elle s'engage. Pris dans l'autre sens, c'est un test utile de votre propre périmètre : prenez chaque ligne et demandez quel principe elle sert. Si une ligne ne correspond à aucun d'eux — si elle ne définit pas le terminé, ni ne nomme où mesurer, ni ne façonne ce que vous possédez, ni ne rythme l'horloge — c'est probablement de la décoration, et la décoration dans un périmètre est là où le coût s'accumule en silence.

C'est aussi pourquoi la méthodologie d'un prestataire et votre périmètre ne peuvent pas être évalués séparément. Un périmètre écrit pour un prestataire sans discipline d'evals dérivera quand même, car il n'y a rien en aval pour tenir la métrique de succès responsable. Le périmètre le plus solide au monde ne peut pas sauver un modèle de livraison qui profite de la poursuite du travail — et la pod la plus légère et la plus disciplinée ne peut pas sauver un périmètre qui n'a jamais dit ce que terminé signifie.

Un périmètre se teste dans la conversation qui le suit, et les questions qu'un prestataire vous renvoie en disent plus que la proposition qu'il envoie. La première chose à sonder est la métrique de succès : demandez comment il compte transformer votre définition du terminé en quelque chose d'automatisé et de reproductible. Un prestataire sérieux parlera d'un jeu de référence, de grilles de notation et de seuils ; un plus faible vous rassurera en disant qu'il « le saura quand il le verra », ce qui est précisément l'ouverture indéfinie que le bon périmètre existe pour empêcher. Demandez aussi ce qu'il refuserait de chiffrer tant qu'il n'a pas vu vos données — un prestataire qui chiffre n'importe quel périmètre sans rien voir gonfle lourdement ou prévoit de facturer la différence plus tard.

La deuxième série de questions porte sur la variance et sur ce qui se passe quand le build s'avère plus difficile que prévu. Demandez directement : sous votre modèle, gagnez-vous plus en terminant ou en continuant ? Demandez ce que produit l'étape de cadrage, si le prix est fixé par rapport à elle, et sur quoi la garantie est mesurée. Les réponses honnêtes ici sont précises — un prix fixe chiffré seulement après un Diagnostic, une garantie mesurée par rapport aux seuils d'evals convenus, un énoncé clair de ce qui est hors périmètre. Le flou dans les réponses est l'annonce d'un flou dans la facture.

Enfin, demandez ce que vous détiendrez quand la mission se termine. Où vivra le code, quel compte cloud l'exécute, qui possède les clés de modèle et le magasin de télémétrie. Les réponses distinguent un bâtisseur d'un propriétaire bailleur — et la distinction compte le plus précisément quand la relation se passe bien, car c'est là qu'un acheteur est le moins enclin à vérifier. Cadrez la sortie avant de cadrer le build ; il est bien moins coûteux de négocier la propriété à l'entrée que d'en découvrir l'absence à la sortie.

Les six composants ne sont pas d'égale urgence, et tenter de tous les perfectionner en parallèle est en soi une erreur de cadrage. Il existe un ordre qui dérisque le travail le plus vite. Réglez d'abord l'inventaire des données, car c'est le composant le plus susceptible d'être erroné d'une façon qui invalide tout l'aval — une cible de flux et une métrique de succès bâties sur des données qui s'avèrent incomplètes, inaccessibles ou juridiquement grevées sont des réponses sophistiquées à la mauvaise question. Confirmez que les données existent, que vous pouvez les utiliser légalement et qu'elles sont représentatives de la production avant d'investir un effort ailleurs.

Les données confirmées, fixez la cible de flux et la métrique de succès ensemble, car elles se contraignent mutuellement : la métrique n'a de sens que face à une opération précise, et l'opération ne vaut la peine d'être changée que si son succès peut être mesuré. Cartographiez ensuite les points d'intégration, là où se cache d'ordinaire le plus gros coût non budgété — le travail ingrat de se connecter à des systèmes qui ne se comportent en rien comme leur documentation. Les contraintes et le repère de calendrier viennent en dernier non parce qu'ils comptent le moins, mais parce qu'ils sont les plus faciles à énoncer une fois la substance réglée ; une date et une règle de résidence sont rapides à écrire et rapides à vérifier.

La limite honnête de faire cela vous-même est le travail sur les données et l'intégration. Vous pouvez écrire une cible de flux solide, une métrique de succès testable et un ensemble clair de contraintes sans prestataire dans la pièce. Ce que vous ne pouvez généralement pas résoudre seul, c'est de savoir si les données soutiendront vraiment la métrique et si les intégrations sont aussi propres qu'elles en ont l'air — et c'est exactement cette incertitude que le Diagnostic de deux semaines est conçu pour réduire avant que le Build soit chiffré.

L'idée reçue la plus tenace est qu'un périmètre détaillé ralentit un projet — que fixer tout avant le build est une charge bureaucratique qui retarde le travail intéressant. C'est l'inverse pour l'IA en particulier, car l'incertitude qu'un périmètre flou laisse irrésolue ne disparaît pas ; elle est simplement reportée à un moment où il est bien plus coûteux de l'affronter. Une métrique de succès laissée vague à la signature devient un litige à la livraison. Une intégration supposée au cadrage devient quinze jours de travail imprévu au build. Le détail n'est pas le coût ; c'est ce qui empêche le coût.

Une deuxième idée reçue est qu'un périmètre plus long est un meilleur périmètre. La longueur n'est pas le signal — la testabilité l'est. Une page de lignes constructibles et chiffrables vaut mieux que dix pages d'aspirations, et bourrer un périmètre de capacités dont le projet n'a pas besoin est un moyen sûr de gonfler à la fois le devis et la surface de risque. La discipline est soustractive : un bon périmètre est autant un relevé de ce qui est explicitement hors champ que de ce qui est dedans. Nommer les exclusions clairement est ce qui maintient honnête une horloge de huit semaines.

La troisième idée reçue est qu'un périmètre est figé une fois signé. En pratique, le périmètre est une contrainte vivante que la télémétrie et les evals maintiennent honnête — la métrique de succès convenue au départ est l'étalon auquel les données de production sont ensuite mesurées, et une régression en dessous est une affaire de garantie plutôt qu'une renégociation. Ce qui ne doit pas bouger, c'est la définition du terminé ; ce qui peut s'apprendre, c'est comment la réalité se compare à elle. Traiter le périmètre comme un document ponctuel plutôt que comme un engagement mesuré, c'est ainsi que des missions bien parties dérivent quand même dans leur seconde moitié.