Repenser le modèle opérationnel produit, IT, data et IA

Avant-propos

Ce document décrit le terrain où évoluent aujourd’hui ceux qui pilotent la donnée et l’IA (CDAIO, Head of AI), la technologie (CTO), le produit (CPO, Head of Product) et les portefeuilles d’initiatives (PMO). Il en dresse l’état des lieux en croisant trois sources : ce que publient les grands cabinets de conseil depuis dix-huit mois (McKinsey, BCG, Gartner), ce qu’impose la réglementation européenne, et ce que nous observons nous-mêmes.

Le règlement européen sur l’IA devait imposer une série d’obligations contraignantes aux systèmes à haut risque dès le 2 août 2026. En mai 2026, l’Union européenne a repoussé l’échéance à décembre 2027 : ni les États ni les entreprises n’étaient prêts. Seule la date a bougé, parce que personne n’avait la couche opérationnelle qui permet de prouver la conformité au quotidien. La Partie 2 revient sur cette couche.

La lecture demande une quarantaine de minutes. Chaque donnée avancée est sourcée, et l’ensemble des références figure en Annexe A : McKinsey, BCG, Gartner, PwC, WEF, RAND, Silicon Valley Product Group et Product Talk.

Synthèse

1. Produit, IT, data et IA convergent dans un même modèle opérationnel, intégré et piloté par la valeur. McKinsey publie son cadre « agentic organization » en 2025, BCG son AI Radar l’année suivante, et Gartner rebaptise le « Project & Portfolio Management » en « Strategic Portfolio Management ». Les trois aboutissent à la même conclusion.

2. Le report du règlement européen sur l’IA est un signal. Le règlement devait s’appliquer aux systèmes à haut risque le 2 août 2026. En mai 2026, l’Union européenne a acté un report à décembre 2027, faute de mise en œuvre prête, côté États comme côté entreprises. Registre européen, évaluation de conformité, supervision humaine, gouvernance des données : les obligations sont intactes, seule l’échéance a glissé. Et prouver cette conformité demandera autre chose qu’un PowerPoint.

3. L’écart entre adoption et valeur est massif. 80 % des projets IA n’ont pas livré la valeur attendue en 2025 (RAND). 88 % des organisations utilisent l’IA, mais 39 % seulement voient un effet sur leur résultat d’exploitation (McKinsey).

4. Le diagnostic se résume à trois symptômes connus. Feature factory, prédominance d’Excel, test des trois PMs : aucun n’est nouveau, et dix ans d’agilité, de SAFe ou d’OKR n’en sont pas venus à bout.

5. Les cadres de gouvernance IA s’arrêtent avant les équipes produit. La plupart des cadres de gouvernance IA en 2026 décrivent un AI Office, un cycle de vie et un risk playbook. Très peu disent comment ce cadre se traduit dans le travail des équipes produit. C’est pourtant là que se trouve l’essentiel du travail.

6. L’architecture qui fonctionne repose sur quatre couches. Ces couches (bet, opportunité, initiative, expérimentation) se logent dans trois conteneurs (workspace, portefeuille, produit) et se lisent à travers trois prismes (PM, PMO, CDAIO). Une seule saisie alimente trois calculs.

7. Déléguer à des agents suppose un modèle opérationnel explicite. Un agent sait lire un tableur. Il n’y trouve ni règle, ni limite, ni endroit où rendre compte de ce qu’il a fait. Les entreprises qui laissent leur stratégie dans des slides et des fichiers ne pourront rien lui confier. Celles qui l’auront inscrite dans un système arbitreront en continu ce que les autres arbitrent une fois par an.

La convergence produit, IT, data et IA

Produit, IT, data et IA formaient quatre métiers séparés. Ils forment aujourd’hui un seul modèle opérationnel. Les entreprises qui les pilotent encore séparément ne peuvent pas comparer leurs initiatives entre elles. À chaque comité, elles reconstruisent à la main une vue que personne ne partage.

Le mouvement est déjà engagé. Il se lit dans la recomposition des postes de direction, dans la réorganisation du marché du logiciel, et dans ce que publient les grands cabinets depuis dix-huit mois.

L’IA ne peut plus être un chantier à part

Une organisation ne peut plus traiter l’IA comme un chantier à part. Dès qu’un modèle entre en production, il touche en même temps le produit, les processus, les équipes et la donnée. Quatre équipes qui décident chacune dans leur coin produisent quatre versions de la même priorité.

Le problème apparaît au moment de l’arbitrage. Le produit défend sa roadmap, l’IT défend sa capacité, la data défend ses cas d’usage. Chacun a raison dans son périmètre. Personne ne peut dire lequel des trois sert le mieux la stratégie, faute d’une unité de mesure commune.

McKinsey décrit le même phénomène dans The Agentic Organization (septembre 2025). Le cabinet distingue cinq piliers : le business model, le modèle opérationnel, la gouvernance, les talents et la culture, enfin les technologies et la donnée. Il refuse qu’on les lise en silos : les cinq forment les facettes d’un même système.

L’essentiel du travail est organisationnel

Dans une transformation IA, la technique est la partie la plus simple. La réussite ou l’échec se décident ailleurs.

Beaucoup de modèles marchent en test et ne passent jamais en production. Il faut décider qui porte le cas d’usage, quel processus change, qui valide le résultat, et ce que devient le travail des équipes concernées. Aucune de ces décisions n’est technique, et chacune peut tout arrêter.

BCG aboutit au même constat dans son AI Radar 2026 : une transformation par l’IA ne réussit qu’arrimée à la stratégie, inscrite dans des processus repensés et menée jusqu’à l’échelle.

Son cadre 10-20-70 répartit l’effort sans ambiguïté : 10 % pour l’algorithme, 20 % pour les technologies et la donnée, 70 % pour les personnes et les processus. Ces 70 % portent sur l’organisation du travail, pas sur le modèle de machine learning.

Du projet au portefeuille

La question posée à un portefeuille a changé. Hier, on demandait si les projets sortaient dans les temps. Aujourd’hui, on demande si l’entreprise fait les bons paris. Le marché du logiciel a acté ce basculement avant beaucoup d’entreprises.

Ce basculement change le métier du PMO. Suivre des délais produit un tableau d’avancement. Suivre des paris oblige à dire quels paris sont invalidés par les faits, et donc quelles initiatives on arrête. Arrêter une initiative demande une autorité que le suivi de délais n’a jamais eu à réclamer.

Le signal le plus net vient de Gartner. La catégorie historique du « Project & Portfolio Management » a été officiellement rebaptisée « Strategic Portfolio Management » (SPM), transition que formalisent le Magic Quadrant 2025 et l’infographie 2026.

Le marché épouse le mouvement. Planview, ServiceNow, Planisware et six autres éditeurs sont désormais jugés sur leur capacité à réunir dans une seule plateforme des portefeuilles interdépendants, la modélisation de la stratégie et l’exécution opérationnelle.

Une seule autorité sur la data et l’IA

Les organigrammes bougent dans le même sens. La fonction de Chief Data, Analytics and AI Officer (CDAIO) absorbe peu à peu des rôles jusque-là dispersés : Chief Data Officer, CTO data, responsable de l’IA. On ne gouverne pas la donnée sans gouverner l’IA qui s’en nourrit, ni l’IA sans gouverner les produits qui l’incorporent. Tout se consolide par le haut. Cette consolidation ne se fait pas partout au même endroit : selon les organisations, l’IA relève d’un Head of AI rattaché au CTO ou d’un CDAIO de plein exercice. Quel que soit le titulaire du poste, ces responsabilités doivent se lire dans un même système.

Ce que ces quatre signaux ont en commun

Ces cabinets se concurrencent, et les éditeurs de logiciels ne se concertent pas avec eux. Ils dessinent pourtant le même modèle opérationnel.

• Une gouvernance intégrée (McKinsey) qui couvre business model, opérations, talents, data et IA.
• Un effort centré sur les personnes et les processus (BCG, 70 % de l’effort), et non sur l’algorithme.
• Un portefeuille stratégique unifié (Gartner SPM) qui se substitue aux PPMs en silos.
• Un leadership consolidé (CDAIO) qui couvre data, analytics et IA, et qui doit articuler ce périmètre avec le produit et l’IT.

Réglementation, valeur, agents

Trois forces rendent aujourd’hui l’attentisme coûteux : la réglementation européenne, l’écart persistant entre adoption et valeur, la bascule vers les agents. Aucune de ces trois forces n’est nouvelle. Elles convergent pour la première fois sur le même calendrier.

Le calendrier réglementaire. L’échéance a glissé de seize mois

Le règlement européen sur l’IA (EU AI Act, 2024/1689) entre en vigueur par paliers. Le palier qui devait peser sur la plupart des entreprises était fixé au 2 août 2026 : à cette date, les systèmes à haut risque devaient respecter une série d’obligations contraignantes, de l’enregistrement au registre européen à l’évaluation de conformité, en passant par la gestion des risques, la gouvernance des données, la journalisation, la supervision humaine et la transparence.

Cette échéance a bougé. En novembre 2025, la Commission dépose le Digital Omnibus on AI pour amender le règlement ; après l’échec d’un premier trilogue le 28 avril, un accord politique est trouvé début mai 2026, que le Conseil confirme le 13. Les systèmes à haut risque autonomes (Annexe III) basculent au 2 décembre 2027, ceux qui sont embarqués dans des produits régulés (Annexe I) au 2 août 2028. Soit seize mois de décalage sur le palier principal.

À l’heure où nous écrivons (juin 2026), cet accord reste en cours d’adoption formelle : tant qu’il n’est pas publié au Journal officiel, c’est le texte initial qui fait foi, et donc le 2 août 2026. Les équipes conformité planifient pour la plupart sur décembre 2027, mais la bascule juridique n’est pas encore actée. Tout n’est pas reporté non plus : certaines obligations de transparence pesant sur les déployeurs restent dues au 2 août 2026, tandis que le marquage des contenus générés est repoussé à décembre 2026.

L’Union européenne n’a pas reculé sur le fond. Elle a constaté que la mise en œuvre n’était pas prête : des normes inachevées, des autorités nationales pas toutes désignées, des entreprises en retard. Seule la date a glissé. Les éditeurs comme les entreprises n’avaient pas produit à temps la couche opérationnelle que ces obligations supposent.

Les amendes, en revanche, n’ont pas varié, et restent calibrées pour que le sujet remonte jusqu’au comex : jusqu’à 35 M€ ou 7 % du chiffre d’affaires au niveau mondial pour les pratiques interdites, jusqu’à 15 M€ ou 3 % pour le non-respect des obligations attachées aux systèmes à haut risque.

Ce que ce report change concrètement. Seize mois de plus ne modifient pas la nature du travail. Un AI Office documenté en PowerPoint ne tiendra pas devant le régulateur, le client interne ou le comité d’audit. Tous réclameront des preuves : une validation tracée pour chaque cas d’usage à haut risque, une supervision documentée en production, une évaluation de conformité consultable à tout moment. C’est un travail de portefeuille, et les seize mois gagnés ne profiteront qu’aux entreprises qui les consacrent à ce travail.

L’écart entre adoption et valeur

La majorité des investissements dans l’IA n’a pas tenu ses promesses de valeur. Trois études récentes le chiffrent.

L’IA fonctionne, mais l’organisation qui l’entoure ne suit pas le rythme. Ce que McKinsey et BCG rangent sous l’étiquette « people and processes » désigne précisément ce qui fait défaut entre le pilote et la production.

Ces chiffres datent d’avant la généralisation des agents. Un système qui décide et agit en boucle creusera cet écart de 49 points chez les entreprises qui n’ont pas de modèle opérationnel pour l’encadrer. Il le refermera chez celles qui en ont un.

Ce que les agents changent

Jusqu’en 2024, l’IA en entreprise restait surtout prédictive, avec ses modèles, et générative, avec ses assistants. En 2025 et 2026, le centre de gravité se déplace vers l’agentique : des systèmes qui décident, déclenchent des actions et opèrent en boucle.

McKinsey en fait le titre de son rapport, The Agentic Organization ; BCG y voit le changement majeur de la décennie. Ce saut soulève surtout des questions d’organisation. Qui supervise un agent qui décide ? Qui en porte la responsabilité ? Qui en mesure la valeur ?

Toutes ces questions relèvent du modèle opérationnel. Aucune ne se tranche au niveau de l’algorithme.

Un agent sait lire un tableur ou une présentation. Il n’y trouve pourtant pas de quoi agir : aucun identifiant stable, aucun état défini, aucune règle qui dise ce qu’il a le droit de déclencher, aucun endroit où inscrire ce qu’il a fait. Déléguer à des agents suppose que les paris, les limites et les responsabilités vivent dans un système, avec une adresse et une trace. Ce prérequis est l’objet des parties 5 à 7.

Trois symptômes que l’on retrouve partout

Trois symptômes reviennent presque partout, côté produit comme côté IT ou data. On les décrit depuis dix ans, et ils dominent encore en 2026.

Symptôme 1. Le test des trois PMs

Le test est volontairement simple. Réunissez trois product managers de la même organisation, la même semaine, sans préparation. Demandez à chacun sur quoi l’entreprise parie ce trimestre. Comparez les réponses.

Si elles divergent, il n’y a pas de stratégie, seulement trois interprétations. Une stratégie que les équipes ne savent pas restituer n’est qu’un document que personne ne porte.

Le test se transpose aux directions techniques. Posez la même question à trois engineering managers : les réponses divergent autant.

Symptôme 2. La feature factory

Le terme est de Marty Cagan, présent dès Inspired (2017), puis Empowered (2020) et Transformed (2024). Une feature factory mesure sa réussite au nombre de story points livrés, jamais à des indicateurs métier qui évoluent.

Le schéma se reconnaît au premier coup d’œil : la roadmap s’empile au fil des demandes, personne ne formule d’hypothèse qu’on pourrait invalider, et l’expérimentation reste l’exception.

Côté IA, la feature factory prend un tour particulier : un pipeline de cas d’usage qui s’empilent, « on en a quarante-sept dans le backlog », sans hiérarchie claire entre ce qui change la donne pour le métier et ce qui relève de la curiosité technique.

Symptôme 3. La prédominance d’Excel

Dans la grande majorité des organisations que nous accompagnons, il existe un fichier Excel, tenu par le PMO, le CDAIO ou un consultant. Ce fichier est la véritable source de vérité du portefeuille, et chacun le sait. Le comex s’y réfère, les revues mensuelles le projettent.

Ce fichier n’est pas un système : pas d’auditabilité, pas d’historique fiable, et une collaboration qui se résume à un envoi par mail. C’est une œuvre personnelle, qui s’effondre le jour où son auteur quitte l’entreprise.

L’Excel qui fait foi est un pansement. Il comble le vide laissé par l’absence d’un système logiciel dédié. Le retirer trop tôt installe le chaos. Le garder trop longtemps fait reposer tout le portefeuille sur une seule personne. Il faut lui substituer une plateforme qui couvre les mêmes usages tout en apportant ce qui manque : l’auditabilité, la collaboration, l’historique.

Les trois symptômes se renforcent l’un l’autre

Un symptôme seul se soigne. Les trois ensemble s’alimentent : faute de stratégie réelle, le produit livre en feature factory, et la seule vue d’ensemble disponible vit dans un Excel. Un operating system de portefeuille doit défaire ce nœud. Il rend d’abord le diagnostic visible, puis il outille un autre mode de travail.

Ce que les cadres de gouvernance IA ne couvrent pas

La plupart des grandes entreprises françaises ont déjà déployé, ou déploient en 2026, un cadre de gouvernance de l’IA. Les schémas circulent, produits par les directions internes, les cabinets de conseil ou les éditeurs. La forme varie de l’un à l’autre ; la structure, elle, converge.

Nous l’avons redessinée (Figure 1) pour séparer ce qui fonctionne de ce qui manque.

La structure typique

Au sommet, la gouvernance IA compte trois briques : le cadre de gouvernance (principes, politiques, risques, éthique), le modèle opérationnel (comités, articulation avec l’IT et les risques) et l’AI Office, qui assure le pilotage, la design authority et les relais métiers.

Au centre se trouve l’AI Factory, organisée en six phases : découvrir, concevoir, développer, valider, déployer, exploiter. Un risk playbook traverse l’ensemble du cycle, sur un socle commun (données, outils, infrastructure).

En bas figurent cinq à six axes stratégiques : alignement, maîtrise des risques, industrialisation, collaboration, mesure de la valeur, apprentissage continu.

Ses points forts

• La gouvernance comme couche distincte. Sans cette couche, la conformité EU AI Act ne tient pas.
• Le cycle de vie structuré en phases. C’est le seul moyen connu de passer du pilote à l’échelle.
• L’AI Office érigé en rôle à part entière, et non en simple cellule virtuelle. Un rôle nommé et doté fait tenir la cohérence entre les directions.

Beaucoup d’entreprises ne réunissent pas encore ces trois éléments. Les réunir est déjà une avancée.

Ses angles morts

Trois absences ressortent, par ordre de gravité.

Le pont vers les équipes produit. Ce schéma traite l’IA comme un monde à part. Or les produits modernes mêlent IA et hors-IA. Un cas d’usage ne vaut que s’il aboutit dans un produit, porté par une équipe et jugé sur les résultats obtenus. Le pont entre l’AI Office et les PM n’est presque jamais tracé ; il se construit alors au cas par cas, au gré des bonnes volontés. Le même pont manque côté ingénierie. Les agents mis en production agiront dans des systèmes dont le CTO a la charge, et ce schéma type ne dit pas où son autorité rencontre celle de l’AI Office.

Ce qui définit un bet. Dans notre vocabulaire, un bet est un pari stratégique. C’est un résultat métier clair et daté, qu’une équipe se donne les moyens d’atteindre, et qu’elle accepte de voir contredit par les faits. Ce schéma type parle de cas d’usage, sans jamais dire ce qui sépare un bon bet du bruit : aucun test pour vérifier qu’une hypothèse peut être contredite, aucun test des trois PM, aucun cadrage des résultats attendus. Le risk playbook est fourni ; le value playbook, lui, manque à l’appel.

La watchtower en PowerPoint ou Excel. La watchtower figure bien comme couche d’observabilité et de pilotage de la valeur, mais elle vit le plus souvent en slide ou en fichier Excel isolé, pas en code. Un mardi matin à neuf heures, personne ne peut dire où en sont les quarante-sept cas d’usage du portefeuille, lesquels sont à risque, lesquels créent de la valeur, lesquels dérivent : cette vue n’existe qu’en slide.

Comment s’en servir

Ce schéma type est incomplet. La couche gouvernance est solide. La couche industrialisation reste approximative. La couche opérationnelle est oubliée, alors que l’essentiel du travail s’y joue.

Gardez la couche gouvernance telle quelle, elle fait son travail. Construisez la couche opérationnelle à côté, sans attendre que le cadre de gouvernance la prévoie.

Produit et IA dans une même architecture

Cette architecture repose sur quatre couches d’objets, trois conteneurs et une source de vérité unique. Tout le travail décrit dans le cadre de gouvernance précédent passe par ces objets. Aucun n’est inventé ici : chacun est emprunté à des travaux publiés, côté produit comme côté IA. Notre apport est leur articulation.

Les quatre couches

Cette architecture prolonge un strategy stack que nous avons proposé précédemment. Les trois couches d’origine, « the bet, the structure, what we ship », deviennent quatre, afin de distinguer explicitement l’initiative de l’expérimentation.

Les quatre couches se lisent de haut en bas, du stratégique à l’opérationnel.

• BET (« pari »). Une affirmation stratégique mesurable, datée et formulée pour que les faits puissent la contredire. Un bet désigne ce que l’on croit assez fort pour y engager des moyens, en acceptant à l’avance que les résultats puissent montrer qu’on avait tort. Sans bet, il n’y a pas de stratégie, seulement un budget.
• OPPORTUNITÉ. Besoin client, problème ou levier métier qui contribue au bet. La notion vient de l’Opportunity Solution Tree de Teresa Torres (Continuous Discovery Habits, 2021).
• INITIATIVE. Solution explorée pour répondre à une ou plusieurs opportunités. C’est l’objet que les PM et les équipes de développement portent au quotidien.
• EXPÉRIMENTATION. Test concret d’une hypothèse de l’initiative. L’expérimentation peut réussir, échouer ou rester ambiguë. C’est le seul niveau où l’invalidation est explicitement acceptée.

Les trois conteneurs

Au-dessus des couches, trois conteneurs situent chaque objet dans l’organisation.

• Workspace. L’organisation entière. Un seul workspace par entreprise.
• Portefeuille. Un regroupement cohérent par BU, marché ou mission.
• Produit. Une équipe et un périmètre. C’est ici que se logent les bets.

Les bets se placent au niveau du produit. Pas au portefeuille, trop large ; pas à l’initiative, trop étroite. Cette règle simple tranche la plupart des désaccords sur le niveau où loger un bet.

Pourquoi cette architecture convient aussi à l’IA

Le cas d’usage IA évoqué en Partie 4 n’introduit aucun objet nouveau dans cette architecture : c’est une initiative. Il aboutit dans un produit, sert un bet, répond à une opportunité et se valide par des expérimentations.

Cette homogénéité a deux conséquences pratiques.

• Les équipes produit et les équipes data ou IA travaillent avec le même langage. Plus rien à traduire d’un système à l’autre.
• Le portefeuille total (initiatives produit et cas d’usage IA) devient visible dans une seule vue. Le comex arbitre sur la même grille pour tout.

Une troisième conséquence apparaît à mesure que les agents passent du statut d’initiative à celui d’exécutant. Un agent qui agit doit savoir sur quel bet il travaille et quelles limites il ne franchit pas. Il doit aussi pouvoir inscrire quelque part ce qu’il a fait. Les quatre couches lui donnent ces repères. Le système qui aligne les équipes aujourd’hui devient l’environnement de travail des agents demain.

Trois lectures d’un même portefeuille

La Partie 5 a posé la structure. Reste à savoir qui regarde quoi, et avec quelle préoccupation en tête. Une source de vérité unique se lit à travers trois prismes. Ces prismes ne traduisent pas la donnée, ils éclairent les mêmes objets sous trois angles.

Les trois rôles

• Le Product Manager (« Eva ») dirige une équipe produit. Sa question quotidienne : « qu’apprend-on cette semaine ? ». Son prisme montre l’Opportunity Solution Tree, les expérimentations en cours, les résultats par opportunité, le calendrier d’expérimentation.
• Le responsable du PMO (« Pierre ») orchestre le portefeuille. Sa question : « tient-on la trajectoire promise ? ». Son prisme montre les initiatives par phase, les dépendances, la capacité, les jalons, l’écart entre trajectoire et engagement.
• Le CDAIO (« Sarah ») chapeaute la stratégie data et IA. Sa question : « quels cas d’usage créent de la valeur, lesquels divergent ? ». Son prisme montre la watchtower IA : cas d’usage par phase, qualité des données, drift, conformité EU AI Act, valeur captée.

Pourquoi trois prismes plutôt qu’une vue universelle

L’idée d’une vue universelle séduit, mais elle échoue à chaque tentative. Le PM la juge trop large, le PMO trop superficielle, le CDAIO trop centrée sur le produit. C’est le prisme qui rend la donnée exploitable : sans lui, elle est juste, mais ne sert à personne.

Prenons un même bet. Côté PM, ce sont les hypothèses à tester qui ressortent ; côté PMO, les ressources à mobiliser ; côté CDAIO, le risque du modèle et la valeur captée.

La règle d’or. Aucune donnée saisie deux fois

Si une équipe doit ressaisir la même information pour alimenter un autre prisme, l’architecture a échoué. La saisie est unique, le prisme calcule. Cette règle d’apparence anodine vient à bout de l’Excel qui fait foi, bien mieux que n’importe quelle fonctionnalité.

Une watchtower en production

La watchtower est la promesse la plus ambitieuse du schéma type de gouvernance IA, et c’est aussi celle qui reste le plus souvent à l’état de slide ou de fichier Excel isolé. Une watchtower qui fonctionne est un logiciel qui tourne. Il est alimenté par les données du portefeuille, et il est à jour sans que personne ait à le reconstruire.

Quatre couches d’observabilité

Une watchtower IA opérationnelle couvre quatre couches, de la plus immédiate à la plus stratégique.

• 1. Cycle de vie. Où en est chaque cas d’usage dans les six phases ? Combien sont bloqués ? Depuis combien de temps ? C’est la première couche que les comités exécutifs demandent à voir.
• 2. Conformité. Quels cas d’usage entrent dans la catégorie « haut risque » au sens EU AI Act ? L’évaluation de conformité est-elle à jour ? La supervision humaine est-elle documentée ? C’est la couche qui protège l’entreprise à l’échéance haut risque (décembre 2027 dans le calendrier révisé), et dès maintenant pour les obligations de transparence déjà applicables.
• 3. Qualité technique. Qualité des données d’entrée, drift du modèle, dérive de performance, alertes opérationnelles. C’est la couche que les équipes data et MLOps (l’ingénierie de mise en production des modèles) connaissent bien (MLflow, Evidently, Weights & Biases).
• 4. Valeur. Quelle valeur métier chaque cas d’usage capte-t-il par rapport au bet qu’il soutient ? C’est la couche la plus difficile, parce qu’elle oblige à relier une métrique métier à un cas d’usage technique. Et c’est précisément la couche qui justifie l’investissement. Elle intègre aussi le coût de run de chaque cas d’usage : un portefeuille IA se juge en valeur nette, inférence et supervision comprises.

Trois critères

Watchtower et MLOps. Deux fonctions distinctes

La confusion est fréquente, alors que les deux sont complémentaires. Le MLOps couvre la qualité technique, la couche 3 ci-dessus : nécessaire, mais insuffisant pour piloter un portefeuille. La watchtower, elle, agrège les quatre couches et, surtout, les raccroche aux bets. Elle fait le pont entre la qualité technique, côté MLOps, et la stratégie, côté bet.

Sans ce pont, l’observabilité reste cantonnée aux équipes data, invisible au comex comme au régulateur.

L’article 14 du règlement européen impose une supervision humaine effective des systèmes à haut risque. En 2027, l’auditeur voudra voir où cette supervision s’exerce, écran par écran. La watchtower est la seule couche capable de le montrer.

Une trajectoire en six à douze mois

Cagan décrit des transformations produit, BCG des transformations IA. Les deux convergent vers une trajectoire en trois temps.

Mois 1 à 3. Le bet pilote

Choisir un bet, une équipe, un produit. Un seul, pas trois ni dix. De préférence un domaine où l’IA pèse réellement, sinon le prisme du CDAIO n’aura rien à montrer.

Déployer l’architecture complète sur ce périmètre restreint : le bet, les opportunités, les initiatives et les expérimentations, dans les trois prismes. Il s’agit de prouver que le système répond aux trois questions d’Eva, Pierre et Sarah, sans qu’un Excel parallèle subsiste.

Mois 4 à 6. Le portefeuille

Étendre la démarche à tous les bets d’un même portefeuille. C’est la deuxième vague d’effort organisationnel : homogénéiser le vocabulaire, fusionner les Excel parallèles, refondre les rituels, comex mensuel et revue de portefeuille trimestrielle. C’est la phase la plus délicate, celle où les habitudes anciennes résistent le plus.

Mois 7 à 12. Le modèle opérationnel entier

Étendre enfin la démarche à tous les portefeuilles. C’est le moment où les économies d’échelle apparaissent : comparaisons inter-portefeuilles, arbitrages du comex sur des grilles homogènes, watchtower IA consolidée, conformité EU AI Act systématique.

C’est aussi le moment où la culture bascule : les nouveaux arrivants adoptent ce vocabulaire d’emblée.

Trois pièges

Trois pièges reviennent.

• Vouloir tout transformer d’un coup. Le bet pilote est une condition. Sans lui, la phase 2 démarre dans le doute et perd l’élan.
• Confondre outil et modèle opérationnel. Le logiciel ne transforme pas une organisation. Il accélère une transformation déjà décidée. Installer le système sans modifier les rituels revient à ajouter un Excel de plus.
• Laisser l’AI Office isolé. Si l’AI Office n’est pas relié aux équipes produit dès la phase 1, la phase 3 découvrira un fossé coûteux à combler.

Ce que nous construisons

Cette catégorie de logiciel n’a pas encore de nom stable. Nous l’appelons un operating system de portefeuille. C’est une source de vérité unique sur les bets, les opportunités, les initiatives et les expérimentations. Elle se lit à travers les trois prismes du PM, du PMO et du CDAIO. Une watchtower y rattache la valeur aux bets. Le tout sert un modèle opérationnel intégré et piloté par la valeur.

C’est ce que nous construisons chez Fygurs. Ce document ne fait pas la démonstration du produit. Il pose le terrain et l’architecture de référence, que chacun reste libre de reprendre. Nous menons régulièrement cet exercice avec des équipes produit, PMO et data : confronter leur modèle opérationnel à ce cadre, et repérer où il tient et où il leur manque un système. saad@fygurs.com

Sources

Chaque affirmation chiffrée ou structurelle de ce document est traçable à l'une des sources suivantes. Les liens directs vers les publications originales sont indiqués lorsque celles-ci sont disponibles publiquement.