Et si vous supprimiez le "bouton IA" ?
#2 - Ou comment penser son expérience utilisateur en 2026.
Buenos días !
Bienvenue dans cette seconde édition de Founder Naked.
Pas facile d’ailleurs d’enchaîner après une première édition assez personnelle, qui faisait le lien avec mon ancienne vie, avec ce nouveau numéro beaucoup plus concret !
Je me suis creusé la tête pour savoir avec quel sujet j’allais démarrer cette année, et je trouve que ce que j’appelle “le bouton IA” est une bonne entrée en matière. C’est l’archétype même de la situation bancale dans laquelle se trouve la plupart des boîtes.
Si ce n’est pas déjà le cas, tu peux aussi :
Me suivre sur Linkedin, où je publie des posts complémentaires,
Découvrir les services que je propose, notamment dans le secteur de la finance…
… mais pas encore découvrir Licorn, ma nouvelle boîte.
Allez, c’est parti !
Au programme
Ce qu’on a fait de l’IA entre 2022 et 2025
Photo de l’IA en entreprise à fin 2025
Ce que ça implique si tu construits un produit
Comment moi j’implémente l’IA
En 4 ans on a …
…découvert que l’IA n’était plus un truc théorique et qu’une nouvelle révolution industrielle était en marche. Et je pense qu’il a vraiment fallu 4 ans pour qu’on commence à le réaliser, et qu’on commence (à peine) à entrevoir les changements que cela implique.
On a tous très vite parlé des sujets qui fâchent — l’emploi notamment — mais on n’est pas encore parvenu à “capter” ce que ça veut dire concrètement pour tout ce qu’on construit : produits, expériences, organisations.
Techniquement, si on suit les chercheurs, l’histoire commence bien avant : les briques de machine learning et les premières formes d’apprentissage profond (les LLMs) datent des années 1990. Mais soyons honnêtes : c’est le lancement de ChatGPT en novembre 2022 qui nous a fait réaliser que l’IA débarquait vraiment dans nos vies.
Depuis, côté entreprises, McKinsey montre une adoption qui explose sur le papier : près de 9 organisations sur 10 disent utiliser l’IA quelque part dans leur activité.
Côté terrain, les sondages en France racontent une autre histoire :
12 % des salariés disent utiliser l’IA dans leur travail,
30 % déclarent qu’il en est fait usage dans leur entreprise,
et parmi ceux qui l’utilisent, 83 % s’en servent au moins une fois par semaine, dont 44 % tous les jours.
Autrement dit :
dans les slides, l’IA est partout,
dans la vraie vie, elle touche encore une minorité de gens, mais ceux qui s’en servent, s’en servent vraiment.
On a ensuite vu fleurir des POC1 de chatbot un peu partout, puis en 2025 nous avons eu “l’année de la révolution agentique”, comme l’on titré pas mal de journaux début 2025.
On est progressivement passé de “je demande un truc”,
à “je demande de faire un truc”.
Et quand je lis de prime abord les rapports de McKinsey & co, j’ai l’impression que toutes les boîtes se sont mises à l’IA. Mais quand je parle à mes clients ou à mon entourage, j’ai surtout l’impression que ce sont les salariés qui se sont mis à l’IA, parfois bien avant leur boîte.
Où en est-on à fin 2025 ?
Pour l’instant, ma lecture est assez simple :
sur le volet “adoption en entreprise”, on n’y est clairement pas encore,
sur le volet “adoption par les gens”, ChatGPT & co ont lancé un mouvement de fond.
Les chiffres sont assez parlants : globalement, environ 1 personne sur 6 dans le monde utilise déjà l’IA pour apprendre, travailler ou résoudre des problèmes (16,3 % de la population au second semestre 2025).
En France, on retrouve le même décalage :
côté entreprises, les baromètres Bpifrance, Artefact, INSEE… montrent qu’une minorité d’acteurs a vraiment revu ses process en profondeur pour intégrer l’IA,
côté salariés, l’étude Artefact × Odoxa montre que 30 % des salariés disent que leur entreprise utilise l’IA, mais seulement 12 % l’utilisent eux-mêmes dans leur travail, avec un usage intensif pour ceux qui ont sauté le pas.
On a donc :
des boîtes qui déclarent fièrement “avoir lancé l’IA” parce qu’elles ont un chatbot sur leur site ou une intégration Copilot,
et, en parallèle, des équipes qui commencent à bricoler leur propre stack IA (ChatGPT, Perplexity, etc.), parfois en dehors des outils officiels.
La même étude Odoxa montre d’ailleurs que, parmi les salariés qui utilisent l’IA, 66 % passent par des IA intégrées aux outils internes, mais près de la moitié utilisent aussi des outils externes comme ChatGPT ou Perplexity.
Face à cette adoption précaire, les entreprises font aujourd’hui face au “Shadow IA”.
Ainsi, on a beaucoup parlé transformation, mais on a surtout transformé des bouts de process, avec un gros gap entre le discours corporate et la réalité produit.
Ce que ça implique si tu construis un produit
Ça implique surtout de changer de mindset.
Imagine qu’on rembobine et qu’on revienne aux débuts d’Internet.
Est-ce qu’aujourd’hui tu mettrais un bouton “Recherche avec Internet” dans un coin de ton app pour montrer que toi aussi tu as le Web ?
Non. Internet est juste devenu un outil dans ta palette. Tu l’utilises pour faire des trucs.
Pour l’IA, on est exactement à ce moment‑là : l’IA doit devenir le nouvel Internet.
Tu ne vends pas “j’ai de l’IA”,
tu vends une expérience qui, entre autres, s’appuie dessus.
Concrètement, si tu construis un produit en 2026, je ferais au moins quatre choses :
1. Tuer au moins un “bouton IA” décoratif
Pose-toi la question brutalement : “Est-ce que ce bouton fait vraiment gagner du temps au client ?”. Notamment si tu avais déjà une recherche avancée par exemple.
Si la réponse est non, tu as sans doute trouvé ta première cible à abattre.
2. Déplacer l’IA dans les coulisses à un endroit qui fait mal aujourd’hui
Exemples de bons candidats :
Tri / priorisation des tickets,
Suggestions de réponses pour le support, validées par un humain,
Recommandations personnalisées (contenus, produits, actions suivantes),
Détection d’anomalies (fraude, bugs, signaux clients faibles).
Ce sont souvent ces cas d’usage discrets qui génèrent le vrai ROI, bien plus que le chatbot qui fait tout.
3. Écrire noir sur blanc où l’IA est interdite dans ton produit
Décisions sensibles,
Modération sans supervision humaine,
Promesses contractuelles,
Tout ce qui touche à ta différenciation de marque.
Ce cadre te protège des “bonnes idées” qui finissent en catastrophe quelques mois plus tard.
4. Dans ton prochain sprint, écrire au moins une user story IA sans le mot “chat”.
Par exemple :
“En tant qu’utilisateur, je veux que le produit devine les 3 actions les plus probables pour moi, au lieu de me laisser devant un écran vide.”
“En tant qu’agent support, je veux 3 suggestions de réponses courtes à adapter, plutôt qu’un pavé générique.”
“En tant que fondateur, je veux un diff clair de l’impact de l’IA sur mes métriques produit (réduction du temps de résolution, réduction des abandons, etc.).”
À partir du moment où tu formules les choses comme ça, tu n’es plus en train de “mettre un bouton IA”, tu es en train de dessiner une expérience où l’IA est une brique parmi d’autres.
Comment de mon côté j’implémente l’IA
Je distingue deux cas d’usage principaux :
d’un côté les outils qui me servent à bosser au quotidien, qui ne sont pas en contact direct avec le client,
de l’autre ceux que j’incorpore dans le produit pour le client final, qui vont directement servir l’expérience utilisateur.
À titre d’exemple, voici deux cas d’usage sur mon projet qui rentrent chacun dans une de ces deux catégories :
J’ai d’un côté un serveur Railway sur lequel tourne n8n, qui me permet de faire des automatisations rapides et d’itérer au fil de l’eau, en quelques minutes dès que je vois un truc à corriger ou adapter. Je crée par exemple mes PRD2 sur Notion, et via ce système, elles sont automatiquement converties et résumées par l’IA dans Linear pour préparer la phase de dev.
Et de l’autre côté, j’ai des outils beaucoup plus administrés, qui tournent sur Inngest par exemple, avec du code versionné, pour gérer mes workflows de traduction automatisée, qui permettent de rendre disponible mon application dans le monde entier. Et là, je fais un peu plus gaffe. 😅
En pratique, ça revient pour moi à suivre quelques principes simples :
Interne : je privilégie des outils low‑code / no‑code pour itérer vite (n8n, etc.), quitte à casser et reconstruire des bouts de process.
Produit : je ne branche que ce qui est versionné, testé, observable (jobs, logs, alertes).
Risque : je suis beaucoup plus tolérant au “hack” côté interne qu’au moindre comportement étrange côté client final.
Évolution : j’accepte dès le départ que certains flows IA seront jetés ou remplacés en quelques semaines ou mois.
Tout cela pour dire que de mon côté je pense qu’il faut itérer, et itérer vite. Et pour cela, je prends le parti d’être hyper agile sur mes implémentations internes, et de tester régulièrement de nouvelles choses.
Cela me permet de rester à jour, et de monter en compétences pour implémenter de nouvelles choses sur la partie qui sert l’UX et le client.
Enfin, et ce n’est pas du superflu : tous les 3 à 6 mois je remets en question ce que j’ai bâti avec l’IA. Concrètement, je scanne des parties de mes process et de mes outils avec l’IA, en lui posant par exemple des questions du type :
“Quelles parties de ce workflow te semblent obsolètes au regard de l’état de l’art actuel (janvier 2026), tant en terme de technos, d’outils que de process ?”
(je lui donne la date, car ça les LLMs ont encore du mal)
Je fais ça à la fois sur les process internes et sur ceux qui touchent le produit, en étant plus strict sur ces derniers.
Et c’est comme ça que je me tiens à jour, sans tout reconstruire en permanence, mais sans non plus figer ce que j’ai mis en place il y a six mois comme si c’était gravé dans le marbre.
Le mot de la fin
Merci pour ta lecture.
J’ai essayé de donner quelques billes et cas concrets de mon usage de l’IA, mais il y a tellement à dire. Si tu as des questions, ou un cas d’usage sur lequel tu souhaiterais en savoir plus, partages-les moi en commentaire.
J’y répondrai ou j’en ferai un exemple dans une prochaine édition.
Passes une bonne semaine !
Yoann
POC = Proof Of Concept, c’est-à-dire un produit test développé sur un périmètre limité, mais qui permet de tester la viabilité d’une idée.
PRD = Product Requirement Document, autrement dit le document qui cadre une fonctionnalité ou ensemble de fonctionnalité sur un périmètre donné, et qui va ensuite servir de base pour le découpage du travail à faire en dev.