Ressources > Articles
Projet IA : ce qui change vraiment pour un Product Manager
Intelligence artificielle
En travaillant sur l’intégration GenAI chez Closd (LexisNexis) — résumés de contrats, RAG, détection d’anomalies réglementaires — puis sur un projet de plateforme agentique pour Renault Group, j’ai réalisé quelque chose que beaucoup de Product Managers découvrent trop tard : piloter un développement IA, c’est différent de piloter un développement classique avec un modèle en plus.
Les cycles sont différents. Les risques sont différents. Les compétences mobilisées sont différentes. Et surtout, la façon dont on valide et mesure le succès est radicalement différente.
Voici 5 différences clés que tout PM IA/GenAI doit comprendre avant de se lancer.
1. En IA, l’objectif est un comportement attendu
En développement classique, on spécifie un comportement attendu : si l’utilisateur clique sur X, il se passe Y. Le système est déterministe.
En développement IA, et a fortiori en GenAI, la logique change : on entraîne ou on orchestre un modèle pour qu’il produise des outputs vraisemblables, plutôt que de spécifier un comportement attendu. Chez Renault, l’objectif n’était pas « afficher une recommandation » mais « générer une recommandation pertinente, robuste et conforme ». La nuance est énorme en termes de cadrage produit.
Ce que ça change pour le PM IA : les user stories ne suffisent plus. Il faut définir des critères de qualité des outputs, des seuils d’acceptabilité, et des cas limites dès le cadrage.
2. La discovery est plus longue, et plus critique
Dans un projet classique, la discovery sert à comprendre le problème utilisateur et à valider la solution. Dans un projet IA, elle sert aussi à vérifier que les données existent, qu’elles sont exploitables, et que le modèle peut techniquement résoudre le problème.
Chez Renault, j’ai passé plusieurs semaines en discovery métiers avant d’écrire la première ligne de spec : interviews value streams, qualification des cas d’usage, calcul du ROI attendu, et surtout vérification de la disponibilité des données avec les équipes Data et Architecture SI.
Ce que ça change pour le PM IA : faute de cette phase, on construit des POCs qui restent bloqués avant la production. C’est le piège le plus fréquent que j’observe.
3. Les tests sont plus complexes, et jamais exhaustifs
En développement classique, on teste des scénarios prédéfinis. Un test passe ou ne passe pas.
En développement IA, on teste la qualité statistique des outputs sur des jeux de données variés. Chez Closd, la validation du module de résumé de contrats ne pouvait pas se faire sur 10 documents — il fallait tester sur des centaines de contrats, dans des formats différents, avec des juristes qui évaluaient la pertinence des résumés.
Ce que ça change pour le PM IA : il faut prévoir des cycles de validation plus longs, impliquer des experts métiers dans les tests, et accepter qu’un modèle soit suffisamment bon pour le cas d’usage défini, plutôt que parfait.
4. La maintenance est continue
Un bug en développement classique se corrige et se ferme. Un modèle IA se dégrade dans le temps sans surveillance active : les données changent, les comportements utilisateurs évoluent, les outputs dérivent.
Chez Renault, la gouvernance des modèles était un sujet à part entière : qualité, robustesse, conformité RGPD, adoption. On a conçu des dashboards de pilotage spécifiques pour le suivi des modèles en production — distincts des dashboards produit classiques.
Ce que ça change pour le PM IA : il faut intégrer la surveillance des modèles dans la roadmap dès le lancement. C’est une responsabilité produit, autant que data.
5. Les contraintes réglementaires arrivent beaucoup plus tôt
En développement classique, la conformité RGPD est souvent traitée en fin de cycle. En développement IA — surtout GenAI — elle doit être intégrée dès la conception.
Chez Renault, le cadrage sécurité et RGPD avec la DPO (PIA) faisait partie du design de l’architecture agentique. On ne pouvait pas connecter les agents aux outils du quotidien sans avoir validé le cadre de traitement des données en amont.
Ce que ça change pour le PM : impliquer la DPO et les équipes sécurité dès la phase de cadrage. C’est une condition pour aller en production.
Ce que j’en retiens
Piloter un projet IA, c’est travailler avec l’incertitude comme donnée de base. La plupart des POCs qui n’atteignent pas la production n’ont pas échoué sur la technique : ils ont échoué sur le cadrage, la validation et la gouvernance.
Maîtriser ces dimensions demande une posture différente de celle du PM classique — plus proche des équipes Data et Architecture, plus attentif aux contraintes réglementaires, capable de définir le succès sur des outputs probabilistes. C’est le cœur du rôle de Product Manager IA.