Point clé
L'IA dans le marché intermédiaire se bâtit en écosystème, pas avec un seul fournisseur, et la plupart des écosystèmes ont déjà la stratégie, la distribution et les plateformes. Ce qui manque, c'est l'ingénierie qui bâtit le système et l'exploite après le lancement, et les partenaires qui s'en assurent décideront quels projets IA atteignent la production.
Aucune entreprise ne bâtit seule un système IA de production pour un client de taille moyenne. Cet article s’adresse au côté partenaires de ces projets : associés de cabinets-conseils, dirigeants d’agences et gestionnaires d’alliances chez les plateformes. Il explique pourquoi la livraison en production est le maillon qui manque à la plupart des écosystèmes, et ce qu’il faut exiger d’un partenaire de livraison.
Imaginez qui participe vraiment quand une entreprise de taille moyenne met un système IA en production. Pas la version communiqué de presse. La vraie.
Il y a généralement un conseiller qui comprend l’entreprise : un cabinet comptable ou de conseil qui assiste aux réunions du conseil depuis des années et sait où la marge s’échappe. Il y a une firme qui a la légitimité de proposer le projet. Ça peut être le même conseiller, une agence numérique ou un fournisseur de services TI. Il y a une plateforme sur laquelle le système va rouler, souvent un fournisseur infonuagique, un progiciel de gestion intégré (PGI) ou un outil de flux de travail que l’entreprise paie déjà. Et quelque part, il faut des ingénieurs capables de bâtir la chose, de la brancher sur des systèmes internes désordonnés, de la mettre en production et de la garder fonctionnelle après le lancement.
Dans le marché intermédiaire, l’IA se bâtit en écosystème, pas avec un seul fournisseur, et la plupart des écosystèmes ont le même trou. La stratégie ne manque pas. La distribution existe. Les plateformes sont matures. Ce qui est rare, c’est la livraison en production, et celui qui la fournira de façon fiable influencera la manière dont le reste de l’écosystème fait de l’argent avec l’IA.
Pourquoi une seule entreprise ne peut-elle pas livrer un projet IA seule?
Parce que chaque acteur est fort dans un ou deux domaines et structurellement faible dans les autres. Ce n’est pas une critique. C’est la façon dont leurs entreprises sont bâties.
Les cabinets-conseils ont l’accès au domaine et la confiance. Leurs associés connaissent les finances, les contrôles et l’exposition réglementaire du client mieux que quiconque. Leur modèle économique repose sur les heures d’experts, et la plupart ne sont pas organisés pour doter une équipe logicielle qui écrit, teste et soutient du code de production pendant des années.
Les agences et les firmes de services TI ont la distribution. Elles détiennent la relation, l’énoncé des travaux et la discussion de renouvellement. Beaucoup ont de solides pratiques Web, données ou intégration. Moins nombreuses sont celles qui ont une expérience poussée de l’évaluation de modèles, de la conception de la recherche documentaire, de l’orchestration d’agents et du travail opérationnel qui garde un système IA honnête après sa mise en service.
Les plateformes fournissent la fondation : calcul, modèles, services de données, moteurs de flux de travail, places de marché. Leurs programmes de partenaires existent parce qu’elles ne veulent pas faire de livraison sur mesure pour des milliers de comptes du marché intermédiaire. Elles ont besoin que d’autres transforment leurs briques de base en systèmes qui fonctionnent.
Les firmes d’ingénierie savent bâtir. Seules, il leur manque souvent la confiance du client et le contexte du domaine qui font qu’un projet vaut la peine d’être bâti.
Réunissez les quatre et le client a tout ce qu’il lui faut. Laissez-en un de côté et le projet cale à un endroit prévisible.
Quels sont les quatre rôles d’un écosystème de livraison IA?
L’accès au domaine, la distribution de confiance, une plateforme, et une livraison qui bâtit et exploite le système. Chacun vient d’un type de firme différent, et chacun brise quelque chose de précis quand il manque.
| Rôle | Ce qu’il apporte | Généralement détenu par | Ce qui brise sans lui |
|---|---|---|---|
| Accès au domaine | Compréhension des affaires, des risques, de la réglementation et des données du client | Cabinets-conseils, associations sectorielles, spécialistes verticaux | Le système règle le mauvais problème, ou un problème que personne ne paiera pour régler |
| Distribution de confiance | La relation, la légitimité de proposer, l’accès à l’approvisionnement | Conseillers, agences, firmes de services TI, revendeurs | Les bonnes idées ne sont jamais achetées |
| Plateforme | Infrastructure, modèles, services de données, un endroit où le système peut vivre | Fournisseurs infonuagiques, éditeurs de PGI et d’outils de flux, places de marché | Chaque projet réinvente la pile et coûte trop cher à exploiter |
| Livraison (bâtir et exploiter) | Ingénierie, intégration, tests, déploiement, surveillance, soutien continu | Équipes d’ingénierie spécialisées, ou l’équipe interne du client s’il en a une | La feuille de route est approuvée et rien n’atteint la production |
C’est à la dernière ligne que la plupart des discussions entre partenaires deviennent floues. Tout le monde convient que la livraison compte. Peu de modèles de partenariat précisent qui s’en charge, sous quel contrat, avec quel engagement de soutien après le lancement.
Pourquoi la livraison est-elle le goulot des projets IA?
Trois forces font de la livraison le maillon rare en IA, plus que lors des vagues technologiques précédentes : exploiter le système coûte plus cher que le bâtir, les compétences sont rares, et les projets pilotes ne prouvent pas le chemin vers la production.
Pourquoi exploiter un système IA est-il plus difficile que le bâtir?
Parce qu’un système IA n’est jamais vraiment « terminé ». Un projet logiciel traditionnel est livré, passe les tests d’acceptation, et l’entretien devient un petit poste récurrent. Les systèmes IA ne se comportent pas comme ça. Les fournisseurs de modèles lancent de nouvelles versions. La qualité de la recherche documentaire dérive à mesure que les documents changent. Les agents qui appellent des outils peuvent échouer de façons nouvelles quand une API en amont change. Quelqu’un doit suivre les scores d’évaluation, réviser les résultats signalés, gérer le coût par transaction et réagir quand le comportement change.
Ce travail d’exploitation est continu, technique et facile à oublier dans la proposition initiale. Quand il manque, le client vit le projet comme « ça a marché quelques mois, puis ça s’est dégradé ». Le blâme retombe sur celui qui possède la relation, pas sur celui qui a écrit le code. On a décrit à quoi ressemble cette surveillance dans l’observabilité des agents IA en production.
Pourquoi les compétences en livraison IA sont-elles si difficiles à trouver?
Les ingénieurs capables de faire passer un agent d’un carnet à un service de production, avec des suites d’évaluation, des garde-fous, des journaux d’audit et des solutions de repli sensées, forment encore un petit groupe. Les cabinets-conseils et les agences peuvent en embaucher quelques-uns, mais monter une équipe complète pour une pratique qui cherche encore sa demande est un pari risqué. La plupart se retrouvent avec quelques personnes solides tiraillées entre trop de mandats.
Pourquoi un projet pilote réussi ne prouve-t-il pas le chemin vers la production?
Un projet pilote prouve qu’un modèle peut faire la tâche sur des données choisies. Il ne prouve pas que le système peut gérer de vrais volumes, de vraies permissions et de vrais cas limites dans l’environnement du client. C’est dans cet écart que meurent beaucoup d’initiatives IA, un schéma qu’on décrit dans la stratégie IA pour les entreprises en croissance : du projet pilote à la production. Un écosystème qui vend des projets pilotes sans chemin crédible vers la production vend la partie la plus fragile du projet.
Que chercher chez un partenaire de livraison IA?
De l’ingénierie de production, des engagements d’exploitation écrits, une gouvernance que l’équipe de gestion des risques du client acceptera, et un comportement commercial qui ne menace pas votre relation. Si vous êtes associé d’un cabinet-conseil, dirigeant d’agence ou gestionnaire d’alliances, voici la liste qu’on utiliserait nous-mêmes. Elle est exigeante exprès, parce que les échecs d’un partenaire de livraison deviennent votre problème avec le client.
De l’ingénierie pour la production, pas pour la démo
- Des suites d’évaluation bâties avant le lancement, avec une base de référence acceptée par le client
- L’intégration avec les exigences d’identité, de permissions et d’audit du client
- Des solutions de repli claires quand le modèle hésite ou qu’une dépendance est en panne
- Un déploiement par un vrai pipeline, pas un téléversement manuel
Des engagements d’exploitation après la mise en service
- La surveillance de la dérive de qualité, de la latence et du coût par transaction
- Un processus défini pour les mises à niveau de modèles et de dépendances
- Un responsable des incidents et des délais de réponse inscrits dans l’entente
- Des rapports que le client peut lire, formulés en résultats d’affaires
Une gouvernance que l’équipe de risques du client acceptera
- Une résidence et un traitement des données conformes aux obligations du client
- Des décisions documentées sur les endroits où des humains restent dans la boucle
- Une piste d’audit de ce que le système a fait et pourquoi
Pour en savoir plus sur cet aspect, voyez la gouvernance de l’IA pour les équipes produit.
Un comportement commercial qui respecte l’écosystème
- Aucune concurrence pour la relation client apportée par le partenaire
- La volonté de livrer sous le contrat du partenaire, à côté de celui-ci ou directement, selon les besoins du client
- La transparence sur la structure de marge, pour que les deux côtés puissent établir leurs prix
- Une remise claire du compte à la fin de chaque mandat
C’est souvent dans ce dernier groupe que les partenariats échouent en silence. Un partenaire de livraison qui se met à vendre directement à votre client après le premier projet est un concurrent avec un accès privilégié. Rendez les incitatifs explicites dès le premier jour.
Qu’est-ce que chaque partenaire gagne d’une couche de livraison partagée?
Chaque acteur peut faire croître la partie de son entreprise pour laquelle il est bâti. Combler le trou de la livraison, ce n’est pas donner du travail.
| Acteur | Ce qu’il cède | Ce qu’il gagne |
|---|---|---|
| Cabinet-conseil | La réalisation directe du travail d’ingénierie | Des mandats de stratégie et de gouvernance IA qui mènent à des systèmes que les clients utilisent vraiment, des relations-conseils plus durables, du travail subséquent en contrôles et en certification |
| Agence ou firme de services TI | Monter d’avance une équipe complète d’ingénierie IA | La capacité de dire oui aux projets IA dès maintenant, une marge sur le travail livré, une relation d’exploitation qui se renouvelle |
| Plateforme | Rien qu’elle voulait garder | De la consommation sur son infrastructure, des déploiements à citer en référence, des comptes apportés par les partenaires |
| Partenaire de livraison | La propriété de la relation client | Du travail régulier et bien délimité avec des partenaires qui ont déjà la confiance et le contexte |
L’échange ne fonctionne que si chaque côté est honnête sur ce qu’il fait bien. Une firme qui veut posséder toutes les couches est un fournisseur solo avec une diapositive « partenaires ».
À quoi ressemble la colivraison dans un vrai projet?
Chaque firme fait la partie pour laquelle elle est bâtie, et le client continue de traiter avec la firme en qui il a déjà confiance. Cet exemple est fourni à titre d’illustration. Il montre la structure, pas un mandat précis.
Un manufacturier régional de quelques centaines d’employés travaille avec le même cabinet-conseil depuis dix ans. Pendant une revue de fin d’année, le chef des finances mentionne que les soumissions pour les commandes sur mesure prennent des jours, parce que les estimateurs fouillent à la main les anciens projets, les chiffriers et les listes de prix des fournisseurs. Les soumissions partent en retard et les marges varient beaucoup d’un estimateur à l’autre.
Accès au domaine : l’associé du cabinet connaît la structure de coûts et les gammes de produits qui ont le plus d’écart de marge. Il présente l’occasion dans les termes qui intéressent le chef des finances : délai des soumissions et constance des marges.
Distribution : le cabinet-conseil possède la relation et propose un mandat délimité. Une firme de services TI qui soutient déjà le PGI est ajoutée pour l’accès aux systèmes.
Plateforme : le manufacturier roule déjà sur un nuage et un PGI courants. Le système les utilise au lieu d’introduire une nouvelle pile.
Livraison : une équipe d’ingénierie bâtit un assistant de soumission qui retrouve des projets passés semblables, va chercher les prix actuels des fournisseurs dans le PGI, rédige une soumission et montre à l’estimateur sur quoi elle s’appuie. Les estimateurs approuvent chaque soumission. L’équipe met en place une évaluation sur un échantillon de soumissions passées, de la surveillance et un processus de mise à niveau, puis reste pour exploiter le système.
Le système atteint la production avec quelqu’un d’imputable pour le garder fonctionnel.
Vers quoi s’en va l’écosystème de partenaires IA?
Vers un tri entre les écosystèmes qui mettent régulièrement des systèmes en production et les gardent en marche, et ceux qui n’y arrivent pas. C’est la livraison qui fera la différence.
Les grandes plateformes ont des programmes de partenaires parce que leurs propres équipes ne sont pas faites pour la livraison sur mesure dans des milliers de comptes du marché intermédiaire. Les cabinets-conseils montent des pratiques IA parce que leurs clients leur demandent sans arrêt par où commencer. Les agences sont entraînées dans le travail en IA, qu’elles l’aient prévu ou non.
Ce qui reste à voir, c’est si les firmes impliquées s’entendent sur qui fait quoi avant la première rencontre avec le client, ou après le premier incident. Notre guide de covente en IA montre comment régler la question sur un seul compte.
Questions fréquentes
Qu’est-ce que la colivraison dans un projet IA?
La colivraison, c’est quand un conseiller, une agence ou une plateforme garde la relation client pendant qu’une équipe d’ingénierie spécialisée bâtit et exploite le système IA. La propriété, le partage des revenus et les transferts sont convenus d’avance, pour que personne ne se dispute le compte.
Pourquoi un projet IA a-t-il besoin de soutien après le lancement?
Les versions de modèles changent, la qualité de la recherche documentaire dérive avec les documents, et les API en amont brisent les appels d’outils des agents. Quelqu’un doit suivre les scores d’évaluation, réviser les résultats signalés et gérer le coût par transaction, sinon le système se dégrade en quelques mois.
Comment empêcher un partenaire de livraison de prendre votre client?
Inscrivez-le dans l’entente : aucune vente directe au client que vous avez apporté, une livraison sous votre contrat si vous le souhaitez, des marges transparentes et une remise claire du compte à la fin de chaque mandat.
Avez-vous une demande en IA que vous ne pouvez pas entièrement livrer?
Si vous dirigez une pratique, une agence ou un programme de partenaires, commencez par quelque chose de concret. Apportez un défi client ou une thèse sectorielle sur laquelle vous travaillez déjà. On bâtira avec vous une offre conjointe autour de ce défi : un plan de colivraison qui précise qui possède quoi, la voie de revenus de chaque côté et à quoi pourrait ressembler l’activation d’un premier compte. Amorçons la conversation.