Un assistant de programmation IA peut produire une première ébauche plausible avant que l’équipe ait convenu de ce que la fonctionnalité doit accomplir. Le code arrive vite. Les questions difficiles demeurent : quel workflow utilisateur mérite l’attention, que se passe-t-il lorsque la réponse est fausse, quelles données le système peut-il consulter et comment savoir si la mise en production a aidé.
C’est ici que le rôle du développeur dans l’IA prend une forme plus orientée produit. L’ingénieur construit toujours le système, mais il lui faut aussi assez de contexte client et métier pour transformer une demande ambiguë en capacité délimitée, étayée par des preuves.
L’IA réduit le coût de l’output de première ébauche, ce qui augmente la valeur du jugement produit concernant le contexte, l’évaluation, les retours et les résultats métier. Pour les équipes qui ont besoin de cette combinaison dans un workflow réel, le forward-deployed AI engineering est un modèle de delivery fondé sur une relation étroite entre ingénieurs et utilisateurs.
Appeler cette personne un product manager IA peut être un raccourci utile. Cela décrit un ensemble de capacités plutôt qu’un changement complet de profession. Le produit et l’ingénierie restent des disciplines distinctes, avec des responsabilités importantes de part et d’autre.
L’IA a changé le goulot d’étranglement, mais les développeurs restent responsables du résultat
Les outils IA peuvent réduire l’effort nécessaire pour générer du code courant, des tests ou des ébauches d’interface. Cela ne rend pas le résultat prêt pour la production. Quelqu’un doit encore déterminer si le changement respecte l’architecture, traite correctement les autorisations, résiste aux cas limites et améliore le workflow qu’il doit servir.
Le ressenti des développeurs reflète cet écart. Dans la Developer Survey 2025 de Stack Overflow, 46 % des répondants ont déclaré ne pas faire confiance à l’exactitude des outils IA, contre 33 % qui leur faisaient confiance. Les suggestions presque correctes ont frustré 66 % des répondants et 45 % ont cité le temps consacré au débogage de code généré par IA. L’enquête repose sur l’auto-sélection, ces pourcentages ne doivent donc pas être traités comme des estimations de population. Ils remettent néanmoins en cause l’idée que la génération a supprimé le besoin de jugement d’ingénierie.
Les données de productivité sont également mitigées. Une étude randomisée de METR a suivi 16 développeurs open source expérimentés sur 246 tâches réelles dans des dépôts qu’ils connaissaient déjà. Avec les outils du début 2025, ils ont mis en moyenne 19 % de temps supplémentaire quand l’IA était disponible. L’échantillon était petit et spécialisé, et les outils reflétaient la période de février à juin 2025. La leçon est plus limitée : chaque équipe doit mesurer son propre résultat de delivery, y compris le temps de revue et de débogage.
Pour de nombreux workflows augmentés par l’IA, la génération peut déplacer le goulot d’étranglement vers le contexte, la revue et la vérification. Les équipes doivent établir si le système obtenu fonctionne pour de vrais utilisateurs. C’est la partie orientée produit du développement moderne.
Le travail produit désormais inclus dans l’ingénierie IA
Une fonctionnalité classique part souvent d’un comportement que l’équipe peut spécifier à l’avance. De nombreuses fonctionnalités d’IA générative présentent un comportement probabiliste. Des entrées semblables peuvent produire des réponses différentes, et une mise à jour de modèle peut modifier le comportement sans changer le code de l’application environnante. Le jugement produit devient donc une partie de l’implémentation.
Pour un développeur, le travail commence avant le choix d’un modèle ou l’ouverture d’un éditeur :
- Observer le workflow visé et nommer le résultat qui intéresse l’entreprise. Un temps de traitement plus court, un taux de correction inférieur ou une meilleure conversion peuvent servir de mesure. Les lignes de code générées ne le peuvent pas.
- Identifier le coût d’une mauvaise réponse et définir les cas qui doivent passer à un humain. Cela couvre les autorisations, les données sensibles et les actions que le système ne doit jamais réaliser seul.
- Décider si la tâche demande un modèle, une recherche dans une source fiable, une règle déterministe ou une combinaison. Certaines étapes du workflow gagnent à rester inchangées.
- Transformer des exemples historiques et volontairement difficiles en cas d’évaluation assortis de critères de mise en production clairs.
- Instrumenter la fonctionnalité en service pour que l’équipe puisse voir les dérogations, les échecs, les corrections utilisateur et la mesure métier après la sortie.
Ces décisions concernent la valeur utilisateur et les arbitrages, ce qui leur donne un caractère produit. Elles restent du travail d’ingénierie parce qu’elles doivent devenir des tests, des flux de données, des contrôles d’accès et un comportement observable en production. Le même écart entre une démonstration de modèle convaincante et un workflow fiable est étudié dans le problème du dernier kilomètre de l’IA.
L’ingénierie et le product management gardent des responsabilités distinctes
Le titre de « product manager IA » peut brouiller des rôles dont une équipe de delivery a toujours besoin. Un développeur peut être responsable du résultat d’un workflow sans reprendre la stratégie produit. Un product manager peut aider à définir le succès sans devenir responsable de la fiabilité du système. Prenez la répartition suivante comme point de départ pratique et adaptez-la à la taille de l’équipe, aux obligations réglementées et aux droits de décision existants.
| Responsabilité | Responsable ingénierie | Responsable produit ou métier | Décision partagée |
|---|---|---|---|
| Architecture, intégrations et limites de données | Responsable | Consulté | Choix des arbitrages acceptables |
| Fiabilité, latence, sécurité et réponse aux incidents | Responsable | Informé | Tolérance au risque de mise en production |
| Découverte client et choix du problème | Apporte un éclairage technique | Responsable | Périmètre du workflow |
| Séquencement du portefeuille, prix et stratégie d’adoption | Consulté | Responsable | Dossier d’investissement |
| Critères d’évaluation et retours utilisateurs | Crée des preuves répétables | Définit le résultat souhaité et recrute les utilisateurs | Décisions de sortie et de changement |
Les compétences d’ingénierie approfondies comptent au moins autant lorsque du code généré entre dans le système. Un changement plus vaste peut arriver plus vite que l’équipe ne peut le comprendre. Architecture, revue, observabilité et réponse aux incidents empêchent cette vitesse de devenir du logiciel fragile.
Le product management reste également une vraie spécialité. Choisir un marché, comparer des segments de clients ou séquencer les investissements entre équipes exige des preuves plus larges que celles qu’un développeur voit habituellement. Le déplacement utile se produit à la frontière : les développeurs gagnent du jugement produit pour la capacité qu’ils construisent et les responsables produit deviennent plus précis sur les preuves et les contraintes techniques.
Une petite équipe a besoin de droits de décision clairs
Une PME n’a généralement pas besoin d’un nouveau titre pour chaque pilote IA. Elle a besoin de responsables nommés depuis la première discussion sur le workflow jusqu’à la première revue en production. Une même personne peut porter les deux chapeaux dans une petite entreprise, mais les deux responsabilités doivent rester visibles. Voici une répartition possible :
| Décision | Responsable | Partenaire essentiel | Preuve avant passage à l’échelle |
|---|---|---|---|
| Workflow visé et mesure métier | Responsable produit ou métier | Développeur | Mesure de référence et groupe d’utilisateurs nommé |
| Architecture IA ou classique et accès aux données | Développeur ou responsable technique | Responsable sécurité ou données | Revue du flux de données et parcours de repli |
| Jeu d’évaluation et seuil de sortie | Développeur ou responsable technique | Expert produit ou métier | Cas représentatifs et critères de réussite |
| Modèle, fournisseur et arbitrage de coût | Développeur ou responsable technique | Responsable produit ou métier | Comparaison qualité, latence, coût et confidentialité |
| Retours en production et décision de changement | Partagé | Support ou opérations | Mesures de dérogation, d’échec, d’adoption et de résultat |
Ce tableau tient sur une page. Sa valeur vient de la prévention des zones sans propriétaire. Un modèle peut donner une réponse plausible alors que chacun suppose que quelqu’un d’autre a vérifié la source, défini le chemin d’escalade ou mesuré ce qui s’est passé ensuite.
L’accès aux utilisateurs est aussi une dépendance de delivery. Demander à un développeur de construire un agent à partir d’un prompt ambigu laisse les décisions produit les plus importantes sans réponse. Donnez au responsable technique du temps avec les personnes qui font le travail et avec l’expert métier qui connaît les exceptions coûteuses.
L’évaluation fait partie du produit
Pour un logiciel classique, un test peut vérifier que la même entrée produit le résultat attendu. Les systèmes IA ont besoin d’une boucle de preuves plus large. La justesse peut dépendre du contexte, l’utilité peut être subjective et certains échecs coûtent beaucoup plus que d’autres.
Le NIST AI Risk Management Framework organise ce travail autour de gouverner, cartographier, mesurer et gérer. Il appelle à tester avant le déploiement, à évaluer régulièrement en fonctionnement, à documenter les responsabilités et à surveiller. Ce cadre est un modèle pratique pour le delivery même lorsqu’un système ne relève pas d’une catégorie réglementée.
Un dossier de preuves compact pour une fonctionnalité de PME devrait inclure :
- Les utilisateurs visés, le workflow cible et une référence mesurable.
- Des exemples d’évaluation représentatifs, ainsi que des réponses inacceptables et des cas d’usage abusif prévisibles.
- La carte des données et des accès, le chemin d’escalade humaine et le comportement de repli.
- Un seuil de sortie, des responsables identifiés et une trace des changements de modèle ou de prompt.
- Des mesures de production couvrant corrections, dérogations, incidents, effort de revue et le résultat métier choisi.
C’est ici que le jugement produit devient concret. Un objectif tel qu’« aider le support à répondre plus vite » doit devenir un jeu d’évaluation et un seuil que l’équipe peut défendre. L’implémentation technique de cette boucle est traitée plus en détail dans les tests et évaluations d’agents IA.
Les équipes européennes doivent aussi classer le cas d’usage avant de présumer quelles obligations juridiques s’appliquent. L’AI Act européen prévoit des obligations différentes selon le rôle et la catégorie de risque. Sa portée territoriale peut atteindre des fournisseurs ou déployeurs hors de l’UE lorsque la sortie d’un système IA est utilisée dans l’Union, ainsi l’établissement suisse seul ne décide pas de la portée. Le guide de l’AI Act européen pour les agents IA apporte le contexte de conformité plus large. Une classification juridique mérite l’avis d’un spécialiste lorsque le cas d’usage a des conséquences importantes.
Là où la formule du product manager IA atteint ses limites
Cet ensemble de capacités a des limites. Trois situations demandent une attention particulière.
Le développeur a peu d’accès aux clients. Le jugement produit nécessite des preuves venant des utilisateurs et du métier. Sans elles, un développeur peut faire des choix d’interface locaux, mais ne peut pas choisir de manière fiable le bon problème ni représenter un marché.
Le système se trouve dans un environnement ancien ou réglementé. L’intégration, l’identité, l’auditabilité et la gestion des échecs peuvent dominer la charge. Un fort instinct produit aide aux arbitrages, tandis que l’ingénierie spécialisée et la revue métier restent décisives.
L’organisation doit faire des choix de portefeuille. Un développeur proche d’un workflow peut en devenir le meilleur défenseur. Quelqu’un doit toujours comparer cet investissement avec d’autres besoins clients et priorités commerciales de l’entreprise.
La formule échoue aussi lorsque des dirigeants l’utilisent pour faire porter à une personne la découverte, le delivery et la responsabilité commerciale sans lui donner le temps ou l’autorité. Le travail interfonctionnel est plus simple à gouverner lorsque la frontière est explicite et que les deux parties ont accès aux preuves nécessaires.
Un plan pratique de capacité sur 90 jours
Un pilote de 90 jours est assez long pour construire une boucle de preuves et assez court pour garder le périmètre initial étroit. Le calendrier ci-dessous est illustratif. Adaptez-le à la complexité d’intégration et au coût de l’échec.
Jours 1 à 15 : choisir le workflow. Observez les utilisateurs, enregistrez une référence et identifiez un résultat. Nommez les cas hors périmètre et le responsable humain des exceptions. Décidez si l’IA est justifiée pour chaque étape.
Jours 16 à 35 : constituer le dossier de preuves. Sélectionnez des cas historiques représentatifs, ajoutez des exemples difficiles et inacceptables, documentez l’accès aux données et convenez d’un seuil de sortie. C’est là que les responsables produit et technique rendent vérifiables leurs hypothèses communes.
Jours 36 à 65 : construire selon l’évaluation. Implémentez la plus petite portion utile, connectez uniquement les données nécessaires et revoyez le code généré avec les mêmes standards que le code écrit par des humains. Suivez les résultats d’évaluation avec la latence, le coût et les contraintes opérationnelles.
Jours 66 à 90 : sortir avec un parcours réversible. Commencez par une revue humaine ou un groupe d’utilisateurs limité. Journalisez les corrections et incidents, comparez le résultat avec la référence et décidez de passer à l’échelle, de réviser ou d’arrêter.
À la fin, évaluez l’équipe autant que la fonctionnalité. Le développeur peut-il expliquer le résultat utilisateur et le coût de l’échec ? Le responsable produit peut-il expliquer le seuil d’évaluation et les contraintes techniques ? Les deux peuvent-ils montrer des preuves de production ? Ces réponses révèlent si l’organisation a développé la capacité derrière l’étiquette de product manager IA.
L’avenir des développeurs logiciels ne se réduira vraisemblablement pas à un seul titre hybride. Un changement plus clair est déjà visible dans le travail : la génération devient plus facile, tandis que la responsabilité du contexte et de la preuve se rapproche de l’ingénieur qui construit la fonctionnalité. Les équipes qui préservent des spécialités distinctes et partagent le résultat peuvent transformer ce déplacement en meilleurs produits plutôt qu’en un tas plus grand de code plausible.
Questions fréquentes
Chaque développeur devient-il un product manager IA ?
Non. Cette expression décrit un ensemble de compétences qui s'élargit, sans annoncer un changement universel de métier. Les développeurs qui réalisent des workflows augmentés par l'IA doivent de plus en plus comprendre les utilisateurs, définir des critères d'évaluation et suivre les résultats en production. Les product managers gardent la responsabilité de la découverte plus large, des priorités de portefeuille et des arbitrages commerciaux, tandis que les ingénieurs restent responsables de l'architecture, de l'intégration, de la sécurité et de l'exploitation fiable.
Que fait un product manager IA de différent d'un développeur logiciel ?
Un product manager IA dirige généralement le choix du problème, la découverte client, la priorisation et le dossier économique. Un développeur logiciel transforme ces choix en système sûr et observable, puis produit des preuves qu'il fonctionne. Les rôles se recoupent sur le périmètre, les critères d'évaluation, les retours et les décisions de mise en production. La frontière dépend de la taille de l'équipe, de la réglementation et de la proximité de chacun avec les utilisateurs.
Quelles compétences produit les développeurs doivent-ils acquérir pour développer des produits IA ?
Les compétences utiles sont l'observation du workflow, la définition claire du résultat, la conception d'évaluations et la collecte rigoureuse des retours. Un développeur devrait savoir qui utilise la fonctionnalité, ce que coûte une erreur, quand une personne doit reprendre la main et quelle mesure métier doit évoluer. Il n'a pas besoin d'absorber tout le périmètre du product management pour appliquer ce jugement à une capacité précise.
Comment une petite entreprise doit-elle évaluer une fonctionnalité IA ?
Commencez par des cas représentatifs du workflow visé et définissez les comportements corrects, utiles et inacceptables avant le lancement. Documentez la limite de données, le parcours de repli et le responsable désigné. Durant une sortie contrôlée, suivez le temps de revue, les corrections, les dérogations, les incidents et le résultat métier retenu. Revoyez le jeu de tests lorsque les utilisateurs découvrent de nouveaux échecs ou lorsque le modèle et le workflow changent.
Une seule personne peut-elle gérer à la fois le produit et l'ingénierie d'un pilote IA ?
Oui, particulièrement dans une petite entreprise, à condition que les deux zones de décision restent explicites. Cette personne doit pouvoir tester le comportement technique et faire des choix de workflow informés avec un accès à de vrais utilisateurs. Pour les cas d'usage importants ou réglementés, faites intervenir les compétences de domaine, de sécurité ou juridiques utiles. Un rôle combiné ne supprime pas le besoin de revue indépendante lorsque le coût d'un échec l'exige.