Rob Collie, PDG et fondateur de P3 Adaptive et auteur de Fair Game – Série d’interviews

Rob Collie est le fondateur et PDG de P3 Adaptive, un partenaire Microsoft Solutions pour les données et l’IA qui sert des centaines de clients du mid‑market et du Fortune 1000. Ancien responsable d’ingénierie chez Microsoft sur les équipes Excel, Bing et Power BI, Rob a dirigé la vague Power BI après avoir quitté Microsoft et a écrit trois précédents livres business‑technologie (plus de 92 000 exemplaires vendus). Il anime également le podcast Raw Data with Rob Collie. Son quatrième livre, Fair Game: Customizing AI to Your Business Is Easier Than You Think (août 2026), met cette crédibilité de praticien au cœur du moment IA.

Vous avez passé plus d’une décennie chez Microsoft à aider à développer des fonctionnalités d’intelligence économique dans Excel et Power BI avant de fonder P3 Adaptive en 2013. Comment cette transition, du développement de logiciels chez Microsoft à la résolution de problèmes de données pour les clients, a‑t‑elle façonné votre vision actuelle de l’IA d’entreprise ?

Lorsque je dirigeais les équipes produit chez Microsoft, nous construisions des logiciels qui devaient fonctionner pour le monde entier et qui ne pouvaient pas être adaptés aux besoins d’un client spécifique. Nous l’appelions « commander une pizza dont les garnitures conviendraient à 300 millions de personnes ». Il y a inévitablement une ambiance de « plus bas commun dénominateur » dans ce travail, ainsi qu’une certaine distance vis‑à‑vis des clients individuels.

Il y avait un prestige certain à travailler sur cette grande scène, mais ce n’était pas aussi satisfaisant émotionnellement que d’aider des clients spécifiques à réaliser leurs ambitions uniques. En travaillant étroitement avec un client, nous avons la chance de nous investir dans son succès et d’explorer des solutions créatives qui ne tiendraient jamais dans le modèle « taille unique » des gros logiciels. C’est plus stimulant intellectuellement à bien des égards, et la connexion directe avec nos clients rend les succès beaucoup plus gratifiants.

Mais il y a aussi une plus grande responsabilité. Chez Microsoft, un seul client mécontent n’était qu’une statistique, et je balayais les plaintes chaque jour comme faisant simplement partie de mon travail. Chez P3 Adaptive, un seul client insatisfait signifie que nous avons échoué. Il n’y a pas de statistiques. Nous avons une responsabilité envers chaque relation.

J’ai appris de nombreuses choses précieuses chez Microsoft et je ne les échangerais contre rien au monde, mais je me qualifie souvent de « ingénieur logiciel en convalescence », car le succès signifie aujourd’hui fonctionner très différemment.

Et c’est exactement le prisme que j’apporte à l’IA d’entreprise. L’IA prête à l’emploi est la pizza ultime pour 300 millions de personnes – une véritable merveille, conçue pour être individuellement utile à tous tout en n’étant adaptée à personne. Mais les succès d’IA organisationnelle viendront de la personnalisation – du fait de se rapprocher d’une entreprise spécifique et d’adapter l’IA à ses données, ses processus, ses définitions. J’ai eu la chance de passer ma carrière des deux côtés de ce fossé, et cela ne fait aucun doute sur le côté qui remportera la victoire pour l’IA d’entreprise.

Dans Fair Game, vous soutenez que de nombreuses entreprises ont abordé l’intelligence artificielle à l’envers en distribuant des licences de chatbot à usage général plutôt qu’en construisant des systèmes qui comprennent leurs opérations. Jusqu’où les assistants IA prêts à l’emploi atteignent-ils leurs limites, et quels signaux indiquent qu’une entreprise a besoin de quelque chose de personnalisé ?

L’IA prête à l’emploi possède un doctorat dans tout, sauf dans votre activité. Elle a lu tout Internet, mais Internet ne contient pas la définition de votre entreprise de « client actif », votre logique tarifaire, vos processus opérationnels, ni quel de vos deux systèmes il faut privilégier lorsqu’ils divergent. Cette connaissance ne sera jamais publique. Ainsi, l’IA générique, qui excelle en usage personnel, se révèle insuffisante pour un usage professionnel, et l’écart entre les deux expériences est à la fois décourageant et déroutant.

Aujourd’hui, la réponse de presque tout le monde à la question « que faire avec l’IA » a été « acheter des abonnements et voir ce qui se passe ». Je pense que c’est une première étape naturelle, donc je ne suis pas critique envers ceux qui l’ont fait. Au contraire, je suis sympathique – personne ne prend vraiment le temps d’expliquer que les abonnements prêts à l’emploi ne suffisent pas, ni pourquoi. Ainsi, je pense que les entreprises se trouvent exactement là où nous devrions nous attendre à les voir – essayer ce qui est disponible et commencer à réaliser que cela est insuffisant.

La solution ne consiste pas à toucher le modèle d’IA lui‑même – vous n’avez pas besoin de devenir chercheur en LLM. Tout réside dans ce que vous entourez le modèle : vos données, vos instructions rédigées en anglais simple, et le logiciel habituel. Lorsque vous vous surprenez à taper le même contexte dans un chatbot pour la cinquième fois cette semaine, c’est le signal. Tout ce que vous continuez à réexpliquer est exactement ce qu’un système personnalisé devrait déjà connaître – chaque fois qu’il se réveille.

Vous utilisez le terme « Crafters » pour désigner les professionnels d’entreprise à l’aise avec les données qui peuvent créer des systèmes d’IA personnalisés sans être des développeurs logiciels traditionnels. Quelles caractéristiques distinguent un Crafter, et comment les dirigeants peuvent‑ils identifier ces personnes au sein de leurs effectifs actuels ?

Un Crafter est quelqu’un né avec l’envie de résoudre des problèmes à l’aide d’outils. Environ un travailleur du savoir sur seize en possède l’instinct, d’après mon expérience. Ils étaient les utilisateurs avancés d’Excel, puis la génération Power BI, puis les personnes que l’informatique qualifiait de « shadow IT ». Ce sont vos analystes, vos modélisateurs financiers, vos responsables des opérations – des personnes qui ont grandi dans l’entreprise et découvert un talent pour l’outillage.

Deux traits les rendent idéaux pour le travail d’IA. D’abord, la pensée systémique : ils décomposent instinctivement un processus désordonné en entrées, règles et sorties, à l’instar des développeurs logiciels professionnels. Ensuite, l’ancrage dans le métier : ils savent quels chiffres le directeur financier surveille réellement et ce que la personne qui pose une question demande vraiment. Aucun de ces deux aspects ne peut être enseigné dans un bootcamp.

Comment les repérer : suivez les feuilles de calcul. Aujourd’hui, dans votre entreprise, il existe des feuilles de calcul, des tableaux de bord et des automatisations au cœur des flux de travail critiques. Aucun d’eux n’a été créé par l’informatique, et chacun a un auteur. Commencez par là. Puis évaluez comment ils pourraient orienter leurs talents vers des solutions d’IA personnalisées.

Pourquoi pensez‑vous que les Crafters, plutôt que les seuls développeurs, sont les mieux placés pour diriger de nombreux projets d’IA internes, et comment les responsabilités devraient‑elles être réparties entre les experts métier, les équipes data, les ingénieurs logiciels, les départements informatiques et les équipes de sécurité ?

Parce que la partie difficile de l’IA personnalisée n’est pas le code – c’est le contexte. L’activité à plus fort levier dans un projet d’IA est de décider ce que le système doit savoir de votre entreprise, et les Crafters possèdent naturellement cette connaissance. Un ingénieur brillant parachuté depuis trois niveaux hiérarchiques plus loin doit mener des mois d’entretiens pour apprendre ce que votre responsable opérationnel sait déjà par réflexe.

Mais ce n’est absolument pas une histoire où les développeurs sont obsolètes. La division du travail que je recommande repose sur trois facteurs, aucun d’entre eux n’étant l’ancienneté ou la personnalité : le travail converge vers les développeurs professionnels à mesure que la réutilisabilité, la complexité et la sensibilité augmentent. Tout ce qui touche les clients, tout ce qui manipule des données sensibles, tout ce qui prend des décisions autonomes – c’est le territoire des développeurs, et à mesure que les agents se multiplient, ces compétences d’ingénierie rares deviennent plus précieuses, pas moins. Le travail converge vers les Crafters là où la nuance des processus métier domine.

Il existe également un terrain intermédiaire sous‑estimé : le Crafter construit, le développeur audite. L’informatique et la sécurité ne devraient pas être des gardiens qui approuvent les projets pour qu’ils existent – ils devraient posséder la voie pavée. Fournissez les plateformes autorisées, les règles d’accès aux données, les points de contrôle, et laissez les personnes les plus proches des problèmes faire la construction. Considérez le tout comme un modèle de maturité, pas comme une barrière.

L’IA personnalisée a besoin d’accéder à la terminologie, aux métriques, aux processus et aux connaissances institutionnelles propres à l’entreprise. Quel rôle jouent les modèles sémantiques et l’infrastructure de business intelligence existante pour offrir à l’IA une compréhension précise d’une société ?

Ce sont le « decoder ring ». Aujourd’hui, les définitions de votre entreprise – ce qui compte comme client actif, quels coûts sont inclus dans le bénéfice brut – résident dans la tête des gens et dans des milliers de feuilles de calcul légèrement incohérentes. Un agent IA ne peut pas raisonner de façon fiable sur vos données tant que ces définitions ne sont pas consignées sous une forme fiable pour une machine. L’industrie commence à appeler cette discipline « context engineering », et je traduirais le terme ainsi : c’est le travail de structurer ce que votre entreprise sait afin qu’une IA puisse réellement l’utiliser. Les analystes ont fait paraître cela comme une nouveauté. Les praticiens de la BI le font depuis quinze ans.

C’est la bonne nouvelle qui se cache à la vue de tous : si vous avez investi dans l’ère de la BI (et notamment si vous avez investi dans Power BI), vous avez peut‑être déjà une longueur d’avance. Un modèle sémantique bien construit est exactement la capture lisible par machine de la signification métier dont les agents ont besoin. Les entreprises qui ont traité leur couche sémantique comme une réflexion après coup découvrent que le travail de définition « ennuyeux » qu’elles ont sauté est maintenant le péage sur la route vers l’IA. Et, de façon cruciale, ce travail est profondément spécifique à votre activité – ce qui explique précisément pourquoi il constitue un avantage durable. Chaque fournisseur peut vous vendre le même modèle. Personne ne peut vous vendre vos propres définitions.

Vous avez créé un éditeur d’IA personnalisé, appelé Eddie, pour aider à développer Fair Game. Que faisait réellement le système pendant le processus d’écriture, et quelles leçons ses succès et échecs vous ont‑ils enseignées sur la conception d’une IA autour d’un flux de travail très personnel ?

Pour être clair, j’ai rédigé chaque paragraphe du livre à partir de zéro, tandis qu’Eddie restait principalement assis à attendre. Parfois, je passais des heures à peaufiner une section entière d’un chapitre avant de demander à « lui » de la lire. D’autres fois, je rebondissais sur lui toutes les quelques minutes. Mais surtout, Eddie était disponible 24 h/24 et 7 j/7. Je pouvais obtenir un retour aussi facilement à trois heures du matin qu’à une heure de l’après‑midi, et il le retournait en une minute ou moins. Au total, je soupçonne qu’Eddie a lu le manuscrit au moins trente fois. Aucun être humain n’aurait pu faire ce travail, car aucun être humain ne le voudrait.

Il a suivi les promesses que j’ai faites dans le chapitre trois et m’a rappelé lorsqu’elles étaient oubliées dans le chapitre douze. Il a appris mon style d’écriture puis l’a appliqué – me contraignant à la meilleure version de ma propre voix au lieu de me laisser glisser dans le mode « Auteur d’entreprise sans humour ». Il m’a indiqué quand j’étais paresseux et quand je battais le même cheval mort. Nous avons eu de réelles désaccords, et parfois il a gagné.

La plus grande leçon de conception : le « cerveau » d’Eddie est écrit en anglais et réside dans un dossier. Chaque fois qu’il donnait un retour qui manquait – trop générique, registre inapproprié, oubli d’une règle que j’avais déjà énoncée – la solution était d’écrire la correction et de l’intégrer à son contexte permanent. Les échecs n’étaient pas des échecs d’IA ; c’étaient des lacunes dans ce que j’avais pris la peine de lui enseigner. Cette boucle – remarquer l’erreur, encoder la leçon, observer son ancrage – constitue tout l’art de l’IA personnalisée en miniature. Et c’est pourquoi j’ai fini par créer des Eddie spécialisés pour la publicité, la recherche concurrentielle et les messages du site web. Même modèle LLM sous‑jacent. Mais spécialistes différents.

De nombreuses organisations pensent qu’elles doivent nettoyer et centraliser complètement leurs données avant d’essayer l’IA personnalisée. Quelle quantité de préparation des données est réellement nécessaire pour commencer, et comment les entreprises peuvent‑elles commencer à créer de la valeur sans attendre une base parfaite ?

La perfection des données n’est pas une condition préalable, et c’est une bonne nouvelle car la perfection n’arrive jamais. Si vous vous fixez comme objectif de d’abord construire un domaine de données parfait, comme le conseillent de nombreux cabinets de conseil, vous construirez ce que j’appelle « la plomberie pour elle‑même » – des tuyaux coûteux partout, mais quand vous finissez par installer un robinet, vous constatez qu’il n’y a aucun tuyau à l’endroit où vous en avez besoin.

Notre société préconise plutôt une approche « robinets d’abord ». Choisissez un cas d’usage précis et travaillez à rebours à partir de l’impact métier plutôt que d’avancer à partir de l’infrastructure. Construisez un MVP à partir de ce cas d’usage, et faites‑le avec un minimum d’infrastructure nouvelle. Itérez le MVP jusqu’à ce qu’il soit prêt pour la production, puis reculez et évaluez comment vous pourriez renforcer votre infrastructure pour le soutenir. Cela génère un impact métier plus rapidement, minimise les coûts et informe les projets futurs – tant au niveau du robinet que de la plomberie.

Un prototype d’IA personnalisée peut sembler impressionnant lors d’une démonstration mais devenir peu fiable lorsqu’il est exposé aux vrais employés, aux données changeantes et aux cas limites. Quelle évaluation, surveillance et supervision humaine devraient être mises en place avant qu’un système d’IA interne ne devienne opérationnel ?

Avec quelques exceptions notables, je pense que les démos sont moins utiles à l’ère de l’IA qu’elles ne l’étaient à l’ère du logiciel. Les démos de logiciels promettaient toujours trop et nous le savions tous. Mais les démos d’IA seront encore plus éloignées de votre réalité.

L’IA concerne le flux de travail. Et il n’y a rien de plus personnalisé que les milliers de flux qui alimentent les opérations d’une organisation spécifique. Revenez à la métaphore du « nouvel employé titulaire d’un doctorat en tout ». Combien de formation – et d’expérience pratique au sein de votre entreprise – un nouvel employé nécessite avant d’être efficace chez vous ? Comment une démo peut‑elle éventuellement tenir compte de tout cela ?

Nous utilisons donc les démos pour faire réfléchir les gens. Pour leur montrer l’art du possible. Pas pour leur vendre un produit. La vraie démo commence avec le prototype de la solution personnalisée. Le MVP. Puis nous itérons et améliorons. Rapidement.

À un moment donné, il est prêt pour un lancement en douceur ou un programme pilote. Et encore une fois, nous apprenons – ensemble – et améliorons rapidement en fonction de cet apprentissage. C’est souvent la phase où la surveillance, l’évaluation et la supervision deviennent cruciales. Les choses dont vous avez finalement besoin sont souvent très différentes de ce que vous auriez deviné au départ.

Comment les entreprises peuvent‑elles permettre aux Crafters d’expérimenter sans créer une nouvelle génération de systèmes d’IA fantômes, de flux de travail dupliqués, de vulnérabilités de sécurité et d’outils dont personne n’est responsable de la maintenance ?

Rappelez‑vous d’où vient le shadow IT : ce n’était pas de la malveillance, mais la satisfaction nécessaire d’une demande non satisfaite. Les Crafters construisent parce que les problèmes les dérangent – c’est le gène. Si le chemin autorisé signifie attendre un an, l’IA fantôme comblera le vide – et le fera sous le radar, là où c’est le plus dangereux.

Donc, faites du chemin autorisé le chemin facile. Donnez aux Crafters une plateforme approuvée avec les garde‑fous de sécurité déjà intégrés – identité, accès aux données, journalisation – afin que le choix conforme soit aussi le choix pratique. Maintenez un registre léger : tout ce qui passe de l’expérimentation personnelle à quelque chose dont dépend une seconde personne doit être consigné, avec un propriétaire nommé. Cette règle unique élimine la plupart des problèmes d’outils orphelins, car les outils avec un nom attaché ne sont pas abandonnés discrètement.

Appliquez ensuite le modèle d’escalade : les expériences restent libres, mais dès qu’une chose devient critique pour la mission – plus d’utilisateurs, plus de sensibilité, plus d’autonomie – elle gagne progressivement plus de revues d’ingénierie. Le Crafter conserve la propriété de la logique métier ; un développeur renforce ce qui doit l’être. L’objectif est un pipeline de maturité, pas un processus d’autorisation. Les entreprises ont déjà joué ce même scénario avec les feuilles de calcul, et les gagnants n’étaient pas ceux qui interdisaient Excel.

Pour une entreprise qui débute son premier projet d’IA personnalisée, comment doit‑elle choisir le cas d’usage initial, mesurer si le projet délivre une valeur métier significative, et décider s’il faut l’étendre, le redessiner ou l’abandonner ?

Nous disposons de deux approches de point de départ que nous utilisons avec nos clients.

Option un, cherchez les tâches que personne ne réalise – pas les tâches que vous aimeriez éliminer. Il y a une question que j’aime poser aux managers : « si j’avais une personne qui surveillait constamment cela et y pensait, les choses s’amélioreraient nettement – mais je ne pourrais jamais justifier l’embauche d’une telle personne », quels sont ces cas ? Ce sont souvent vos meilleurs points de départ. Ils sont sûrs, ils renforcent la confiance, personne ne se sent visé, et le contre‑factuel est honnête : l’alternative n’était pas un humain qui le faisait bien, c’était que personne ne le faisait du tout (comme mon ami éditeur Eddie).

Option deux, envisagez de remplacer les tableaux de bord par des agents de données. Aussi simples que les tableaux de bord puissent paraître, ils ne tiennent pas la promesse en pratique. Lorsqu’une personne a une question métier, il faut beaucoup travailler pour traduire cette question dans le paysage des tableaux de bord. Où se trouve le tableau de bord qui répond à cette question ? Comment s’appelle‑t‑il ? Ce tableau de bord existe‑t‑il même ? Et si vous parvenez à trouver le « bon » tableau, est‑il clair et pratique à utiliser ? Devez‑vous le manipuler à plusieurs reprises, en notant ou en capturant plusieurs versions pour assembler le tableau d’ensemble dont vous avez besoin ?

À l’ère de l’IA, vous prenez simplement votre question métier – avec vos propres mots – et vous la saisissez (ou la dictez !) à un agent de données qui gère tout cela pour vous, et vous renvoie une réponse certifiée, bien recherchée – visuels inclus – en une ou deux minutes. Lorsque vous avez une question de suivi, il répond rapidement également – lors de la réunion, pendant que les décisions peuvent encore être prises.

Le fil conducteur derrière ces deux options de départ ? Elles répondent toutes deux à des points de douleur que les employés adopteront plutôt que de résister. Vous ne voulez pas que vos premières initiatives IA suscitent la méfiance. Vous voulez qu’elles amènent les employés à la table. Vous voulez que les employés suggèrent des améliorations et de nouvelles idées de projets. Parce qu’encore une fois, votre entreprise est composée de milliers de flux de travail, et vos employés les connaissent mieux que vous.

Concernant l’extension, le redesign ou l’abandon – soyez indulgent avec vous‑même, car la recherche à ce sujet est réellement réconfortante : la plupart des déploiements IA réussis ont connu des échecs auparavant. Un premier projet qui produit une leçon plutôt qu’un gain est une formation, pas une preuve que l’IA ne fonctionne pas. Ma règle d’or : si les gens l’utilisent, étendez‑le. Si les gens ne l’utilisent pas, vous devez comprendre pourquoi, et cela peut aller d’une réponse telle que « parce qu’il ne fonctionne pas bien » à « parce que je ne le comprends pas » à « il me fait peur ». La réponse indique s’il faut améliorer, redessiner ou abandonner. Vous n’avez pas à prédire où tout cela aboutira. Vous devez simplement commencer quelque part honnêtement.

Merci pour cette excellente interview, les lecteurs devraient également lire Fair Game: Customizing AI to Your Business Is Easier Than You Think.