L’IA s’invite partout : assistants intelligents, automatisation de tâches, recommandations personnalisées… Chaque organisation explore comment l’intégrer dans ses produits.
Mais derrière l’excitation, une question émerge : qui pilote quoi dans l’IA entre Produit, Data et Tech ?
Les frontières traditionnelles se brouillent. Et sans clarification, le risque est simple : tout le monde parle d’IA, mais personne n’en prend vraiment la responsabilité.
Produit, Data, Tech : trois regards sur l’IA
Dans les faits, l’IA touche aux trois métiers — mais avec des angles radicalement différents :
- Produit : l’IA doit servir la valeur utilisateur et le business. Le PM est légitime pour poser la question du “pourquoi” et du “pour qui”. Exemple : chez un acteur du e-commerce, le PM oriente le choix entre un moteur de recommandation “poussé par la marge” ou “poussé par la personnalisation client”.
- Data : l’IA repose sur des modèles, des données et une gouvernance. Les équipes data en garantissent la qualité et les biais éventuels. Exemple : dans la santé, un modèle de diagnostic doit couvrir toutes les populations pour ne pas reproduire des biais discriminants.
- Tech : sans infrastructure, intégration ni scalabilité, un modèle IA reste une démo. Exemple : un chatbot peut fonctionner en POC, mais devenir inutilisable si les temps de réponse explosent une fois intégré à l’appli mobile.
👉 Résultat : chacun a une part du sujet, mais si les rôles ne sont pas clarifiés, l’IA devient un terrain de lutte d’influence.
Nouveaux rôles, nouvelles tensions
Certaines entreprises créent de nouveaux métiers : AI PM, Data PO, ou encore des équipes IA transverses.
Mais là encore, deux risques :
- Multiplier les rôles → complexité accrue, lenteur dans les décisions. Plusieurs scale-ups ont vu leur chaîne de validation IA nécessiter quatre interlocuteurs avant de lancer une simple expérimentation.
- Créer un silo IA → une équipe à part qui avance sans lien réel avec le produit. Chez certains grands groupes, les “labs IA” livrent des prototypes brillants… mais jamais utilisés par les utilisateurs finaux.
L’exemple de Builder.ai est révélateur. Présentée comme une plateforme “IA first” permettant de développer des applications aussi simplement qu’on commande une pizza, la start-up s’est en réalité appuyée sur 700 développeurs humains derrière son IA “Natasha”. Résultat : faillite en 2025 et énorme désillusion (source : Medium).
👉 Quand la communication IA est déconnectée du Produit et de la Tech, on fragilise toute l’organisation.
D’autres entreprises choisissent d’intégrer des experts IA dans les squads existants.
Avantage : plus de proximité avec les problématiques utilisateur (ex : un data scientist dans une squad marketing affine un modèle de scoring en temps réel).
Inconvénient : rareté des compétences et arbitrages difficiles, surtout si un même expert doit naviguer entre plusieurs squads.
Structurer les responsabilités : quelques repères
Dans les organisations qui tiennent la route, on observe des schémas relativement clairs :
- Le PM reste garant de la valeur, des priorités et de l’impact business.
- La Data porte la responsabilité des modèles, de la qualité et des risques (biais, éthique, conformité réglementaire).
- La Tech assure la robustesse, la scalabilité et l’intégration.
- Et surtout : un cadre de gouvernance clair → rituels de décision, sponsors identifiés, critères de succès partagés.
C’est ce qu’a expérimenté Bpifrance – Le Hub, en structurant des équipes dédiées aux “IA features” directement intégrées aux squads. Le principe : un Product Requirements Document (PRD) co-rédigé à trois voix (Produit, Data, Tech) et des roadmaps partagées avec le framework Now / Next / Later. Résultat : des arbitrages plus rapides et une intégration fluide dans les cycles Produit (source : Le Hub Bpifrance).
Éviter la désorganisation : trois leviers
- Ne pas créer un silo IA Intégrer autant que possible les enjeux IA dans les process Produit existants : discovery, cadrage, delivery. Exemple : intégrer un “check IA” dans les templates de discovery pour challenger chaque nouvelle fonctionnalité.
- Acculturer les PM Pas besoin qu’ils deviennent data scientists, mais comprendre les bases leur permet de challenger et d’orienter. Exemple : savoir ce qu’est l’overfitting ou la différence entre un modèle supervisé et non supervisé suffit pour éviter les faux débats.
- Adapter selon la maturité Une scale-up et un grand groupe n’auront pas la même approche.
- Une scale-up pourra tester vite (A/B tester un moteur de reco sur un segment).
- Un grand groupe devra cadrer davantage (sécurité, RGPD, conformité).
À noter : le modèle de l’AI factory, une structure centralisée regroupant talents et méthodes – peut accélérer la production IA, à condition de rester connectée aux squads Produit. Sinon, elle risque de devenir un “lab IA” coupé du terrain.
Conclusion
L’IA n’est pas seulement un sujet technologique : c’est un révélateur de maturité organisationnelle.
Elle oblige les équipes Produit, Data et Tech à clarifier leurs responsabilités, à collaborer davantage et à éviter les “territoires gris” où les décisions se perdent.
Pas de recette unique, mais une conviction : la valeur IA naît quand chacun connaît son rôle et qu’un cadre clair permet de décider vite et bien.
Cet article vous a plus, découvrez Comment se lancer dans l’utilisation de l’IA en tant que Product Manager et IA Générative & RAG : Comment passer de l’idée au POC en quelques minutes.
