Cadrer votre intégration Claude, puis la mettre en production

Une intégration échoue rarement sur l'appel au modèle. Elle échoue sur ce qui l'entoure : une sortie plausible et fausse qui part chez un client, une fonctionnalité indisponible parce qu'un service externe l'est, une consommation qu'on ne sait pas attribuer, un accès ouvert plus largement qu'annoncé. Cet accompagnement répond donc à une seule question : qu'est-ce que vous branchez, sur quoi, et qu'est-ce qui continue de fonctionner le jour où l'appel échoue. C'est une prestation facturée, sur devis selon le périmètre, et tout ce qui est produit vous appartient, code compris.

Ce que l'accompagnement couvre, et ce qu'il ne couvre pas

Il couvre deux temps que nous ne confondons pas. Le cadrage décide ce qui est branché et sous quelles garanties ; la réalisation met la fonctionnalité en production avec son repli, sa validation de sortie et sa supervision. Le cadrage se vend seul, et nous l'assumons : vous pouvez le prendre, puis réaliser en interne ou avec un tiers. Le dossier est écrit pour cela.

Ce n'est pas une prestation de cadrage général sur l'intelligence artificielle, et ce n'est pas de l'accompagnement au changement. Nous travaillons sur un périmètre fonctionnel nommé : cette fonctionnalité, dans cette application, pour ces utilisateurs. Notre parti pris est de refuser les périmètres ouverts du type « mettre de l'IA dans le produit ». Ils produisent des démonstrations que personne n'assume ensuite, et le coût de cette impasse est toujours payé par l'équipe qui reprend le dossier.

Les six axes de cadrage

Un mot sur l'axe 3, parce que c'est celui qu'on nous demande le plus souvent de sortir du périmètre pour tenir un budget. La règle que nous appliquons est que la fonctionnalité doit exister sans le modèle : celui-ci améliore le résultat, il ne conditionne pas son existence. Ce choix coûte un second chemin de code, et nous n'acceptons pas de le retirer. Une fonctionnalité qui tombe quand un service externe tombe n'est pas une fonctionnalité, c'est une panne différée dont la date reste à fixer.

Ce n'est pas seulement notre position, c'est ce que prévoit le contrat du service que vous utiliserez : il revient au client d'évaluer si une sortie convient à son usage, « y compris lorsqu'une revue humaine est appropriée », et les affirmations factuelles d'une sortie ne doivent pas être tenues pour exactes sans vérification indépendante (Commercial Terms of Service, section D.3).

Vous pouvez vérifier que nous appliquons cette règle à notre propre produit avant de nous l'entendre vendre. Sur ce site, le rapport d'audit est rédigé par un appel à l'API d'Anthropic quand une clé est configurée, et par un générateur déterministe quand elle ne l'est pas, y compris lorsque l'appel échoue en cours de route. La page se rend dans les deux cas, avec les mêmes constats et des phrases moins fluides. Deux chemins de code à écrire, aucune indisponibilité externe capable de rendre la fonctionnalité inaccessible.

Le livrable du cadrage

Le cadrage produit un dossier dont la forme est arrêtée, et non un compte rendu libre. Il contient le périmètre fonctionnel retenu et ce qui en est explicitement exclu, le contrat de sortie sous forme de schéma exécutable, la spécification du repli déterministe, la liste nominative des accès à ouvrir avec le compte de service qui les porte, la liste des sorties soumises à validation humaine avec le rôle qui valide, un jeu de cas représentatifs tirés de vos données réelles avec la sortie attendue pour chacun, et le plan de mesure de la consommation par usage fonctionnel.

Le jeu de cas est la pièce que nous tenons pour la plus durable, et c'est aussi celle qu'on nous demande le moins. C'est lui qui vous permettra de comparer deux modèles, d'en changer quand la gamme évolue, et de dire si une régression vient de votre code ou d'ailleurs. Sans lui, chaque décision technique ultérieure se prend au ressenti, et les discussions de renouvellement deviennent des confrontations d'impressions.

La réalisation, quand vous la confiez, livre le code, ses tests, la supervision et la documentation d'exploitation. Le code est déposé dans vos dépôts, avec vos conventions. Nous n'y installons aucun composant maison dont vous dépendriez ensuite, et aucune couche d'abstraction qui vous rendrait captif : ce que le code appelle, c'est l'API du fournisseur et vos propres modules.

Le déroulement du cadrage, en cinq temps

Votre charge tient donc en une demi-journée, répartie sur la mission, et c'est volontaire : lire du code, écrire un schéma et construire un jeu de cas ne demandent pas votre présence. Nous sollicitons vos équipes là où l'information ne peut venir que d'elles, c'est-à-dire sur le pourquoi d'une règle métier et sur ce qui se passe réellement quand la tâche est faite à la main. Le calendrier, lui, se fixe avec vous au moment du devis, en fonction de la disponibilité de vos interlocuteurs : nous ne l'annonçons pas sur une page publique.

Ce qu'on vous demande en entrée

• Un accès en lecture au code de l'application concernée, ou l'export du périmètre à étudier.
• La description de la tâche telle qu'elle se fait aujourd'hui, même et surtout si elle se fait à la main.
• Des exemples réels d'entrées et de sorties attendues, y compris les cas que vos équipes trouvent tordus : ce sont eux qui décident du contrat de sortie.
• La liste des systèmes que vous envisagez d'exposer, et celle des systèmes que vous excluez.
• Un compte d'API fourni par votre entreprise. Nous ne travaillons pas depuis un abonnement personnel sur des données professionnelles, le régime contractuel n'étant pas le même.
• Un interlocuteur technique, un référent métier, et la personne qui devra valider les sorties engageantes : c'est souvent celle qu'on oublie d'inviter.

Confidentialité : un accord est signé avant tout accès, aucune donnée de production n'est extraite au-delà des exemples que vous fournissez, et les copies de travail sont détruites à la fin de la mission. Le périmètre exclu s'écrit avant le premier envoi de données, jamais après le premier incident.

Et si la conclusion est de ne pas brancher de modèle

C'est une issue possible, et nous l'écrivons dans le dossier quand c'est le cas. Trois situations où notre recommandation est de ne rien brancher. Quand les cas d'entrée se dénombrent : une séquence déterministe est alors plus simple, plus testable et moins chère à exploiter, et nous le dirons même si cela réduit la prestation qui suit. Quand la sortie ne supporte aucune erreur et qu'aucune validation humaine n'est acceptable dans le processus : aucun montage technique ne rattrape cette contradiction. Quand personne n'a mesuré la tâche avant : sans ligne de base, vous ne saurez pas si l'intégration a servi.

Dans ces trois cas, le dossier de cadrage vaut ce qu'il coûte, parce qu'il documente pourquoi vous ne branchez pas. C'est exactement ce qu'un comité redemandera dans six mois, quand la question reviendra sous une autre forme.

Questions fréquentes