Fournisseur, consultant ou partenaire opérationnel en IA?

Une entreprise de taille moyenne qui prend l’IA au sérieux finit généralement par choisir entre trois types d’aide. Elle peut acheter un logiciel auprès d’un fournisseur. Elle peut engager un consultant pour lui dire quoi faire. Ou elle peut s’associer à un partenaire qui bâtit et exploite le système avec son équipe.

Vus de l’extérieur, ces modèles se ressemblent. Les fournisseurs offrent maintenant des « services d’implantation ». Les firmes-conseils ont leur « pratique de développement ». Tout le monde se dit axé sur les résultats. Les propositions se ressemblent assez pour que la décision se joue souvent sur le prix et sur la meilleure présentation.

Pourtant, les trois modèles diffèrent sur des points qui pèsent lourd sur deux ans : qui est responsable quand quelque chose brise, à qui appartient ce qui est bâti, et ce qui tient encore debout une fois le mandat terminé. Ce billet les compare sur ces critères, indique quand chacun est le bon choix et se termine par une liste de questions pour votre prochaine évaluation.

Quelle est la différence entre un fournisseur, un consultant et un partenaire opérationnel?

Le fournisseur vend un produit, le consultant vend des conseils et des livrables, et le partenaire opérationnel vend un système qui fonctionne en production. La différence se voit à l’endroit où s’arrête la responsabilité de chacun.

Un fournisseur vous vend un produit. Vous obtenez une instance configurée de son logiciel, un peu d’accompagnement au démarrage et un abonnement. Le fournisseur est responsable du bon fonctionnement du produit tel que documenté. Il n’est pas responsable de savoir s’il règle votre problème opérationnel précis.

Un consultant vous vend son expertise et son temps. En général : un diagnostic, une stratégie, une feuille de route, un dossier d’affaires et parfois un projet pour bâtir une première version. Le consultant répond de la qualité de ses conseils et des livrables prévus à l’énoncé des travaux. À la fin du mandat, l’exécution devient votre responsabilité.

Un partenaire opérationnel vous vend un résultat en production. Il travaille avec votre équipe pour cadrer un problème, bâtir le système, le déployer dans votre environnement, amener les gens à l’utiliser et rester responsable de son bon fonctionnement. Le système et le code vous appartiennent. La relation se poursuit, souvent sous forme d’abonnement ou de mandat continu, parce qu’exploiter et améliorer le système fait partie du travail.

Chaque modèle est légitime. La vraie question, c’est lequel correspond au problème que vous avez et à l’équipe dont vous disposez.

Comment les trois modèles se comparent-ils sur ce qui compte?

Ils se distinguent sur quatre points : la responsabilité, la propriété, ce qui reste à la fin du contrat et l’évolution des coûts sur environ 24 mois. Le prix au troisième mois en dit très peu.

Qui est responsable quand quelque chose brise?

Avec un fournisseur, la responsabilité s’arrête aux limites du produit. Si le logiciel fait ce que dit la documentation et que votre processus ne cadre pas, c’est un enjeu de configuration ou d’adoption de votre côté. Les bons fournisseurs donnent un coup de main, mais leur intérêt, c’est le renouvellement de la licence, pas le changement dans vos opérations.

Avec un consultant, la responsabilité s’arrête au livrable. Un mandat bien mené produit une recommandation solide et parfois un prototype fonctionnel. Que ce prototype serve au quotidien dépend de qui le reprend ensuite. Si vous avez lu pourquoi les projets pilotes IA bloquent avant que quiconque les utilise, vous reconnaîtrez ce transfert comme l’endroit où la plupart des initiatives meurent.

Avec un partenaire opérationnel, la responsabilité se prolonge en production. Le partenaire répond du fonctionnement du système dans votre environnement, avec vos données, pour vos gens. Ça change sa façon de bâtir. Surveillance, contrôles d’accès, plans de repli et formation sont prévus dès le départ, parce que c’est lui qui vivra avec les conséquences s’ils manquent.

À qui appartiennent le code et le système?

C’est la question que les acheteurs posent le moins et qu’ils regrettent le plus.

Avec un fournisseur, vous possédez vos données (vérifiez le contrat) et votre configuration. Le logiciel ne vous appartient pas. Si les prix montent, si le produit change de cap ou si le fournisseur est acquis, vos options se limitent à ce que permettent ses outils d’exportation.

Avec un consultant, la propriété dépend du contrat. Les documents de stratégie sont à vous. Le code d’une phase de développement l’est souvent aussi, mais il peut reposer sur des accélérateurs ou des cadres propriétaires de la firme, que vous obtenez sous licence sans les posséder. Lisez attentivement la clause de propriété intellectuelle (PI).

Avec un partenaire opérationnel qui fait les choses correctement, les systèmes et le code vous appartiennent entièrement. Le partenaire peut apporter une plateforme de composants réutilisables, mais ce qui est bâti pour vous roule dans votre environnement et reste chez vous si la relation prend fin. Si un partenaire ne peut pas le dire clairement, c’est un signal d’alarme.

Que reste-t-il une fois le mandat terminé?

Imaginez le lendemain de la fin du contrat, dans 18 mois.

Avec un fournisseur, il reste l’abonnement. Votre équipe sait utiliser le produit. Le savoir opérationnel sur les raisons pour lesquelles votre processus fonctionne ainsi est encore surtout dans la tête des gens, parce que le produit n’a jamais eu besoin de le capter.

Avec un consultant, il reste de la documentation et, avec un peu de chance, un prototype. Les personnes qui maîtrisaient les détails sont passées au client suivant. Votre équipe hérite d’un plan et de la tâche de le réaliser.

Avec un partenaire opérationnel, il devrait rester des systèmes en production que votre équipe utilise chaque jour, avec les flux de travail, les intégrations, les cas de test et la gouvernance qui viennent avec. Idéalement, le savoir institutionnel capté pendant le développement (les règles qui vivaient dans le chiffrier d’une seule personne) se trouve maintenant dans un système qui vous appartient. Nous avons détaillé ce qu’un mandat IA devrait laisser derrière lui.

Combien coûte chaque modèle sur 24 mois?

Nous ne mettrons pas de montants en dollars, parce qu’ils varient trop selon la portée. La forme de la courbe de coûts est plus utile que n’importe quel chiffre.

Fournisseur : faible coût d’entrée, coût récurrent prévisible. Les licences ont tendance à grimper à mesure que vous ajoutez des utilisateurs, du volume ou des modules. Les coûts cachés prennent la forme du temps interne passé à configurer, intégrer et contourner les lacunes. Sur 24 mois, le total est généralement prévisible mais monte de façon constante, et vous achetez une capacité, vous ne bâtissez pas un actif.

Consultant : un coût élevé concentré sur une courte période, puis une falaise. Les honoraires sont payés au début. Ensuite, le coût de l’exécution passe à votre équipe interne, ou à un deuxième mandat avec quelqu’un d’autre pour bâtir ce que la stratégie recommandait. Le risque : payer deux fois, une fois pour le plan et une fois pour qu’une autre équipe redécouvre les détails et le bâtisse.

Partenaire opérationnel : une première phase définie, puis un coût continu lié aux systèmes en production. Un bon point de départ est un mandat à portée fixe qui règle ou prototype un ou deux problèmes précis, pour juger les résultats avant d’aller plus loin. Ensuite, le coût passe habituellement à un abonnement ou à une provision mensuelle qui couvre la plateforme, l’exploitation et les problèmes suivants. Le pari : chaque nouveau problème coûte moins cher à régler que le précédent, parce que les flux de travail, les intégrations et le contexte des travaux antérieurs sont réutilisés.

La comparaison honnête ne porte pas sur le modèle le moins cher au troisième mois. Elle porte sur celui qui vous laisse le plus de capacité fonctionnelle par dollar au 24e mois.

Pourquoi les entreprises de taille moyenne ne peuvent-elles pas simplement confier le relais à une équipe interne?

Parce que dans la plupart d’entre elles, cette équipe n’existe pas. Les recettes des grandes entreprises supposent que des consultants conçoivent, qu’un intégrateur de systèmes bâtit et qu’une équipe IA interne ou un centre d’excellence prend le relais. Retirez la dernière étape et le transfert n’atterrit chez personne.

Regardez qui est vraiment là. Vous avez peut-être un CTO, une petite équipe TI qui fait rouler l’ERP (progiciel de gestion intégré) et le réseau, quelques développeurs et un analyste de données très fort avec Power BI. Aucun n’a de capacité libre. Aucun n’a accepté de prendre en charge un système d’IA en production, avec la dérive des modèles, les changements de requêtes et le suivi de la précision.

Bâtir cette équipe est possible, mais lent. Les profils seniors avec de l’expérience en IA de production sont rares, et une entreprise de 150 ou 400 personnes a rarement besoin d’une équipe complète à temps plein dès le premier jour. Il vous faut la capacité avant de pouvoir justifier les postes.

C’est la principale raison pour laquelle les projets IA menés par des consultants bloquent plus souvent dans les entreprises de taille moyenne que dans les grandes. Les conseils peuvent être excellents. Il n’y a simplement personne en position de les recevoir.

Le modèle de partenaire opérationnel existe pour combler ce vide. L’équipe du partenaire joue le rôle de la capacité IA que vous n’avez pas encore, intégrée aux opérateurs qui connaissent l’entreprise, jusqu’à ce que vous décidiez de bâtir cette capacité à l’interne. Si vous embauchez, le partenaire devrait vous aider à le faire et vous remettre des systèmes documentés qui vous appartiennent.

C’est encore plus vrai dans les industries traditionnelles axées sur les processus : distribution, fabrication, construction, logistique. Ces entreprises ont souvent le plus à gagner, puisqu’une grande partie de leurs opérations roule encore sur des chiffriers, des courriels et le jugement d’experts. Ce sont aussi elles qui ont le moins de capacité logicielle interne pour absorber un transfert. Nous traitons de l’IA dans les industries traditionnelles dans un billet à part.

Quand chaque modèle est-il le bon choix?

Un fournisseur pour les problèmes courants déjà réglés, un consultant quand il vous faut une décision, et un partenaire opérationnel pour les problèmes à forte valeur propres à votre façon de travailler. Il faut être juste ici : le mauvais modèle pour votre situation coûtera plus cher que n’importe lequel des trois au bon prix.

Choisissez un fournisseur quand le problème est commun à beaucoup d’entreprises et qu’un produit mature le règle déjà bien. L’automatisation des comptes fournisseurs, la transcription de réunions, l’analyse d’appels de vente et l’acheminement des billets de soutien ont tous de bons produits. Si votre processus est près du standard et que vous préférez vous adapter à l’outil plutôt que de bâtir autour de vos particularités, achetez le produit. Développer un logiciel sur mesure pour un problème déjà réglé, c’est du gaspillage.

Choisissez un consultant quand vous avez besoin d’une décision plus que d’un système. Par exemple, vous évaluez si l’IA compte dans une acquisition en cours, il vous faut une évaluation indépendante pour le conseil d’administration, ou vous voulez un portrait du marché avant d’engager un budget. Le consultant est aussi le bon choix si vous avez déjà une équipe interne compétente, prête à exécuter, et qu’il vous manque un regard externe senior pour façonner le plan.

Choisissez un partenaire opérationnel quand le problème est propre à votre façon d’opérer, que la valeur justifie un système sur mesure et que vous n’avez pas d’équipe interne capable de le bâtir et de l’exploiter. C’est le cas typique des problèmes au cœur de vos revenus : soumissions, planification, prise de commandes, documentation de conformité, répartition du service sur le terrain. C’est aussi le bon choix si vous voulez que chaque projet s’appuie sur le précédent au lieu de repartir de zéro.

Bien des entreprises finissent par utiliser les trois. Un fournisseur pour les outils standards, un consultant pour la question stratégique occasionnelle, et un partenaire pour les problèmes qui définissent leurs opérations. L’erreur, c’est d’utiliser un seul modèle pour tout.

Quelles questions poser avant de choisir?

Commencez par la responsabilité et la propriété. Les réponses d’un candidat à ces deux séries de questions vous en diront plus sur le modèle que vous achetez vraiment que sa proposition.

Sur la responsabilité

• Qui est responsable du bon fonctionnement en production six mois après la mise en service? Nommez la personne ou le rôle.
• Que se passe-t-il quand la précision baisse ou qu’un processus change? Qui s’en aperçoit, et qui corrige?
• Comment définit-on le succès : la livraison d’un document ou d’un système, ou une utilisation et des résultats mesurables dans nos opérations?

Sur la propriété

• À qui appartiennent le code, les modèles, les requêtes, les pipelines de données et les configurations que vous bâtissez pour nous?
• Est-ce que quelque chose dépend de composants que nous obtenons sous licence sans les posséder? Qu’arrive-t-il si nous mettons fin à la relation?
• Où roule le système, et qui contrôle l’accès?

Sur ce qui reste

• Qu’est-ce qui existera dans notre entreprise dans 18 mois et qui n’existe pas aujourd’hui?
• Comment le savoir opérationnel que vous captez auprès de notre équipe sera-t-il conservé, et qui pourra l’utiliser?
• Si nous rapatrions le tout à l’interne plus tard, à quoi ressemble le transfert?

Sur les gens et l’adoption

• Qui de votre équipe sera dans la pièce avec nos opérateurs, et quel est leur niveau d’expérience?
• Quel est votre plan pour que nos gens l’utilisent au quotidien, au-delà des séances de formation?
• Comment gérez-vous les personnes dont le travail change à cause de ce projet?

Sur les coûts et la structure

• Qu’est-ce qui est à portée fixe, et qu’est-ce qui est ouvert?
• Que livre la première phase, et comment jugerons-nous s’il faut continuer?
• Comment le coût évolue-t-il sur 24 mois, et qu’est-ce qui devient moins cher à mesure que nous en faisons plus?

Sur la gouvernance et l’adéquation

• Comment gérez-vous la résidence des données, la confidentialité et les exigences d’audit pour une entreprise canadienne? Notre billet sur la gouvernance de l’IA pour les entreprises canadiennes explique quoi vérifier.
• Pouvez-vous travailler en français comme en anglais, si nos équipes en ont besoin?
• Une partie de ce travail est-elle admissible aux crédits d’impôt pour la RS&DE (recherche scientifique et développement expérimental), et allez-vous nous aider à la documenter? Notre billet sur la RS&DE pour les projets d’IA explique comment ça fonctionne.

Si un candidat bafouille sur les questions de responsabilité et de propriété, vous savez ce que vous aviez besoin de savoir. Ce sont elles qui distinguent un vrai partenaire d’un fournisseur doté d’une équipe de services ou d’une firme-conseil dotée d’une pratique de développement.

Pourquoi commencer par un seul problème?

Peu importe le modèle choisi, une première phase ciblée, avec une définition claire de ce qui est terminé, vous en apprend plus sur un partenaire que n’importe quel appel de référence. Elle donne aussi à votre équipe un système fonctionnel auquel réagir, ce qui fait ressortir les vrais besoins plus vite que n’importe quel atelier.

Nous avons présenté l’argumentaire complet pour prouver la valeur de l’IA sur un seul problème, et le dossier d’affaires d’un investissement en IA explique comment présenter les chiffres à votre direction.

Questions fréquentes

Qu’est-ce qu’un partenaire opérationnel en IA?

Un partenaire opérationnel bâtit un système d’IA avec votre équipe, le déploie dans votre environnement et reste responsable de son fonctionnement en production. Le code et les systèmes vous appartiennent. La relation se poursuit généralement sous forme d’abonnement, parce qu’exploiter et améliorer le système fait partie du travail.

Est-ce moins cher d’engager un consultant en IA ou un partenaire opérationnel?

Le consultant semble souvent moins cher au départ, mais le coût d’exécution retombe sur votre équipe à la fin du mandat, et beaucoup d’entreprises paient une deuxième firme pour bâtir ce que la stratégie recommandait. Comparez la capacité fonctionnelle par dollar au 24e mois, pas la première facture.

Quand une entreprise de taille moyenne devrait-elle simplement acheter un logiciel d’IA?

Quand le problème est courant et qu’un produit mature le règle déjà, comme l’automatisation des comptes fournisseurs ou la transcription de réunions. Si votre processus est près du standard, s’adapter à l’outil vaut mieux que de bâtir un logiciel sur mesure.

Parlons-en

Chrono Innovation agit comme partenaire opérationnel pour les PME et les entreprises de taille moyenne au Canada et aux États-Unis. Une équipe senior couvre la stratégie, l’ingénierie, l’infrastructure, l’adoption et la RS&DE, et travaille avec vos opérateurs en français ou en anglais. Nous commençons par un mandat à portée fixe sur un ou deux problèmes, et tout ce que nous bâtissons vous appartient. Si vous pesez vos options, prenez rendez-vous et nous vous dirons honnêtement quel modèle convient à votre situation, même si ce n’est pas le nôtre.