Construire un produit numérique : ce que l'IA ne change pas

Trois fondamentaux du produit que l'IA ne change pas, et comment les tenir quand un financeur veut un plan précis. Ce qu'on a retenu en écoutant Romain Kuzniak.

À peine le temps de comprendre un outil qu'un autre le remplace. À peine un choix posé qu'une annonce le périme. Mener un projet numérique aujourd'hui, c'est courir derrière un train qui accélère, et avec les moyens d'une association, on part avec deux wagons de retard.

La tentation, c'est de courir plus vite. Romain Kuzniak déplace le problème : plutôt que de se demander ce que l'IA change, il se demande ce qu'elle ne change pas. Parce qu'on bâtit une stratégie solide sur ce qui sera encore vrai dans dix ans, pas sur ce qui bouge tous les mois.

Romain sait de quoi il parle : il a dirigé le produit et la technologie d'OpenClassrooms pendant douze ans, d'une équipe de douze personnes (le site s'appelait encore Le Site du Zéro) à une entreprise de près de 700. Son constat tient en une phrase : l'IA change la façon de construire un produit (votre plateforme, votre appli, votre chatbot), pas ce qui fait sa valeur. Et créer de la valeur pour les gens qu'on accompagne, c'est le métier des associations depuis toujours, même sans le vocabulaire du produit.

On en retient trois fondamentaux : partir d'un problème qui compte, chercher à apprendre vite plutôt qu'à faire propre au début, et piloter par objectifs plutôt que par fonctionnalités. Plus une question épineuse que Romain n'a pas vraiment tranchée : comment tenir tout ça face à des financeurs qui veulent un plan précis. Comptez huit minutes.

Fondamental 1 : partez d'un problème qui compte, pas d'un outil

Vous connaissez le refrain : on part du besoin des bénéficiaires, pas de l'outil. On en a même fait un article entier. Romain le résume d'une formule à afficher au mur : l'IA fournit des solutions, pas des résultats. Les gens n'utilisent pas une solution pour ce qu'elle est, mais pour ce qu'elle leur permet d'obtenir.

Un besoin, ça ne suffit pourtant pas : encore faut-il qu'il compte vraiment. La question à se poser est simple : est-ce que vos bénéficiaires attendent ce projet, ou est-ce que c'est juste une bonne idée de plus ?

Imaginons une association d'accès aux droits qui hésite entre deux projets : un chatbot qui explique les aides sociales, ou un rappel automatique avant chaque échéance de renouvellement, quand rater une date signifie des semaines sans ressources. Le premier part d'une bonne intention, mais l'information existe déjà ailleurs : personne ne l'attendait vraiment. Le second règle un problème qui a des conséquences concrètes dans leur vie.

Attention à un autre mauvais point de départ, moins évident : vous-même. Partir de vos objectifs ("toucher plus de bénéficiaires", "plus d'usage sur la plateforme") pour redescendre vers une solution ne marche pas non plus forcément. Les gens utilisent un service parce qu'il règle leur problème, pas parce que vous avez besoin qu'ils l'utilisent. Quant à l'IA, elle fait surgir de nouveaux problèmes à traiter et fabrique les solutions plus vite ; elle ne choisit pas le problème à votre place.

Concrètement. Décrivez votre projet sans prononcer "IA", "chatbot" ni "algorithme" : quel problème, pour qui, quel changement dans leur vie. Si vous n'y arrivez pas, vous êtes parti de l'outil. Si vous y arrivez, posez la seconde question : vos bénéficiaires l'attendent-ils assez pour changer leurs habitudes ? Si la réponse honnête est "pas vraiment", le projet peut attendre.

‍

Fondamental 2 : au début, ne cherchez pas la qualité, cherchez à apprendre vite

Romain emprunte un cadre à Kent Beck, une des figures historiques du développement logiciel. Un produit traverse trois étapes :

- Explorer : peu d'utilisateurs, vous cherchez encore le vrai problème.

- Étendre : ça décolle, tout sature, l'objectif est que ça tienne.

- Exploiter : c'est stabilisé, beaucoup de gens en dépendent, chaque décision compte.

Chaque étape a ses pratiques, et la plus contre-intuitive concerne l'exploration : on n'y vise pas la qualité, on vise à apprendre vite. Au début, vous avez tout à gagner et presque rien à perdre : peu d'utilisateurs, donc une erreur ne coûte rien, et la bonne piste peut tout changer. Plus tard, quand beaucoup de gens dépendent de votre outil, le rapport s'inverse : une fausse manœuvre peut coûter cher.

Or la plupart des projets IA d'associations sont en pleine exploration. D'où ce piège fréquent : passer 6 mois à peaufiner un assistant avant de l'avoir montré à un seul bénéficiaire. Mieux vaut un prototype bricolé, montré vite, qui vous apprend ce dont les gens ont vraiment besoin. Et c'est là que l'IA aide : on prototype aujourd'hui en quelques semaines, sans grosse compétence technique.

Reste un réflexe que Romain juge décisif : nommez l'étape à voix haute, devant votre équipe et votre conseil d'administration. Sinon, on reprochera à votre prototype de ne pas être un produit fini, alors que c'était justement le but.

Concrètement. Avant votre prochaine décision (recruter, investir dans une techno, soigner le design), demandez-vous à quelle étape est ce projet. Si vous cherchez encore qui vous aidez et comment, vous explorez : la finition est prématurée. Notez l'étape, dites-la à votre équipe.

‍

Fondamental 3 : une feuille de route, ce sont des objectifs, pas une liste de fonctionnalités

Le réflexe courant, c'est de voir sa feuille de route produit comme une liste de choses à construire. Elle finit par vous enfermer : une fois écrite, vous construisez "parce que c'est dessus", même quand ça ne sert plus votre mission. Romain propose de la formuler en objectifs : non pas "construire un module de recommandation", mais "amener X% de jeunes de plus au bout de leur parcours d'orientation". L'objectif laisse la solution ouverte, et souvent un petit ajustement (un lien, une relance) suffit là où on imaginait un gros chantier.

Son format, un tableau avec trois colonnes : maintenant, ensuite, plus tard. Avec une règle ferme : une seule chose dans "maintenant". Parce que la ressource rare, ce ne sont pas les idées, c'est l'attention : plus vous ouvrez de chantiers en même temps, plus vous la diluez, jusqu'à n'en finir aucun. Avec deux salariés et trois mille bénéficiaires, huit priorités, c'est zéro priorité. Plus facile à écrire qu'à faire, on le sait, quand chaque financement impose ses livrables ; raison de plus pour ne pas s'en ajouter.

La colonne "plus tard" sert surtout à écrire noir sur blanc ce qu'on ne fera pas, pour que ces idées cessent de revenir sur la table. C'est d'ailleurs là qu'atterrissent les envies d'IA accumulées depuis deux ans ("et si on faisait un chatbot ?"). La décision la plus difficile, et souvent la meilleure, c'est de renoncer.

Concrètement. Reprenez votre feuille de route. Chaque ligne est-elle un objectif mesurable ("X% de…") ou une fonctionnalité à livrer ("construire…") ? Si les fonctionnalités dominent, vous pilotez à la livraison, pas à la valeur. Et comptez vos priorités du moment : plus d'une, c'est que vous n'avez pas encore priorisé.

Oui, mais nos financeurs veulent un plan précis

Tout cela suppose une liberté que les associations n'ont pas toujours. Pendant la session, quelqu'un a posé la question qui fâche : nos subventions décrivent ce qu'on va faire, avec des objectifs précis ; si on s'en écarte, on risque de perdre l'argent. Comment concilier ça avec une feuille de route souple ?

Romain a reconnu ne pas avoir de réponse toute faite, mais il a posé une distinction utile : s'engager sur des moyens ("former 100 personnes") ou sur des résultats ("100 personnes retrouvent un emploi"). Le résultat parle plus, à vous comme au financeur. Mais, il l'a dit lui-même, c'est plus risqué : s'il n'est pas au rendez-vous, l'argent peut ne pas suivre.

On se permet d'ajouter une nuance, parce que toutes les associations ne peuvent pas se permettre ce pari. Quand la trésorerie tient six mois, conditionner le versement à un résultat qu'on ne maîtrise qu'à moitié (le retour à l'emploi dépend aussi du marché) n'est plus de l'ambition, c'est de la roulette. Il y a même un piège que les économistes ont baptisé la loi de Goodhart : dès qu'une mesure devient une cible, elle cesse d'être une bonne mesure. Une association sommée de "faire son chiffre" pour survivre finira par sélectionner les bénéficiaires les plus faciles à placer, l'inverse exact de sa mission.

La ligne de crête : pilotez aux résultats, contractualisez sur les moyens. Engagez-vous auprès du financeur sur ce que vous maîtrisez (former cent personnes), et affichez à côté, volontairement, le résultat que vous visez et comment vous le mesurez (combien retrouvent un emploi à six mois). Le versement est sécurisé, le financeur reçoit une transparence rare, et vous vous constituez, résultat après résultat, un dossier pour le prochain renouvellement. Votre feuille de route, elle, reste votre boussole interne ; elle n'a pas besoin d'être votre contrat.

Ce qu'on en retient

L'IA accélère surtout l'exécution : on prototype en jours, on construit plus vite, on tente plus. Elle ne déplace pas les fondamentaux : bâtir sur ce qui ne change pas, partir d'un problème qui compte, faire une chose à la fois. Romain ajoute une nuance qui pique : loin de niveler les écarts, l'IA les creuse entre ceux qui maîtrisent ces fondamentaux et les autres. À OpenClassrooms, ses équipes avaient accumulé dix-huit ans de chantiers en réserve ; ils ont tout jeté. Le problème n'a jamais été de manquer d'idées, c'est de choisir.

Sa dernière histoire ne parle d'ailleurs ni d'IA ni de méthode. Un utilisateur de Capitaine Train, un service français de billets de train, demande un jour sur Twitter de pouvoir réserver une place pour son chat. Deux ans et demi plus tard, la fonctionnalité sort, et l'équipe, qui avait noté chaque demande, retrouve son message et lui répond : c'est disponible depuis hier. La personne a partagé la réponse, stupéfaite qu'on ne l'ait pas oubliée.

C'est peut-être ça, ce qui ne change pas : la valeur d'un produit, comme celle d'un accompagnement, se joue dans l'attention réelle portée à des personnes réelles. Cette attention-là, c'est votre métier depuis toujours. L'IA peut vous dégager du temps pour l'exercer ; elle ne l'exercera pas à votre place.

La conférence de Romain Kuzniak a eu lieu lors de l'événement de lancement de forwa, le premier programme européen qui accompagne 15 associations luttant contre les inégalités d'accès à l'éducation et à l'emploi grâce à l'IA.

‍

Ça coule de (nos) sources

- Les trois étapes d'un produit (explorer, étendre, exploiter) : Kent Beck, le modèle des "3X"

- Pourquoi on peut tout tenter au début et plus après (convexité, antifragilité) : Nassim Nicholas Taleb, Antifragile (2012)

- L'attention comme ressource rare : Herbert Simon, "Designing Organizations for an Information-Rich World" (1971)

- "Quand une mesure devient une cible, elle cesse d'être une bonne mesure" : la loi de Goodhart (Charles Goodhart, 1975), formulation de Marilyn Strathern (1997)

- "Se concentrer, c'est dire non" : Steve Jobs (WWDC, 1997)

- Prioriser sans se déchirer : la méthode RICE (Reach, Impact, Confidence, Effort)

- Feuille de route "maintenant / ensuite / plus tard" : le format now-next-later, popularisé par Janna Bastow (ProdPad)

‍