J’y ai pensé plusieurs fois ces derniers mois, presque avec une certaine inquiétude. J’ai passé vingt ans à construire des produits numériques, assez pour bien me souvenir comment c’était quand le web 2.0 semblait la réponse à tout, et assez pour avoir vécu la révolution mobile de l’intérieur, avec cet air de « ok, là quelque chose change vraiment ».
Avec l’IA il se passe la même chose. Et pourtant, autour de moi, je vois beaucoup d’entreprises réagir comme s’il s’agissait d’une mise à jour ordinaire. Un add-on. Un plugin.
Et c’est peut-être un problème.
Le piège du « mettons un peu d’IA »
C’est devenu presque un réflexe. Un chatbot dans le service client. Un résumé généré dans le tableau de bord. Un copilot dans une sidebar. Une recherche « plus intelligente ».
Ce sont des choses utiles, vraiment. Je ne veux pas faire le puriste qui snobe ce qui marche. Mais je me demande si elles ne sont pas, en même temps, des choses profondément conservatrices. Comme mettre un moteur électrique sur une calèche et appeler ça révolution. La calèche reste une calèche, ce qui change c’est ce qui la tire.
Cette dynamique je l’ai déjà vue. En 2007 elle s’appelait « mobile ».
Quand l’iPhone a explosé, beaucoup d’entreprises ont pris leurs sites desktop et les ont « adaptés ». Responsive, boutons plus petits, colonnes réordonnées, menu hamburger, et voilà. Techniquement correct. Stratégiquement… presque sans intérêt.
Parce que ceux qui ont gagné ne sont pas ceux qui ont adapté l’ancien au nouveau, mais ceux qui ont tout repensé.
Uber n’est pas un site de taxi rendu responsive. C’est un produit qui sans GPS, connexion always-on et appareil dans la poche n’aurait pas eu de sens.
Instagram n’est pas Flickr en miniature. C’est un langage visuel né pour le mobile, pensé pour s’utiliser à une main, en marchant.
WhatsApp n’est pas un mail sur smartphone. C’est de la communication reconçue autour d’un postulat : l’appareil est personnel, toujours avec toi, toujours connecté.
Aucun de ces produits ne serait né de la mentalité « bricolons ce qui existe ». Ils sont nés d’une autre question.
La bonne question
La question n’est pas : comment j’ajoute de l’IA à mon produit ?
La question est : si je concevais ce produit aujourd’hui, en sachant que la moitié des interactions passera par des agents IA, en quoi serait-il différent ?
Cela ressemble à une nuance, mais ça ne l’est pas.
Pendant vingt ans nous avons conçu du logiciel à partir d’un postulat presque invisible : un être humain s’assoit devant un écran et interagit avec une interface graphique. Il clique, défile, remplit des champs.
Ce postulat ne disparaîtra pas, mais il cessera d’être le seul. Et quand il cesse d’être le seul, beaucoup de choix qui paraissaient « normaux » deviennent soudain arbitraires.
Pensez à toutes les actions quotidiennes que nous faisons dans des produits numériques que, avec les bonnes API et les bonnes permissions, un agent pourrait faire à notre place. Réserver un restaurant. Comparer des devis. Remplir un formulaire. Déplacer un rendez-vous. Analyser un rapport. Faire les courses. Payer une facture.
Ce n’est pas de la science-fiction. Les modèles de langage savent déjà gérer des flux complexes. Le goulot d’étranglement n’est souvent pas l’IA. C’est la façon dont les produits sont construits.
Beaucoup de logiciels ont été conçus pour être regardés et cliqués. Pas pour être compris et orchestrés.
Et cette différence est, à mon avis, énorme.
D’interfaces à contrats
Là, ça devient concret.
Pendant des années, le « produit » a été l’interface. L’UI était le produit. Tout le reste — backend, API, base de données — était de l’infrastructure au service des écrans. Designers qui dessinaient des écrans, développeurs qui les implémentaient, product managers qui mesuraient les conversions sur les boutons.
Dans le paradigme qui arrive, le produit devient le contrat.
API claires. Documentation structurée. Schémas de données cohérents. Capabilities exposées de façon sémantiquement riche. Erreurs qui expliquent ce qui s’est passé et quoi faire. Contrats stables.
L’interface graphique ne disparaît pas, mais change de rôle. Elle devient un client du produit, pas le produit. Un client parmi d’autres.
Et, paradoxalement, c’est une bonne nouvelle. Parce qu’une API pensée pour être consommée par des agents IA vous force à faire du bon logiciel. Elle vous force à être clair. Cohérent. Fiable. Composable.
L’IA ne baisse pas la barre. Elle la lève.
De feature à capability
Il y a un changement de mentalité qui touche au cœur du product management.
La mentalité traditionnelle est feature-driven. Ajoutons la feature X. Il faut cinq écrans, trois endpoints, deux tables. Wireframes, user stories, critères d’acceptation. Et puis un flux presque toujours linéaire : l’utilisateur arrive en A, clique B, remplit C, obtient D.
La mentalité AI-native, en revanche, tend à être capability-driven.
Vous ne concevez pas un parcours. Vous concevez une brique. Une capability orchestrable par n’importe qui : un humain via GUI, un agent via API, un autre système via webhook. Et souvent elle sera combinée à d’autres briques de manières que vous n’aviez pas prévues.
C’est plus puissant, mais aussi plus difficile. Cela demande de penser en termes de contrats, d’invariants, de préconditions et postconditions. Cela demande une ingénierie plus mature.
Et là, je l’avoue, je m’enthousiasme un peu. Parce que c’est comme si la pression de l’IA rendait enfin inévitables ces best practices que tant d’ingénieurs ont répétées des années, souvent dans le vide.
Le paradoxe de l’ouverture
Il y a un autre aspect que je trouve contre-intuitif.
Pendant des années, le modèle dominant a été le lock-in. Données fermées, exports difficiles, walled garden. « C’est comme ça qu’on défend l’avantage compétitif. »
Dans un monde d’agents IA, la fermeture risque de devenir un handicap.
Un agent travaille mieux avec des services qui collaborent. Qui exposent des données structurées. Qui ont des API documentées. Qui permettent l’interopérabilité. Si un service est opaque et difficile à intégrer, l’agent tendra à le contourner et à choisir des alternatives plus composables.
Et il y a là un paradoxe magnifique, presque poétique : pour retenir les utilisateurs, il faut les laisser libres de partir.
Cela déplace aussi le terrain de jeu pour les petites entreprises. Parce que sur l’ouverture, la qualité des API, la documentation, la propreté des contrats, une PME agile peut rivaliser. Parfois elle peut même faire mieux qu’un mastodonte plein de legacy.
La compliance comme superpouvoir
Cette partie me tient particulièrement à cœur, parce que c’est le terrain sur lequel je me retrouve tous les jours.
RGPD, AI Act, Cyber Resilience Act, Product Liability Directive, European Accessibility Act. Souvent vécus comme un coût. Une nuisance. Une taxe sur le business.
Moi, de plus en plus, je les vois différemment.
Dans un écosystème médié par des agents IA, la confiance devient une ressource computationnelle. Pas seulement du marketing. Un input dans les décisions.
Si un agent doit choisir entre deux services semblables, il tendra à préférer celui qui est vérifiable. Celui avec un SBOM transparent. Audit trail complet. Privacy by design documentée. Conformité déclarée et démontrable.
Dans ce sens, la compliance cesse d’être seulement un coût à porter et devient un signal de qualité lisible par les machines. Un différenciateur compétitif.
Je sais que ça sonne presque étrange dit comme ça, mais je pense que c’est vrai : la compliance peut devenir un superpouvoir.
Et peut-être que l’Europe, avec toute sa bureaucratie qui en fait souffler beaucoup, construit un terrain où la confiance est computable. Si vous savez la transformer en architecture, ce n’est pas un frein. C’est un avantage.
Là où tout cela devient concret
Je pourrais m’arrêter ici, sur le plan des idées. Mais ce ne serait pas honnête, parce que pour moi cette transition est concrète, quotidienne.
Quand nous migrons un produit, nous ne « modernisons pas seulement le stack ». Nous préparons un service à un futur où les agents interagiront avec ces systèmes autant que les humains.
Quand nous construisons une plateforme SBOM pour gérer les dépendances logicielles, nous ne faisons pas seulement de la compliance. Nous créons une couche de confiance vérifiable.
Quand nous déplaçons le centre de gravité vers le développement guidé par les spécifications, où la spec est le produit primaire et le code un artefact dérivé, ce n’est pas seulement une méthodologie. C’est une façon de travailler dans laquelle l’IA peut être un vrai partenaire, pas un gadget.
À un moment, vous vous apercevez que tout se tient. Architecture propre, documentation rigoureuse, compliance by design, API-first, spécifications comme objet principal. Ce sont les facettes d’une même idée.
Dans le monde qui vient, la clarté est puissance.
Le vrai risque
Le plus grand risque, aujourd’hui, n’est pas de faire des « choses mauvaises » avec l’IA.
C’est de faire les bonnes choses, mais dans l’ancien paradigme.
C’est ajouter un chatbot au lieu de repenser l’architecture de l’interaction. C’est mettre des suggestions IA dans une interface qui ne devrait peut-être pas exister sous cette forme. C’est utiliser l’IA pour écrire du code plus vite sans se demander si l’on devrait écrire des spécifications plus claires.
Je sais que c’est une position forte. Et je sais aussi que beaucoup d’entreprises obtiennent des résultats réels en ajoutant de l’IA aux produits existants. Je ne dis pas que tout est faux.
Je dis que c’est insuffisant. Que cela risque d’être le jeu d’hier avec les pièces d’aujourd’hui.
Une lettre d’amour à la technologie qui aide
Je clos sur une note personnelle, parce que ce discours, pour moi, n’est pas que stratégie.
J’aime la technologie quand elle aide. Quand elle rend accessible ce qui était exclusif. Quand elle simplifie ce qui était compliqué. Quand elle libère du temps pour ce qui compte vraiment.
Quand je pense à l’IA dans les produits numériques, je ne pense pas, ou en tout cas pas seulement, à des chatbots qui répondent à la place de quelqu’un. Je pense à une personne âgée qui parvient à interagir avec l’administration publique grâce à un agent qui comprend et traduit la bureaucratie. Je pense à un petit entrepreneur qui gère la compliance sans une armée de consultants parce que le logiciel le soutient nativement. Je pense à un médecin qui peut rester avec le patient pendant que la part documentaire est mieux gérée. Je pense à un étudiant en situation de handicap qui trouve une expérience vraiment accessible, pas une case cochée dans un Excel.
Pour y arriver, en revanche, il ne suffit pas d’« ajouter de l’IA ». Il faut repenser les produits autour d’un monde où humains et agents coexistent.
Ce n’est pas facile. Cela exige de remettre en cause des présupposés que nous tenions pour acquis. Cela exige des compétences nouvelles et une certaine humilité. Cela exige la question la plus inconfortable de toutes : si je partais de zéro aujourd’hui, ferais-je comme ça ?
Mais c’est un beau défi. De ceux qui donnent envie de se mettre au travail.
Parce que de l’autre côté, peut-être, il y a un logiciel plus utile, plus accessible, plus fiable. Et, dans un sens non banal, plus humain.
Ce qu'il faut retenir
L’interface graphique ne disparaît pas, mais devient un client parmi d’autres, pas le produit.
Pour retenir les utilisateurs, il faut les laisser libres de partir : l’ouverture devient avantage compétitif.
Le plus grand risque n’est pas de faire des choses mauvaises avec l’IA, c’est de faire les bonnes choses dans l’ancien paradigme.
Questions & réponses
Pourquoi ajouter un chatbot à son produit ne suffit-il pas ?
Parce qu’« ajouter de l’IA » à un produit existant signifie construire une nouvelle interface au-dessus d’une architecture pensée pour l’interaction humaine directe. Quand la moitié des interactions commence à passer par des agents IA qui parlent au nom de l’utilisateur, le produit doit être réinventé : les API doivent être complètes et navigables, les données machine-readable, la sécurité doit distinguer entre utilisateur et agent autorisé, la compliance tracer les décisions automatiques. Le chatbot est un pansement.
Que signifie repenser un produit pour l'ère des agents IA ?
Concevoir un produit AI-native : API publiques et documentées comme citoyens de première classe (pas wrappers autour d’UI), état sérialisable pour l’agent, policies explicites sur ce que les agents peuvent ou non, audit log granulaire, mécanismes d’autorisation reconnaissant agent-as-user. C’est une refonte, pas une feature.
Qui est à l'abri et qui ne l'est pas dans cette transition ?
À l’abri : produits déjà API-first, avec architecture propre, gouvernance mature. À risque : SaaS consumer qui vivent d’UI propriétaires et de lock-in, produits enterprise avec API fragiles ou non documentées, entreprises qui ont fortement investi dans des intégrations vendor-lock. Ces derniers risquent d’être désintermédiés par des agents qui utilisent un concurrent plus ouvert comme défaut.
Combien de temps pour repenser ?
Entre 18 et 36 mois pour la plupart des catégories de produit. Les agents IA consumer (ChatGPT agent, Claude, Perplexity) deviennent le front-end habituel pour une part croissante d’utilisateurs. Chaque mois sans API robuste est un mois où votre produit devient moins composable. Qui planifie la transition comme stratégie biennale arrive à temps. Qui attend les premières pertes de part de marché est en retard.
L'auteur
