Équipes produit dans les entreprises d’IA : modèle et structure

Supposons qu’une entreprise de taille intermédiaire recrute trois data scientists en janvier. En juin, dix-huit demandes des métiers attendent dans leur file, et aucun modèle n’est encore en production. Le scénario est banal. Le problème ne vient pas du talent.

Une organisation produit d’IA ne se résume pas à une organisation logicielle à laquelle on aurait ajouté une équipe data science. On ne livre plus des fonctionnalités au résultat connu. On livre des modèles qui ont raison la plupart du temps, mais pas toujours. Un modèle se dégrade quand le monde change. Il dépend de données que quelqu’un doit obtenir et protéger. Et il porte des obligations que l’agile classique n’avait jamais eu à chiffrer. Si l’organisation n’en tient pas compte, chaque problème revient plus tard. Il revient sous forme de file d’attente, de données dont personne ne connaît l’origine, ou de modèle que personne n’ose valider.

Trois façons d’organiser une entreprise autour de l’IA

La plupart des organisations adoptent l’une de trois structures. Au début, beaucoup partent d’un centre d’excellence. Ce groupe central réunit les talents rares, fixe les règles communes et fait des prototypes rapides.

Vient ensuite la plateforme sous les équipes d’application. La plateforme gère les outils communs : où sont rangées les données des modèles, comment on les entraîne, le registre des versions, les tests de qualité et les contrôles automatiques. Les équipes d’application, elles, portent un problème produit de bout en bout, des tests jusqu’au résultat business.

Les grandes organisations finissent souvent par le modèle fédéré. Il a quatre pièces. Une plateforme centrale qui gère l’infrastructure et les contrôles. Des équipes par domaine métier. Des data scientists intégrés à ces équipes. Et une seule instance qui définit les indicateurs et répartit les coûts partagés.

Dans « Team Topologies » (2019), Matthew Skelton et Manuel Pais décrivent cette séparation. Des équipes centrées sur un flux de valeur s’appuient sur une équipe plateforme. Leur critère marche ici aussi : on trace la frontière selon la fréquence de changement. Ce qui bouge chaque semaine reste près de l’utilisateur. Ce qui bouge une fois par trimestre part à la plateforme.

Pour trancher vite, lisez les trois structures sur deux axes : quand les adopter, et où elles cassent.

Le point de rupture du centre d’excellence se calcule. La loi de Little (John Little, Operations Research, 1961) relie trois grandeurs. Le délai moyen égale le nombre de demandes en cours divisé par le débit.

Revenons à l’entreprise du début. Dix-huit demandes en file, une équipe qui en livre trois par mois : chaque nouvelle demande attend six mois. Si les métiers en déposent cinq par mois, la file gagne deux demandes chaque mois, et le délai s’allonge sans fin. Recruter un quatrième data scientist porte le débit à quatre, pas à cinq. La file grossit moins vite, mais elle grossit encore. C’est le moment où la direction marketing monte sa propre cellule data, hors des règles communes.

D’où une règle de passage. Quand le délai calculé dépasse un cycle budgétaire, souvent un trimestre, et qu’au moins deux métiers ont commencé à recruter de leur côté, il faut fédérer. En dessous, gardez le centre et investissez dans les règles communes. Fédérer trop tôt disperse un talent rare, et personne n’approfondit.

Chaque rôle tranche une question différente

Les produits d’IA demandent des rôles que le logiciel classique n’a pas, ou qu’il définit autrement. Quelqu’un doit répondre de la vie du modèle, des données, de l’évaluation et des contrôles. Le plus utile est de décrire chaque rôle par la question qu’il tranche quand quelque chose casse.

Le product manager IA tranche : « pourquoi ce modèle existe-t-il, et comment savons-nous qu’il marche ? ». Il pose le problème et l’hypothèse. Il vérifie que les données existent. Il fixe les critères d’évaluation et les garde-fous, c’est-à-dire les seuils que le modèle ne doit pas franchir, par exemple un taux maximal de refus à tort. Il porte le plan de tests. Et il garde la technique, la data science et le juridique alignés sur le même objectif.

Le data scientist tranche : « que peut-on apprendre de ces données ? ». Il prépare les données, teste le modèle avant sa mise en ligne et fait des prototypes assez tôt pour qu’une mauvaise idée meure avant d’avoir été promise. L’ingénieur ML tranche : « est-ce que ça tient en production, avec de vrais utilisateurs ? ». Il intègre et déploie le modèle, veille à ce qu’il réponde vite et détecte la dérive, c’est-à-dire le changement de comportement quand les données d’entrée changent. L’ingénieur MLOps fait vivre le modèle dans la durée. Il permet de le surveiller, de le réentraîner quand il le faut et de garder une trace de chaque version. Sans lui, chaque équipe réinvente ses outils et on ne peut plus comparer la qualité d’un produit à l’autre.

Le spécialiste évaluation et sécurité prépare les jeux de référence : des exemples annotés qui ne changent pas d’une version à l’autre, pour comparer honnêtement. Puis il teste le modèle contre les réponses inventées, les biais et les attaques avant la mise en production. C’est lui qui décide si une version peut sortir.

Le designer aide l’utilisateur à voir quand le modèle peut se tromper. Il affiche un niveau de confiance, des explications, des moyens simples de corriger une réponse. Surtout, il prévoit les étapes où une personne relit ou remplace ce que le système propose. Le responsable gouvernance des données répond à une question rarement écrite : d’où vient chaque donnée, et à quel titre peut-on l’utiliser ?

La relecture humaine mérite qu’on s’y arrête. Lisanne Bainbridge l’a montré dès 1983 dans « Ironies of Automation » : plus un système automatique est fiable, moins la personne qui le surveille est prête à intervenir quand il se trompe. Le règlement européen sur l’IA (règlement (UE) 2024/1689) en tire une obligation. Son article 14, paragraphe 4, point b, demande que les personnes chargées du contrôle humain restent conscientes de la tendance à se fier automatiquement aux résultats du système.

Concrètement, un relecteur qui valide 99 % des propositions ne contrôle plus rien. Suivez le taux de désaccord du relecteur. S’il approche de zéro, c’est une alerte.

Le chemin réel d’un problème jusqu’au déploiement

L’ordre du travail dépend des données disponibles et du comportement du modèle, pas seulement du backlog. Il compte huit étapes :

1. Le PM définit le problème, les hypothèses et les critères d’évaluation.
2. Le data scientist vérifie si les données sont utilisables et de bonne qualité.
3. Les ingénieurs ML construisent les prototypes.
4. Le PM et le data scientist évaluent les résultats sur des données de test, hors ligne.
5. L’équipe technique intègre le modèle au produit.
6. Le PM mène des tests avec de vrais utilisateurs, en ligne.
7. L’équipe sécurité valide la conformité.
8. MLOps déploie, surveille et réentraîne le modèle.

Ces étapes ne s’enchaînent pas une seule fois. Si l’évaluation hors ligne de l’étape 4 déçoit, on revient à l’étape 2, pas à la 5. Si le test en ligne de l’étape 6 ne bouge rien, c’est peut-être l’hypothèse de l’étape 1 qui était fausse, et non le modèle. L’équipe doit pouvoir revenir en arrière sans que cela coûte cher.

L’écart entre hors ligne et en ligne est plus grand qu’on ne le croit. Un modèle peut gagner deux points de précision sur les données de test sans rien changer au comportement des utilisateurs. Et une réponse plus lente peut effacer en ventes ce que la précision a apporté. Deux conséquences en découlent. L’étape 6 n’est jamais facultative. Et la vitesse de réponse fait partie des critères de l’étape 1, à côté de la précision.

L’évaluation n’est donc pas une phase finale, et le PM ne délègue plus la lecture des résultats. Le taux de bonnes réponses et la part de cas manqués lui disent si le modèle répond au besoin. La vitesse de réponse et le coût par inférence lui disent si la réponse est rentable. Le taux de réponses inventées et les signes de dérive lui disent combien de temps elle le restera. Les contrôles se font en continu pour la même raison : origine des données, documentation de l’entraînement, tests contre les prompts malveillants, information affichée à l’utilisateur, supervision humaine. Placés en bout de course, ces contrôles bloquent. Intégrés au travail, ils fixent la vitesse.

Ce qu’un PM doit savoir lire, pas construire

Un PM n’a pas à entraîner les modèles. Il doit savoir raisonner avec eux. Il doit comprendre dans les grandes lignes comment fonctionnent les modèles : quand ils inventent, comment on leur donne des instructions, comment ils cherchent dans des documents, comment lire leurs mesures de qualité et où sont les risques éthiques. L’article 4 du règlement européen sur l’IA en fait aussi une question juridique. Le règlement (UE) 2026/1744, dit Omnibus numérique, est entré en vigueur le 27 juillet 2026. Depuis, fournisseurs et utilisateurs professionnels doivent prendre des mesures pour aider leur personnel à maîtriser l’IA. Le texte de 2024 leur demandait d’y veiller. L’obligation s’est assouplie, mais l’attente envers le PM reste la même.

La culture des données suit le même chemin. L’équipe doit lire des tableaux de résultats et relier une dérive à un groupe d’utilisateurs avant que ceux-ci ne la ressentent. Elle teste sans cesse. Les tests hors ligne écartent les versions qui ne tiennent pas. Les tests A/B tranchent en conditions réelles. Et des indicateurs de contrôle empêchent qu’un gain à un endroit abîme le reste du produit.

Enfin, l’IA transforme une partie des coûts fixes en coûts variables, et le PM doit savoir les chiffrer. Prenons un exemple inventé. Une fonction de résumé coûte 0,004 € d’inférence par appel. À 200 000 appels par mois, cela fait 800 € HT, presque rien. Si le modèle plus précis coûte dix fois plus, la facture passe à 8 000 € HT par mois pour deux points de précision.

Ces deux points valent-ils 7 200 € par mois ? Cela dépend du coût d’une erreur, et c’est au PM de le savoir. Une fonction techniquement réussie mais qui perd de l’argent à chaque usage reste un échec produit.

Un test simple : demandez au PM pourquoi l’équipe a écarté le modèle à 94 % de précision au profit d’un modèle à 91 %. S’il parle du coût de l’erreur ou de la vitesse de réponse, les bases sont là. S’il répond « la data science l’a recommandé », elles ne le sont pas encore.

Encadrer les modèles sans bloquer les livraisons

Un cadre d’IA responsable transforme des principes en vérifications. Il donne à chaque cas d’usage un niveau de risque, et ce niveau fixe la force des contrôles. Un modèle qui recommande des articles de blog ne passe pas devant le même comité qu’un modèle qui trie des candidatures. Le règlement européen raisonne de la même façon, avec des obligations plus lourdes pour les systèmes à haut risque. La documentation des données et les journaux d’audit permettent de revoir ces décisions plus tard.

Au lieu d’évaluer chaque modèle à sa manière, les entreprises utilisent la même chaîne pour tous. Elle comprend des attaques simulées (red teaming) pour faire apparaître les failles, des jeux de référence stables et des tests hors ligne et en ligne, avant et après la mise en production. Les règles de validation disent qui signe, et sur quelles preuves. On peut alors comparer la sécurité de tous les modèles.

Les contrôles ne s’arrêtent pas au lancement. Chaque modèle est enregistré et surveillé. Il est réentraîné selon un calendrier fixé à l’avance, pas au moment où quelqu’un remarque un problème. Et un jour, il est retiré de façon documentée. Combien cela coûte-t-il ? Prenons vingt modèles en production et une revue de trente minutes par modèle tous les quinze jours. Cela fait vingt heures par mois, moins de trois jours de travail. C’est peu, comparé à un modèle oublié qui continue de décider.

Faut-il vraiment une plateforme quand on a un seul produit ?

Les petites structures posent la question autrement. Une scale-up avec un produit, un modèle et six ingénieurs n’a que faire d’une équipe plateforme, d’un comité de risque et d’une réunion tous les quinze jours. Ce serait copier l’organigramme d’un groupe du CAC 40 sans en avoir les problèmes. Sur un point, elles ont raison. Avec un seul produit, une seule équipe mixte, où le même ingénieur fait le ML et le MLOps, livre plus vite que n’importe quelle structure. Monter une plateforme avant d’avoir une deuxième équipe produit, c’est payer de la coordination sans rien à coordonner.

La responsabilité, elle, ne diminue pas avec la taille. Une start-up de dix personnes dont le modèle classe des candidatures ou fixe des prix a les mêmes obligations qu’un grand groupe. La version minimale tient sur une page. Un responsable nommé par modèle. La version et les données d’entrée enregistrées pour chaque décision importante. Et une procédure de recours. Le reste peut attendre la deuxième équipe.

Faire travailler ensemble PM, data science et ingénierie

Le travail commun commence plus tôt que dans une équipe logicielle classique. Le data scientist participe à la phase de découverte pendant que le problème se pose encore. Le PM fixe les critères d’évaluation avant qu’un modèle existe. Ainsi, ce qui est faisable et ce qui compte comme un succès sont posés dès le départ. Ensuite, les ingénieurs ML transforment les prototypes en versions de production, les designers conçoivent les explications et MLOps garde le système sous surveillance. Faire travailler les quatre métiers en même temps, plutôt qu’en relais, évite des malentendus et raccourcit chaque cycle.

Une feuille de route IA se construit par couches de capacités plutôt que par versions. Que doivent supporter les circuits de données ? Comment les modèles vont-ils évoluer ? Quelles dépendances envers la plateforme conditionnent le travail ? Le coût d’inférence et la vitesse de réponse y figurent, car ils disent ce qui est réaliste avant toute conception. Et comme un modèle ne promet pas un résultat fixe, la façon de communiquer change. La direction a besoin d’une fourchette de comportement attendu et de scénarios de risque. Une date assortie d’un chiffre exact promet ce que le modèle ne peut garantir.

Trois indicateurs suffisent pour savoir si l’organisation fonctionne. Le délai moyen dans la file IA, à garder sous un cycle budgétaire. La part de modèles en production avec un responsable nommé, qui doit être de 100 %. Et le délai de réponse à une demande de recours. Le garde-fou est le coût d’inférence par utilisateur actif. S’il monte trimestre après trimestre pendant que la file se vide, la fédération achète de la vitesse avec de la marge.

La topologie avant les recrutements

L’ordre des étapes compte plus que n’importe quel choix isolé. Mettez-vous d’accord sur le modèle opérationnel avant d’augmenter les effectifs : qui gère la plateforme, comment fonctionnent les contrôles, quels indicateurs sont définis au centre. Réorganiser après coup coûte bien plus cher qu’un plan de recrutement pensé pour s’y adapter. La mesure passe avant la structure. D’abord, des définitions communes pour l’évaluation et les coûts, afin que chaque équipe mesure avec la même règle. Ensuite, des briques partagées, sorties de l’équipe la plus débordée. Et seulement à la fin, les liens hiérarchiques.

Une file de plus d’un trimestre est le signal le plus simple à lire. Elle se calcule en cinq minutes avec la loi de Little. Faites ce calcul avant la prochaine embauche.