Le logiciel avant la décision

Il y a une quinzaine d’années, j’ai participé au développement d’un projet appelé Meetrical.

L’idée était ambitieuse : utiliser les relations, les disponibilités et le contexte pour faire émerger des occasions de rencontre entre personnes. Le projet appartenait davantage à l’univers des réseaux sociaux de l’époque, mais certaines de ses intuitions se retrouvent aujourd’hui dans Flechis, un projet sur lequel je travaille.

Pour développer Meetrical, nous avions une équipe de cinq développeurs en Inde, une chargée de projet et plusieurs mois devant nous. Il fallait produire des spécifications, répondre aux questions, arbitrer des choix, tester les versions successives et gérer tout ce qui accompagne normalement le développement d’un logiciel.

Ce n’était pas exceptionnel. C’était simplement ainsi que l’on construisait un produit logiciel sérieux.

Surtout, une grande partie des décisions devait être prise avant de voir réellement fonctionner le produit. Il fallait décider ce que l’on voulait construire avant de pouvoir l’essayer.

C’est cette logique qui, à mon avis, commence à basculer.

Depuis quelque temps, je travaille sur Flechis. L’idée centrale est simple : permettre à des personnes qui se connaissent, directement ou indirectement, de signaler des ouvertures — un lieu, une période, une intention — et de détecter automatiquement lorsqu’une possibilité de rencontre existe.

Mais ce n’est pas Flechis lui-même qui m’intéresse ici. C’est la façon dont il est devenu possible de le construire.

En quelques jours, à partir de discussions, de spécifications et d’itérations avec des systèmes d’intelligence artificielle, je suis passée d’une idée relativement abstraite à un prototype fonctionnel, déployé et accessible dans un navigateur, avec des comptes utilisateurs, des fenêtres de disponibilité et un premier moteur de correspondance.

Le logiciel est encore loin d’être terminé. Certaines idées seront probablement abandonnées, d’autres reformulées. L’architecture évoluera. Des problèmes que je ne vois pas encore apparaîtront.

Mais c’est justement là que se situe le changement.

Je n’ai pas eu à décider au départ si Flechis méritait six mois de développement. J’ai pu commencer à le construire afin de découvrir s’il méritait d’être développé.

Construire pour comprendre

Dans le développement logiciel traditionnel, surtout lorsqu’un projet exige une équipe, un budget important ou un contrat avec un fournisseur externe, il existe une forte pression pour décider tôt.

Il faut définir les fonctionnalités, établir un budget, choisir une architecture, planifier les étapes et attribuer des ressources. Plus le coût de développement est élevé, plus on cherche naturellement à réduire l’incertitude avant de commencer.

Le problème est qu’une partie importante de cette incertitude ne peut être éliminée qu’en construisant quelque chose.

Un prototype fait apparaître des questions que les spécifications ne révèlent pas. Une interface peut rendre évidente une incohérence qui semblait parfaitement acceptable dans un document. Une fonctionnalité considérée comme centrale peut paraître secondaire après quelques minutes d’utilisation.

Je l’ai déjà constaté avec Flechis.

La possibilité de créer des ouvertures récurrentes — être généralement disponible lorsque l’on est à la maison, par exemple — n’était pas au cœur du concept initial. Elle est apparue en travaillant sur le système.

Une autre question s’est alors présentée : toutes les ouvertures ont-elles la même importance ? Une occasion exceptionnelle devrait-elle avoir plus de poids qu’une disponibilité routinière ?

Un utilisateur potentiel m’a aussi demandé si Flechis pourrait offrir une messagerie générale.

Techniquement, ce serait probablement assez facile. Mais est-ce souhaitable ? Cette fonction enrichirait-elle Flechis ou commencerait-elle à le transformer en une application de messagerie ou un réseau social comme tant d’autres ?

Autrefois, chacune de ces questions aurait pu devenir une demande de changement, une estimation et un nouvel arbitrage avec une équipe. Aujourd’hui, certaines peuvent simplement devenir des expériences.

Le prototype ne sert plus seulement à montrer ce que l’on a décidé de faire. Il peut servir à découvrir ce que l’on devrait décider.

Le travail invisible autour du code

Lorsque l’on parle d’IA et de programmation, on pense spontanément à la génération de code.

Mais quiconque a participé à des projets logiciels sait qu’une grande part du travail se déroule ailleurs. Il faut configurer les environnements, gérer les dépendances, initialiser les données, faire fonctionner les tests, déployer l’application, comprendre pourquoi quelque chose fonctionne localement mais pas une fois déployé, lire les erreurs, corriger, redéployer et recommencer.

Ce ne sont pas nécessairement les problèmes les plus difficiles du projet. Ils peuvent néanmoins en déterminer le rythme et la viabilité.

Ce qui m’a impressionnée avec Flechis, ce n’est donc pas simplement de voir l’IA écrire rapidement une fonction que j’avais décrite. C’est de voir jusqu’où elle peut participer à toute la boucle :

spécifier → construire → tester → déployer → observer → corriger → recommencer.

Un document de travail du NBER publié en 2026, fondé sur les données de plus de 100 000 développeurs GitHub, montre pourquoi cette distinction compte. Pour la génération d’agents autonomes étudiée, les auteurs mesurent une hausse cumulative de 180 % des commits. Mais ce gain tombe à 50 % lorsqu’ils comptent les projets et à 30 % lorsqu’ils observent les versions effectivement publiées.¹

Produire du code n’est donc pas la même chose que produire un système qui fonctionne, encore moins un système auquel on peut faire confiance.

Un prototype fonctionnel ne règle pas à lui seul les questions de sécurité, de confidentialité, d’accessibilité, de maintenance ou de responsabilité. L’IA peut comprimer une partie du travail nécessaire pour apprendre, sans abolir les obligations qui accompagnent un logiciel durable. Cette distinction est essentielle : le coût de la première expérience peut diminuer beaucoup plus vite que celui de l’exploitation à long terme.

Avec Flechis, je peux créer deux comptes, définir des ouvertures qui devraient normalement produire une correspondance et constater qu’il ne se passe rien.

À partir de là, on peut examiner le système réel. La confiance entre les deux personnes est-elle réciproque ? Les périodes se chevauchent-elles vraiment ? Le lieu est-il le même ? Les intentions sont-elles compatibles ? Une règle bloque-t-elle la rencontre ?

On corrige, on redéploie et on essaie encore.

À ce moment-là, le logiciel cesse d’être seulement le résultat de ma réflexion. Il devient un outil pour réfléchir.

Le coût d’essayer

C’est là que je pense que l’on décrit peut-être mal l’effet de l’IA sur le développement logiciel.

Oui, elle peut augmenter la productivité. Mais ce qui diminue n’est pas seulement le coût de produire du logiciel. C’est le coût d’essayer.

Lorsque ce coût est élevé, beaucoup d’idées ne sont jamais testées. Elles restent dans des cahiers, des présentations, des conversations ou simplement dans la tête de leurs auteurs, parce qu’il n’est pas raisonnable d’engager plusieurs mois de travail pour vérifier une intuition.

Lorsque ce coût baisse fortement, une hypothèse peut devenir un prototype et une mauvaise direction peut être abandonnée sans que l’expérience représente plusieurs semaines de travail.

Il devient rationnel de construire pour apprendre plutôt que de chercher à tout décider avant de commencer.

Et cela change aussi la nature des questions importantes. Si de plus en plus de choses deviennent techniquement accessibles, « est-ce possible ? » perd une partie de son importance. « Est-ce une bonne idée ? » en gagne.

La messagerie générale dans Flechis en est un exemple. Le fait qu’elle soit facile à ajouter ne dit rien sur l’opportunité de l’ajouter.

Plus la construction devient facile, plus le jugement devient visible.

L’optionnalité tardive

J’appelle cela l’optionnalité tardive : ne pas repousser une décision par indécision, mais éviter de la prendre avant qu’elle soit nécessaire lorsque l’on peut obtenir, entre-temps, de meilleures informations.

Il ne s’agit pas de refuser de choisir. Il s’agit d’enchaîner des décisions suffisamment petites et réversibles pour préserver plusieurs trajectoires jusqu’au moment où un engagement plus lourd devient justifié.

Le développement assisté par l’IA me semble être un cas particulièrement intéressant de cette logique.

Je n’ai pas besoin aujourd’hui de décider si Flechis doit devenir d’abord une application iPhone, une application Android ou demeurer une application web. Je peux attendre de mieux comprendre comment il sera utilisé.

Je n’ai pas besoin de décider immédiatement d’intégrer une messagerie parce qu’une personne me l’a suggéré.

Je n’ai même pas, pour le moment, besoin de décider si Flechis doit devenir une entreprise. Je peux continuer à apprendre.

Ce qui me frappe n’est donc pas seulement la vitesse du développement. C’est le déplacement du moment où il devient nécessaire de s’engager.

Le retour possible du petit logiciel

Cette évolution pourrait avoir une conséquence économique encore largement sous-estimée.

Depuis plusieurs décennies, produire un logiciel sérieux exige un minimum de capital, de compétences spécialisées et de coordination. Cela favorise naturellement certains types de projets.

Un logiciel qui peut desservir des millions de personnes peut justifier des investissements considérables. Un logiciel destiné à quelques centaines ou quelques milliers de personnes, beaucoup moins.

Il existe donc un seuil économique en dessous duquel de nombreux logiciels utiles ne sont tout simplement jamais produits : un système spécialisé pour une petite profession, un outil destiné à quelques municipalités ou une application parfaitement adaptée aux processus particuliers d’une organisation.

Le marché n’est pas nécessairement inexistant. Il est simplement trop petit relativement au coût de fabrication du logiciel.

Si ce coût diminue fortement, le seuil descend avec lui. Cela pourrait rendre viables davantage de logiciels spécialisés, mais aussi davantage d’entreprises qui n’ont aucune raison de devenir énormes.

Une entreprise comptant deux ou trois personnes et quelques milliers de clients peut être une excellente entreprise si son coût d’exploitation est suffisamment bas. Elle n’a pas besoin de devenir une plateforme mondiale. Elle n’a peut-être même pas besoin de capital-risque.

Cette possibilité ne doit pas être idéalisée. Le développement n’est qu’une partie du coût d’un produit : trouver des utilisateurs, les soutenir, protéger leurs données, respecter les règles et maintenir le service demeurent des tâches réelles. Mais en abaissant le coût du premier système utilisable, l’IA peut rendre explorables des marchés qui ne l’étaient pas auparavant.

C’est ici que mon expérience avec Flechis commence à me faire réfléchir à quelque chose de beaucoup plus large.

Et si Silicon Valley était aussi une conséquence du prix du logiciel ?

On décrit souvent Silicon Valley par sa culture : goût du risque, ambition, vitesse, capital-risque, volonté de changer le monde.

Mais le modèle qui s’y est développé correspond aussi à une structure de coûts.

Pour transformer une idée en entreprise technologique, il fallait historiquement engager beaucoup de ressources avant de savoir si elle fonctionnerait. Il fallait constituer une équipe, développer le produit, mettre en place l’infrastructure, puis chercher des utilisateurs.

Quelqu’un devait financer cette période. Le capital-risque a fourni une réponse extrêmement efficace à ce problème.

Mais son modèle économique impose ses propres contraintes. Comme beaucoup d’investissements échouent, les quelques entreprises qui réussissent doivent pouvoir produire des rendements très importants. Une entreprise qui a de bonnes chances de devenir petite, stable et rentable peut donc être une excellente entreprise sans être un investissement particulièrement intéressant pour un fonds de capital-risque. Josh Lerner et Ramana Nanda soulignent justement qu’une bande relativement étroite d’innovations correspond bien aux exigences du capital-risque institutionnel.²

Il existe d’ailleurs un précédent intéressant.

L’arrivée de l’infonuagique dans les années 2000 a fait baisser considérablement le coût initial de nombreuses jeunes entreprises Internet. Il n’était plus nécessaire d’acheter à l’avance une infrastructure dimensionnée pour une croissance encore hypothétique.

Une étude consacrée à l’arrivée d’AWS montre que les jeunes entreprises des secteurs les plus touchés ont obtenu environ 20 % moins de financement lors de leur première ronde, tandis que les investisseurs ont financé davantage d’expériences initiales. Pour les entreprises qui survivaient au moins trois ans, le capital total obtenu ne diminuait pas : les investissements importants arrivaient plus tard, une fois une partie de l’incertitude levée.³

L’infonuagique avait réduit le coût de l’infrastructure nécessaire pour essayer.

Je me demande si l’IA n’est pas en train de faire quelque chose de semblable au coût du travail nécessaire pour construire le logiciel lui-même.

Quand le capital arrive plus tard

Si une personne ou une très petite équipe peut désormais construire un produit fonctionnel, le déployer, le faire utiliser, découvrir ce qui ne fonctionne pas et peut-être même trouver ses premiers clients avant de chercher du financement, le rapport au capital change.

L’entrepreneur n’a plus nécessairement besoin de demander de l’argent pour découvrir si son idée fonctionne. Il peut effectuer une part beaucoup plus grande de cette découverte avant de chercher du financement.

Au lieu d’arriver devant un investisseur en disant essentiellement :

Voici mon idée. Donnez-moi les moyens de savoir si elle fonctionne.

il peut arriver avec :

Voici le produit. Voici ce que nous avons appris. Voici les utilisateurs. Maintenant, voulons-nous changer d’échelle ?

Le capital n’est pas éliminé. Il arrive plus tard.

Et cela aussi est une forme d’optionnalité tardive.

Le fondateur conserve plus longtemps l’option de poursuivre seul, de rester petit, de chercher du capital ou d’abandonner — et prend ces décisions avec davantage d’information.

Certains projets auront évidemment toujours besoin de sommes énormes. Les modèles fondamentaux d’intelligence artificielle, les semi-conducteurs, les infrastructures physiques ou les entreprises visant des centaines de millions d’utilisateurs n’appartiennent pas à cette logique.

Mais une grande partie du logiciel, oui.

Si les équipes nécessaires deviennent beaucoup plus petites et si le coût d’expérimentation continue de baisser, une partie de l’économie du logiciel pourrait progressivement se détacher du modèle qui a dominé Silicon Valley.

Non parce que le capital-risque aurait cessé de fonctionner, mais parce qu’un nombre croissant de projets pourraient ne plus avoir besoin de lui aussi tôt.

Le logiciel avant la décision

Je ne sais pas encore ce que deviendra Flechis.

Il est possible que le concept fonctionne très bien, qu’il évolue vers quelque chose de très différent ou que je découvre qu’il ne mérite pas d’être poursuivi.

Il y a quinze ans, j’aurais probablement dû avoir une opinion assez ferme sur cette question avant de justifier les ressources nécessaires pour aller beaucoup plus loin.

Aujourd’hui, je n’ai pas besoin de répondre tout de suite. Je peux construire avant de décider.

C’est peut-être là le changement le plus important.

Le prototype n’est plus seulement une étape vers le produit. Il peut devenir un moyen d’obtenir l’information nécessaire pour décider si le produit mérite d’exister.

Lorsque le coût d’essayer s’effondre, la meilleure stratégie n’est peut-être plus de chercher à prendre la bonne décision le plus tôt possible. Elle consiste peut-être à préserver suffisamment d’options pour pouvoir la prendre plus tard, lorsque l’on en sait davantage.

Références