Que doit-il vous rester quand un mandat d'IA prend fin ?

La plupart des mandats d’IA se terminent par une réunion. Quelqu’un présente une dernière démo, quelqu’un d’autre approuve le dernier jalon, et le projet est marqué « complété » dans l’outil de suivi. Trois mois plus tard, un modèle de rapprochement de factures se met à mal lire la nouvelle mise en page PDF d’un fournisseur, et personne à l’interne ne sait où se trouvent les prompts.

C’est ce deuxième moment qui marque la vraie fin du mandat. C’est lui qui vous dit ce qui a réellement été livré.

Si vous êtes sur le point d’embaucher un partenaire en IA, ou si vous êtes à mi-chemin d’un mandat et que vous vous demandez ce qui vous restera à la fin, servez-vous de cet article comme d’une liste de vérification. Elle s’applique à nous, à une grande firme-conseil, à une boutique spécialisée comme à un consultant indépendant. Les questions restent les mêmes.

Pourquoi « livré » est-il la mauvaise ligne d’arrivée ?

Un jalon de livraison mesure si quelque chose a été remis. Il ne dit rien sur la capacité de votre entreprise à l’exploiter, à le modifier ou à bâtir dessus le trimestre prochain.

Les systèmes d’IA creusent cet écart. Une application traditionnelle se comporte à peu près de la même façon d’une année à l’autre. Un workflow d’IA dépend de choses qui bougent : versions de modèles, structure des prompts, index de recherche, forme des données entrantes, et les choix qu’une personne a faits sur les taux d’erreur acceptables. Quand les gens qui ont fait ces choix partent, le système continue de rouler. Personne ne peut dire s’il roule encore bien.

La ligne d’arrivée utile est donc une autre question. Votre équipe pourrait-elle exploiter ce système pendant douze mois sans appeler le partenaire qui l’a bâti ? Si la réponse est non, le mandat n’est pas terminé. Vous avez loué une capacité, et le loyer revient chaque fois que quelque chose change.

Nous avons traité la version précédente de ce problème dans pourquoi les projets pilotes d’IA stagnent. Un pilote qui n’atteint jamais la production, c’est l’échec évident. Un système en production que seul le fournisseur peut exploiter, c’est l’échec silencieux.

Que doit-il rester quand le partenaire s’en va ?

Cinq choses : du code et une infrastructure qui vous appartiennent, des workflows réutilisables, des artefacts de gouvernance, un contexte d’exploitation documenté et des gens dans votre équipe capables de faire rouler le système. Voyez cette liste comme un minimum, pas comme un idéal.

1. Du code et une infrastructure qui vous appartiennent entièrement

Le code vit dans vos dépôts. Pas un miroir, pas un fichier zip à la fin, pas un « accès sur demande ». Votre organisation GitHub ou GitLab, avec l’historique complet des commits depuis le premier jour.

Même chose pour l’infrastructure. Les modèles, les bases vectorielles, les files d’attente et les tâches planifiées doivent rouler dans des comptes infonuagiques que votre entreprise possède et paie. Si le partenaire héberge quoi que ce soit pendant la construction, il faut un plan écrit et une date de migration.

C’est plus important qu’il n’y paraît. Un nombre étonnant de projets d’IA roulent sur les clés d’API du fournisseur, sur son compte chez le fournisseur de modèles ou sur un outil d’orchestration qu’il gère. Tout fonctionne jusqu’à la fin du contrat, quand les clés sont révoquées.

À vérifier :

• Propriété des dépôts. Votre organisation possède le dépôt. Les ingénieurs du partenaire sont des collaborateurs qu’on retire à la fin.
• Propriété des comptes infonuagiques. La facturation, l’IAM (gestion des identités et des accès) et l’accès root sont entre vos mains.
• Comptes chez les fournisseurs de modèles. Les clés d’API d’OpenAI, d’Anthropic, d’Azure ou de tout autre fournisseur sont émises sous votre compte et vos ententes sur les données.
• Aucune dépendance cachée à l’exécution. Si le système appelle un service propriétaire du partenaire, vous devez le savoir avant de signer, avec ce qu’il en coûte pour le garder ou le remplacer.

2. Des workflows réutilisables

Votre premier système d’IA règle habituellement un seul problème : classer les courriels entrants, extraire les champs des bons de commande, rédiger une première réponse pour une file de soutien. Le deuxième aura besoin de plusieurs des mêmes pièces. Ingestion de documents, couche de recherche, étape de révision humaine, journalisation des décisions, banc d’évaluation.

Un bon mandat bâtit ces pièces pour qu’on puisse les reprendre. L’analyseur de documents est un module avec une interface. La file de révision n’est pas codée en dur sur le canal Slack d’une seule équipe. La logique qui décide quand un humain doit intervenir est configurable au lieu d’être enfouie dans un prompt.

Faites le test avec une question à la fin : « Si on voulait appliquer ça à un deuxième processus, quelles pièces réutiliserait-on et lesquelles faudrait-il refaire ? » Un partenaire qui a bâti pour la réutilisation répond avec des détails précis. Un partenaire qui a bâti du jetable répond avec des généralités.

3. Des artefacts de gouvernance

On traite souvent la gouvernance comme de la paperasse, et c’est une erreur. Pour un système d’IA, les artefacts de gouvernance sont ce qui vous dit ce que le système est censé faire et s’il le fait encore. Notre article sur la gouvernance de l’IA pour les équipes produit va plus loin, mais voici le minimum :

• Un registre des décisions. Pourquoi ce modèle plutôt qu’un autre. Pourquoi ce seuil de confiance. Pourquoi certains cas sont envoyés à un humain. Chaque entrée indique qui a pris la décision et quand. Dans six mois, quelqu’un voudra modifier une de ces décisions et aura besoin de savoir contre quoi elle protégeait.
• Des jeux d’évaluation. Un ensemble étiqueté d’exemples réels, avec les résultats attendus, sur lequel vous pouvez tester le système chaque fois que quelque chose change. C’est l’artefact le plus précieux qu’un mandat puisse laisser. Sans lui, chaque mise à niveau de modèle est un pari.
• Des contrôles d’accès. Qui peut modifier les prompts, qui peut déployer, qui peut voir les données que le système touche. Mis par écrit, appliqués dans les outils et révisés.
• Surveillance et alertes. Des tableaux de bord et des alertes que quelqu’un dans votre équipe regarde vraiment : qualité des résultats, taux d’erreur, volume, coût par transaction. Notre article sur l’observabilité des agents d’IA explique quoi suivre.
• Une cartographie des données. Quelles données le système lit, où elles vont, ce qui est conservé et pour combien de temps. Dans un secteur réglementé, ou dès que vous traitez des renseignements personnels, c’est le premier document que votre responsable de la protection des renseignements personnels ou votre auditeur va demander.

4. Un contexte d’exploitation documenté

Chaque système d’IA encode des connaissances sur le fonctionnement de votre entreprise. Les règles qui déterminent quand une note de crédit doit être approuvée. Les trois fournisseurs dont les factures arrivent toujours avec le mauvais format de bon de commande. La raison pour laquelle l’équipe de nuit consigne les billets d’entretien autrement. Avant le projet, la plupart de ces connaissances vivaient dans la tête des gens et dans des chiffriers, et le travail du projet était de les en sortir. Nous avons décrit ce processus dans transformer le savoir institutionnel en systèmes de production.

Si ce contexte se retrouve seulement dans les prompts et le code, vous avez déplacé le savoir d’un endroit difficile à lire vers un autre. Il doit aussi exister en langage clair, sous forme de guide d’exploitation écrit pour la personne responsable du processus, pas pour un ingénieur.

Un bon guide d’exploitation répond à ces questions :

• Que fait ce système, en deux paragraphes qu’un nouveau gestionnaire pourrait suivre ?
• À quoi ressemble la « normale » ? Volumes, taux d’erreur, coûts.
• Quels sont les modes de défaillance connus, et que faut-il faire dans chaque cas ?
• Quelles règles d’affaires sont encodées, et qui, de votre côté, est responsable de chacune ?
• Comment modifier une règle sans risque ?

5. Des gens dans votre équipe capables de le faire rouler

C’est l’élément le plus souvent oublié, et c’est lui qui décide si tout le reste sera utilisé.

Quelqu’un dans votre entreprise doit être l’opérateur. Cette personne n’a pas besoin d’écrire le code. Elle doit par contre comprendre le système assez bien pour lire les tableaux de bord, remarquer quand la qualité glisse, trier une alerte et juger quand escalader. Idéalement, une deuxième personne peut faire la même chose.

Ça ne s’acquiert pas dans une réunion de transfert la dernière semaine. Ça vient du travail aux côtés de ceux qui bâtissent le système, dès le début. Votre opérateur devrait être présent quand on fixe les seuils et qu’on étiquette les jeux d’évaluation, et présent lors du premier incident en production. À la fin, il devrait avoir lui-même apporté des modifications au système, le partenaire se contentant de réviser.

C’est ici que le principe « amplifier, pas remplacer » prend tout son sens. Si le système a été conçu avec les gens qui font rouler le processus, ces gens finissent par se l’approprier. S’il a été conçu autour d’eux, ils finissent par le contourner. On en parle dans une IA qui amplifie les équipes.

Comment chaque mandat devrait-il rendre le suivant moins cher ?

Le premier projet devrait laisser une fondation sur laquelle le deuxième démarre, pour que le projet deux soit livré nettement plus vite que le premier, et le projet trois plus vite encore. Sinon, vous payez pour une série d’îlots au lieu d’une capacité qui se bâtit d’un projet à l’autre.

Prenez un distributeur industriel de 300 employés. La première année, il automatise la réception des bons de commande. Le projet bâtit un pipeline d’ingestion de documents, une couche d’extraction de champs, une file de révision pour les cas à faible confiance, un jeu d’évaluation de quelques centaines de vrais bons de commande et un registre des décisions.

La deuxième année, il veut automatiser le rapprochement des factures fournisseurs. Si le premier projet était du jetable, le deuxième part de zéro. Nouvelle ingestion, nouvelle file de révision, nouvelle gouvernance, nouvelle courbe d’apprentissage.

Si le premier projet a été bâti pour être réutilisé, le deuxième démarre avec la moitié de sa fondation déjà en production. Le pipeline d’ingestion traite les factures avec quelques ajustements. La file de révision reçoit une nouvelle catégorie. Le banc d’évaluation est déjà là et n’a besoin que d’un nouveau jeu étiqueté. Les patrons de gouvernance sont connus. Et l’opérateur de la réception des bons de commande peut aider à concevoir le workflow des factures, parce qu’il sait déjà comment ces systèmes se comportent.

Si l’estimation de votre partenaire pour le projet trois ressemble à celle du projet un, demandez pourquoi.

C’est pour ça que nous avons bâti ChronoPlatform. Chaque mandat que nous menons laisse derrière lui des workflows réutilisables, des patrons de gouvernance et du contexte d’exploitation, et ChronoPlatform est l’endroit où ces pièces s’accumulent pour que le problème suivant parte de plus loin. Le code et les systèmes appartiennent toujours au client, dans les comptes du client. La plateforme garde les pièces réutilisables organisées et encadrées pour que personne n’ait à les redécouvrir.

Vous n’avez pas besoin de notre plateforme pour obtenir cet effet. Il vous faut par contre quelqu’un qui le conçoit volontairement, parce que ça n’arrive pas par hasard. Laissé à lui-même, chaque projet d’IA devient un îlot.

Quelles questions poser à un partenaire en IA avant de signer ?

Posez des questions sur la propriété intellectuelle, l’hébergement et les comptes, les conditions de sortie, la documentation et qui exploitera le système ensuite. Faites-le dès la première rencontre commerciale, pas une fois l’énoncé des travaux rédigé. La façon dont un partenaire répond en dit long sur sa vision de la fin de la relation.

Propriété intellectuelle

• À qui appartient le code écrit pendant le mandat ? Le contrat le dit-il clairement ?
• Y a-t-il des composantes que vous nous concédez sous licence plutôt que de nous les céder ? Lesquelles, et à quelles conditions ?
• Si vous utilisez des outils internes ou des accélérateurs pour bâtir plus vite, qu’advient-il de ce qu’ils produisent ? Est-ce que ce qu’ils produisent pour nous nous appartient ?

Hébergement et comptes

• Où le système roulera-t-il pendant la construction, et où roulera-t-il en production ?
• Le compte infonuagique de qui, le compte chez le fournisseur de modèles de qui, les clés d’API de qui ?
• Si quelque chose roule sur votre infrastructure, quel est le plan de migration et qui le paie ?

Sortie

• Si on met fin à la relation après la première phase, avec quoi repart-on, et dans quels délais ?
• Que faudrait-il pour que notre équipe, ou un autre partenaire, reprenne le tout sans vous ?
• Y a-t-il une partie du système qu’on ne pourrait pas exploiter si vous disparaissiez demain ?

Documentation et gouvernance

• Quelle documentation produisez-vous de façon standard ? Peut-on voir un exemple tiré d’un mandat passé, sans les détails du client ?
• Bâtissez-vous des jeux d’évaluation dans le cadre du travail ? Qui les étiquette, et est-ce qu’on les garde ?
• Où consignez-vous les décisions de conception, et qui a accès à ce registre ?

Qui l’exploite ensuite

• Qui, chez nous, voyez-vous comme opérateur du système, et comment cette personne participe-t-elle à la construction ?
• Comment mesurez-vous si notre équipe est prête à prendre le relais ?
• Quel soutien continu offrez-vous, et est-il optionnel ?

Cette dernière réponse est révélatrice. Le soutien continu est correct et souvent utile. Nous en offrons nous-mêmes. Le problème, c’est le soutien que vous ne pouvez pas refuser parce que le système ne roule pas sans lui. Dans une relation saine, vous continuez avec le partenaire parce que chaque mandat bâtit sur le précédent, et partir reste une vraie option.

Que faire si votre mandat est déjà en cours ?

C’est généralement réparable, et beaucoup moins cher à corriger maintenant qu’après le départ de l’équipe. Commencez par le jeu d’évaluation et la propriété des comptes, puis désignez votre opérateur.

Demandez le jeu d’évaluation, même petit, et faites-le rouler contre le système actuel pour obtenir une base de référence. Ensuite, demandez que les accès aux dépôts et aux comptes passent sous votre propriété si ce n’est pas déjà le cas. Ces deux étapes suffisent à vous faire passer de dépendant à autonome.

Ensuite, désignez votre opérateur et faites-le participer aux séances de travail jusqu’à la fin du mandat. Demandez-lui de rédiger la première version du guide d’exploitation, le partenaire la corrigeant. Ce qu’il comprend de travers dans cette version vous montre exactement où le transfert de connaissances n’a pas encore eu lieu.

Si vous évaluez des partenaires de façon plus large, notre comparaison entre fournisseurs, consultants et partenaires opérationnels explique comment chaque modèle gère la propriété et ce que ça implique pour vous une fois le mandat terminé.

Questions fréquentes

Quelle est la chose la plus importante qu’un partenaire en IA doit remettre ?

Le jeu d’évaluation. C’est un ensemble étiqueté d’exemples réels avec les résultats attendus, et c’est le seul moyen de savoir si une mise à niveau de modèle, un changement de prompt ou un nouveau format de données a brisé quelque chose. Sans lui, chaque changement est un pari.

Un système d’IA peut-il rouler dans le compte infonuagique du partenaire pendant le projet ?

Seulement de façon temporaire, avec un plan de migration écrit et une date. Les systèmes en production, les clés d’API des fournisseurs de modèles et la facturation doivent être dans des comptes qui appartiennent à votre entreprise, sinon le système peut cesser de fonctionner le jour où le contrat prend fin.

Comment savoir si votre équipe est prête à reprendre un système d’IA ?

Votre opérateur sait lire les tableaux de bord, trier une alerte, expliquer les règles d’affaires du guide d’exploitation, et il a déjà apporté des modifications au système avec le partenaire en simple réviseur. S’il n’y a jamais touché avant la dernière semaine, il n’est pas prêt.

Travailler avec Chrono Innovation

Nous menons nos mandats d’IA en partant du principe que tout ce que nous bâtissons vous appartiendra : le code dans vos dépôts, les systèmes dans votre infonuagique, les jeux d’évaluation, le registre des décisions et des gens dans votre équipe capables de les faire rouler. Si vous réfléchissez à un problème, ou si vous voulez mettre à l’épreuve une proposition qu’un autre vous a déjà faite, prenez rendez-vous avec notre équipe. Nous vous dirons ce que nous comptons laisser derrière nous, et vous pourrez nous tenir à notre parole.