La phrase la plus coûteuse d'un contrat de conseil en IA est généralement celle qui manque. Les acheteurs négocient âprement le taux journalier, le calendrier, le nombre d'ingénieurs seniors nommés dans le cahier des charges, puis signent un document qui ne dit jamais à qui appartient le modèle entraîné, qui détient les données d'entraînement, ni ce qui se passe la première fois que la précision du système se dégrade. Six mois plus tard, le pilote fonctionne, les consultants sont partis, et personne dans l'entreprise ne sait réentraîner le système.
Cette lacune ne résulte pas de la mauvaise foi de l'une ou l'autre partie. Elle résulte d'un marché qui a grandi plus vite que sa propre documentation contractuelle. L'institut Human-Centered AI de Stanford suit l'essor de l'adoption en entreprise dans son AI Index Report annuel, et McKinsey a mené son enquête State of AI sur la même période. Les deux dessinent le même tableau : beaucoup d'organisations ont déployé quelque chose, bien moins savent montrer ce que cela a rapporté. La question de la propriété en est l'une des raisons. Un système que vous ne pouvez pas maintenir cesse de produire de la valeur dès que ceux qui l'ont construit quittent les lieux.
Ce guide porte sur le volet transfert du conseil en IA, et il s'adresse à la personne qui signe le bon de commande plutôt qu'à celle qui écrit le code. Il présente les quatre points à régler avant le début des travaux, les questions qui modifient une proposition lorsqu'on les pose tôt, et ce qu'un cabinet compétent aborde de lui-même sans y être poussé.
Une facture, trois dénouements très différents
Vendue sous l'étiquette unique de conseil en IA, une mission peut s'achever dans l'un de trois états, et la différence vaut plus que les honoraires.
Dans le premier, vous possédez un système qui fonctionne et la capacité de l'exploiter. Le code est dans votre dépôt, les poids du modèle ou la configuration de fine-tuning sont dans votre compte de stockage, le pipeline de données tourne sur une infrastructure que vous payez directement, et deux de vos propres ingénieurs ont livré une modification sous supervision avant la clôture de la mission. Le cabinet pourrait disparaître demain et le système continuerait de tourner.
Dans le deuxième, vous possédez un système qui fonctionne et rien d'autre. Le code a été livré, mais il se déploie par un pipeline que le cabinet a construit sur ses propres outils, le modèle a été entraîné dans un compte que vous ne contrôlez pas, et la seule documentation est le support de présentation de la restitution finale. Le système tourne jusqu'au jour où il ne tourne plus, et les seules personnes capables de le réparer envoient une facture.
Dans le troisième, vous possédez un rapport. C'est plus fréquent que le secteur ne l'admet, et ce n'est pas toujours un échec. Une véritable mission d'évaluation qui recommande à une entreprise de ne pas construire quelque chose a mérité ses honoraires. L'échec consiste à payer le prix d'une évaluation pour ce que vous pensiez être une réalisation.
| Dénouement | Ce que vous détenez ensuite | Ce que cela vous coûte plus tard |
|---|---|---|
| Système exploitable | Le code, les données, les artefacts du modèle, la chaîne de déploiement et une équipe qui y a déjà livré une modification | Vos propres heures de maintenance, et un cabinet que vous pouvez réengager par choix |
| Système dépendant | Un système en fonctionnement sur des outils et des comptes que vous ne contrôlez pas | Un contrat de maintenance que vous ne pouvez pas mettre en concurrence, tarifé par le seul cabinet capable de faire le travail |
| Rapport seul | Une recommandation, une feuille de route et aucun logiciel opérationnel | Un second cycle d'achat, sauf si le rapport était bien ce que vous aviez acheté |
Lequel des trois vous obtiendrez se décide dans le cahier des charges, pas au cours du dernier mois. Si vous comparez encore des prestataires, les questions de notre guide sur ce qu'il faut demander avant d'engager une agence d'IA constituent le bon point de départ, et notre liste de contrôle pour un premier recrutement d'agence couvre les mécanismes d'achat qui les entourent.
Le modèle n'est pas le livrable
Les acheteurs se représentent volontiers le modèle entraîné comme l'objet de leur achat, à la manière d'un bâtiment que l'on achète à un constructeur. La comparaison ne tient pas longtemps. Un modèle entraîné est l'instantané d'un jeu de données à un moment précis, et sa valeur décline à mesure qu'évolue le monde sur lequel il a été entraîné. Ce que vous devez réellement posséder, c'est la capacité de produire le modèle suivant, un actif différent, constitué d'éléments différents.
Cet actif comporte quatre composantes, et un contrat devrait les nommer toutes les quatre :
- Le pipeline d'entraînement. Le code qui transforme des données brutes en modèle candidat, y compris l'ingénierie des caractéristiques, le prétraitement et la suite d'évaluation. Sans la suite d'évaluation, vous ne pouvez pas savoir si le modèle suivant est meilleur ou moins bon que le modèle actuel.
- Les données d'entraînement, et le droit de continuer à les utiliser. Si une partie du jeu de données a été prise sous licence, achetée, collectée par scraping ou fournie par un tiers, l'accord devrait préciser ce qu'il advient de ce droit à la fin de la mission.
- Les artefacts du modèle eux-mêmes. Poids, adaptateurs, configurations de fine-tuning, modèles de prompts, index de recherche. Stockés là où vous pouvez les atteindre, et pas seulement là où le cabinet le peut.
- La chaîne de déploiement. Comment un nouveau modèle passe d'un ordinateur portable à la production, et qui est autorisé à appuyer sur le bouton.
Un cabinet dont le métier est de construire des systèmes sur mesure aura un avis sur chacun de ces points avant que vous ne les souleviez. Un cabinet qui hésite sur le deuxième vous apprend quelque chose d'utile sur la façon dont le jeu de données a été constitué.
Qui détient les clés des données
La propriété des données est rarement le point litigieux. Presque tous les cabinets sérieux accepteront d'écrire que vos données restent les vôtres. Le point litigieux est l'accès, et c'est l'accès qui détermine qui a l'avantage au bout de deux ans.
Trois configurations sont courantes. Le cabinet travaille dans votre compte cloud avec des identifiants que vous délivrez et pouvez révoquer : c'est la solution la plus nette et celle qu'il faut demander. Le cabinet travaille dans son propre environnement et vos données y sont copiées pour la durée de la mission : c'est acceptable si le contrat fixe une date de suppression et désigne la personne qui la confirme. Ou bien le cabinet travaille sur une plateforme partagée qu'il exploite pour plusieurs clients : elle peut être parfaitement gérée, et elle reste la configuration qui vous laisse le moins de recours si la relation se dégrade.
Demandez où les données seront physiquement hébergées, demandez qui, au sein du cabinet, peut les lire, et demandez quelle est la procédure de fin de mission. La réponse à la troisième question est celle qui distingue les cabinets ayant déjà accompagné le départ de clients de ceux qui ne l'ont jamais fait.
Les secteurs réglementés ajoutent une couche supplémentaire. Si vous êtes soumis à des règles sectorielles portant sur les données personnelles, les documents financiers ou les informations cliniques, le contrat doit répercuter ces obligations sur le cabinet et sur tout sous-traitant auquel il fait appel. Nos notes sur ce qui doit figurer dans un contrat d'agence d'IA détaillent davantage les clauses.
Le réentraînement est un coût, pas une faveur
Tout système d'IA construit sur des données du monde réel se dégrade, et aucun contrat de conseil en IA n'abolit cette règle. Le comportement des clients évolue, les catalogues de produits changent, le fournisseur en amont met à jour son API, un éditeur de modèles retire la version sur laquelle vous avez fait votre fine-tuning. Rien de tout cela n'est un défaut du travail initial. C'est la météo ordinaire de l'exploitation d'un modèle en production, et elle coûte de l'argent chaque année.
La plupart des propositions de conseil en IA chiffrent la réalisation et renvoient l'exploitation à une discussion ultérieure. Avancez cette discussion. Avant de signer, obtenez un chiffre pour ce que coûte le maintien du système en état de fiabilité pendant douze mois : supervision, réévaluation périodique, réentraînement lorsque l'évaluation l'exige, et heures d'ingénierie nécessaires pour livrer le modèle réentraîné. Si le cabinet ne peut pas fournir ce chiffre, soit il n'a jamais exploité de système en production, soit il espère que vous ne poserez pas la question avant d'être captif.
Le chiffre lui-même compte moins que son effet sur votre comparaison. Une réalisation proposée à un certain prix, assortie d'une lourde maintenance annuelle, peut facilement coûter plus cher sur trois ans qu'une réalisation proposée plus cher avec un véritable transfert. Notre analyse de ce que coûte réellement le travail d'une agence d'IA présente les fourchettes pour les types de mission courants.
Le runbook que personne ne demande
L'ajout le moins cher que vous puissiez faire à un cahier des charges est un document opérationnel nommément désigné, livré avant le paiement final, qu'un ingénieur compétent n'ayant jamais vu le projet pourrait suivre.
Il devrait expliquer comment exécuter le pipeline d'entraînement de bout en bout, comment lire les résultats de l'évaluation et ce que chaque chiffre signifie en termes métier, les modes de défaillance rencontrés par l'équipe pendant la réalisation et la manière dont elle les a résolus, les seuils à partir desquels quelqu'un doit intervenir, et la procédure d'escalade lorsque le modèle produit quelque chose qu'il ne devrait pas produire. Demandez-le comme un livrable assorti de critères de recette, et non comme une ligne dans la présentation de clôture.
Les cabinets s'y opposent moins souvent que les acheteurs ne s'y attendent. Le rédiger représente un ou deux jours de travail, et un cabinet qui compte remporter le contrat de maintenance a intérêt à ce que le système soit lisible. Ceux qui s'y opposent sont en général ceux dont la marge repose sur le fait d'être les seuls à comprendre ce qu'ils ont construit.
Associez au runbook une séance de transfert qui soit une séance de travail plutôt qu'une présentation. Vos ingénieurs devraient effectuer une modification réelle, lancer l'évaluation et la déployer pendant que le cabinet est encore facturé et encore responsable. Un transfert que personne n'a répété est un document, pas un transfert. Le même principe guide la comparaison de notre article sur l'intégration de l'IA avec une agence ou en interne.
Six questions qui modifient la proposition
Posez-les avant la deuxième réunion, et les propositions qui vous reviendront seront plus honnêtes et plus faciles à comparer.
- À la fin de cette mission, lequel des trois dénouements décrits ci-dessus achetons-nous ? Demandez une réponse formulée dans ces termes.
- Où se trouveront les artefacts du modèle, dans quel compte, et qui pourra les supprimer ?
- Combien coûte le maintien en fonctionnement pendant douze mois après votre départ ?
- Quelles parties des données d'entraînement ne nous appartiennent pas, et qu'advient-il de notre droit de les utiliser ?
- Citez un client dont l'équipe a repris l'exploitation de ce que vous avez construit. À quoi le transfert a-t-il ressemblé ?
- Si nous voulions confier ce système à un autre cabinet dans dix-huit mois, de quoi ce cabinet aurait-il besoin de votre part ?
La sixième question est celle à observer de près. Un cabinet sûr de son travail y répond directement, car il compte gagner par ses résultats plutôt que par les obstacles au départ. Un cabinet qui la reçoit comme une question hostile vous a indiqué comment la relation se termine.
Par où commencer la recherche
Il n'existe pas un seul bon type de cabinet de conseil en IA, ni un classement qui tranche à votre place. Un cabinet orienté stratégie est le bon choix lorsque la décision elle-même n'est pas arrêtée et que le risque est de construire la mauvaise chose. Une société d'ingénierie orientée réalisation est le bon choix lorsque la décision est prise et que le risque réside dans la construction. Un spécialiste de la data science est le bon choix lorsque la difficulté tient au modèle plutôt qu'au système qui l'entoure. L'essentiel est que le cabinet retenu soit honnête sur celui des trois qu'il est, et que le contrat le reflète.
L'annuaire classe les cabinets selon cette distinction précise. Parcourez les cabinets de stratégie et de conseil en IA lorsque la question est de savoir quoi construire, les spécialistes du machine learning et de la data science lorsque le modèle est la partie difficile, et les sociétés d'intégration de l'IA lorsque le travail consiste à relier un modèle à des systèmes que vous exploitez déjà.
Si vous préférez décrire le problème une seule fois et laisser les cabinets adaptés venir à vous, dites-nous ce que vous cherchez à construire et nous vous orienterons vers les agences de notre annuaire qui correspondent au travail. Cela ne coûte rien et vous n'avez aucune obligation d'engager qui que ce soit.
Achetez du conseil en IA selon les conditions du transfert plutôt que selon celles de la facture. Réglez la propriété avant de régler le prix. Les cabinets qui méritent d'être engagés vous respecteront d'avoir posé la question, et ceux qui se dérobent vous ont fait gagner un an.
Sources
- Stanford Institute for Human-Centered Artificial Intelligence, AI Index Report, annuel.
- McKinsey & Company, The State of AI, enquête annuelle.