Torras.ai

Je travaille depuis quelque temps avec un client sur un nouveau projet logiciel. Nous avons pris le temps d’échanger sur le problème, de comprendre le processus de travail et de concevoir ce que le système final devait accomplir.

À certains moments, je me suis demandé si nous n’avancions pas trop lentement. Dans le monde de la technologie, il est facile de penser que chaque semaine consacrée à la réflexion est une semaine perdue. Quelqu’un d’autre peut se lancer avant nous. Le marché peut évoluer. L’occasion peut disparaître.

Puis quelque chose d’inattendu s’est produit.

Lorsque nous avons été prêts à construire, les outils avaient changé. Je pouvais travailler avec Codex en utilisant GPT-5.6 Sol, le connecter à Chrome, lui permettre d’utiliser des applications de bureau grâce à Computer Use et lui donner accès à une plus grande partie de l’environnement où le travail réel s’effectue. Des tâches qui auraient auparavant nécessité des intégrations sur mesure, beaucoup de code d’interface et de nombreuses étapes manuelles sont devenues bien plus directes.

Nous avions commencé plus tard. Pourtant, il semblait soudain possible de terminer plus tôt.

Cela paraît contradictoire. C’est aussi une bonne description de l’époque technologique que nous vivons.

Pourquoi le deuxième vaisseau arrive en premier

Imaginons que l’humanité souhaite atteindre une planète lointaine.

Nous pourrions lancer aujourd’hui un vaisseau équipé du meilleur système de propulsion disponible. Il commencerait immédiatement son voyage et prendrait une avance précieuse.

Mais supposons que nous attendions dix ans. Pendant ce temps, la technologie de propulsion progresse de manière spectaculaire. Nous lançons un deuxième vaisseau qui voyage beaucoup plus vite que le premier. Il le dépasse quelque part entre la Terre et la destination, puis atteint la planète plusieurs années avant lui.

Le premier vaisseau est parti en premier. Le second est arrivé en premier.

Il ne s’agit pas seulement d’une expérience de pensée issue de la science-fiction. Ce problème a été étudié sous le nom de calcul d’attente, également décrit comme le piège des incitations lié au progrès. La question consiste à déterminer s’il vaut mieux partir avec la technologie disponible aujourd’hui ou attendre une technologie plus rapide susceptible de réduire le temps total nécessaire pour atteindre la destination.

Une étude ultérieure a étendu ce calcul aux voyages relativistes et l’a appliqué à d’éventuelles missions interstellaires. La question centrale restait la même : un vaisseau lancé plus tard pourrait-il dépasser une mission antérieure et arriver le premier ?

La logique fondamentale peut s’exprimer simplement :

Un lancement plus tardif l’emporte lorsque le temps économisé grâce à la nouvelle technologie est supérieur au temps passé à l’attendre.

C’est le calcul d’attente de l’IA.

Le logiciel dispose désormais d’une technologie de propulsion

Pendant une grande partie de l’histoire du logiciel, commencer plus tôt créait généralement un avantage durable. Même si les outils progressaient au cours du projet, l’équipe qui comprenait déjà le problème, avait écrit le code et atteint le marché avait accumulé quelque chose de difficile à rattraper.

Cette hypothèse devient moins fiable.

L’IA ne se contente pas d’accélérer légèrement les tâches de programmation existantes. Elle modifie les parties d’un projet qui doivent réellement être programmées. Un agent de programmation performant peut inspecter un dépôt, en comprendre les conventions, modifier plusieurs fichiers, exécuter des tests, diagnostiquer des erreurs et vérifier le résultat. La connexion à Chrome lui permet de travailler avec des sites web et le contexte de sessions déjà ouvertes dans le navigateur. Computer Use étend cette portée aux applications graphiques lorsque les outils en ligne de commande et les intégrations structurées ne suffisent pas.

Chacune de ces capacités transforme l’économie de la mise en œuvre.

Une intégration qui exigeait autrefois une API, un processus d’authentification, un mécanisme de synchronisation, une gestion des erreurs et une interface personnalisée peut désormais commencer par un agent utilisant l’application existante. Une fonctionnalité qui nécessitait plusieurs semaines de programmation peut devenir une tâche clairement définie, réalisée et testée en quelques jours. Un prototype auparavant trop coûteux à justifier peut devenir suffisamment abordable pour être construit dans le seul but d’apprendre.

Le nouveau vaisseau n’est pas seulement plus rapide. Il peut avoir besoin de moins d’infrastructure pour atteindre la même destination.

La réflexion faisait partie du voyage

Il existe une distinction importante entre commencer le projet et commencer la mise en œuvre.

Les conversations avec mon client n’étaient pas une attente passive. Nous cherchions à identifier la véritable destination. Nous déterminions les problèmes importants, les étapes pouvant être automatisées, les endroits où le jugement humain devait rester présent et la forme que prendrait un résultat utile.

Ces connaissances ne sont pas devenues obsolètes lorsque la technologie a changé. Elles ont pris davantage de valeur, car les nouveaux outils pouvaient les mettre en pratique plus rapidement.

Si nous avions commencé à programmer immédiatement, nous aurions peut-être inscrit des hypothèses dans l’architecture avant de comprendre le processus. Nous aurions aussi pu créer des mécanismes sur mesure pour des problèmes que les nouveaux outils d’IA peuvent maintenant traiter directement. Commencer plus tôt aurait produit davantage de code, mais pas nécessairement un résultat plus rapide.

Cela conduit à un principe qui me semble de plus en plus adapté aux projets d’IA :

Commencez à apprendre tôt. Engagez-vous tard.

Commencez le plus tôt possible à découvrir les besoins du client, cartographier les processus, préparer les données, analyser les risques et définir les critères de réussite. Ces activités clarifient la destination et conservent généralement leur valeur.

Soyez plus prudent face aux engagements importants, rigides et dépendants d’une technologie précise. Lorsque les capacités sous-jacentes progressent rapidement, une architecture conçue trop tôt peut devenir le vaisseau lent qu’un système plus simple finira par dépasser.

Le premier vaisseau n’est pas toujours inutile

Le calcul d’attente peut donner lieu à une interprétation séduisante mais dangereuse : ne jamais rien construire, puisqu’un meilleur outil finira toujours par apparaître.

C’est le piège des incitations.

Si nous suivons indéfiniment cette logique, aucun vaisseau ne quitte jamais la Terre. Il y aura toujours un autre modèle, un autre framework et une nouvelle capacité à l’horizon.

Les premiers systèmes peuvent également créer de la valeur même s’ils finissent par être dépassés. Un prototype peut révéler une exigence cachée. Un processus manuel peut produire des exemples d’entraînement. Un lancement limité peut instaurer la confiance des utilisateurs. Une intégration imparfaite peut mettre au jour le véritable goulot d’étranglement opérationnel.

En ce sens, le premier vaisseau peut renvoyer des informations précieuses vers la Terre.

L’erreur n’est pas de se lancer tôt. Elle consiste à traiter chaque premier lancement comme s’il s’agissait du véhicule définitif.

Dans les périodes de changement rapide, les premières versions devraient être conçues comme des sondes : petites, réversibles et destinées à produire des connaissances. Elles doivent nous aider à déterminer ce qui mérite un engagement plus important. Le vaisseau générationnel vient ensuite.

Un calcul d’attente pratique pour les projets d’IA

Nous ne pouvons pas prévoir le rythme exact du développement de l’IA, mais nous pouvons poser de meilleures questions avant de nous engager dans une construction :

• La destination est-elle claire ? Si le problème du client reste vague, une meilleure technologie ne sauvera pas le projet.
• À quelle vitesse la technologie nécessaire progresse-t-elle ? Attendre est plus pertinent lorsqu’une capacité manquante devient visiblement moins coûteuse, plus fiable ou plus simple à intégrer.
• Que pouvons-nous apprendre dès maintenant ? Les entretiens, prototypes, expériences et collectes de données peuvent faire avancer le projet sans nous enfermer dans une architecture.
• Dans quelle mesure la décision est-elle réversible ? Un petit prototype est facile à remplacer. Une grande plateforme personnalisée, une migration ou un contrat pluriannuel ne le sont pas.
• Mesurons-nous l’effort ou l’arrivée ? Commencer le développement plus tôt peut augmenter la quantité de travail accomplie tout en retardant le moment où le client obtient le résultat souhaité.

La dernière question est la plus importante. Les équipes logicielles mesurent naturellement l’activité : exigences rédigées, tickets fermés, intégrations terminées et lignes de code livrées. Les clients, eux, se préoccupent de l’arrivée.

Le processus est-il devenu plus rapide ? Les erreurs ont-elles diminué ? Les revenus ont-ils augmenté ? Les personnes ont-elles cessé d’effectuer un travail que le système pouvait prendre en charge ? L’entreprise a-t-elle acquis une capacité qu’elle ne possédait pas auparavant ?

Un projet commencé plus tard mais qui atteint ces résultats en premier est le projet le plus rapide.

Rivaliser avec un vaisseau qui n’a pas encore décollé

La réalité inconfortable est que chaque produit d’IA est désormais en concurrence, au moins en partie, avec la technologie future.

Une équipe peut passer un an à développer une fonctionnalité spécialisée, puis voir un modèle généraliste acquérir la même capacité. Une interface soigneusement conçue peut devenir inutile lorsqu’un agent sait utiliser l’application d’origine. Une couche d’intégration complexe peut perdre sa valeur lorsque les outils peuvent circuler de manière sécurisée entre les systèmes au nom de l’utilisateur.

Cela ne signifie pas que les éditeurs de logiciels doivent cesser de construire. Cela signifie qu’ils doivent construire là où la valeur est la plus durable : contexte propriétaire, relations avec les clients, processus fiables, distribution, expertise métier, systèmes d’évaluation et compréhension précise du résultat recherché.

La mise en œuvre doit être suffisamment modulaire pour pouvoir remplacer son moteur lorsqu’un moteur plus rapide devient disponible.

Dans mon projet avec ce client, commencer plus tard ne signifiait pas ne rien faire. Cela signifiait qu’au moment de décoller, nous disposions d’une destination plus claire et d’un vaisseau beaucoup plus rapide.

C’est l’opportunité créée par le calcul d’attente de l’IA. L’objectif n’est pas d’attendre le plus longtemps possible, ni de construire le plus tôt possible.

Il s’agit de reconnaître le moment où l’attente cesse de raccourcir le voyage et commence à le retarder.

Commencez à apprendre tôt. Gardez les premières expériences modestes. Préservez ce qui est durable. Retardez les décisions irréversibles. Puis, lorsque la technologie est suffisamment performante et que la destination est claire, lancez-vous.

Dans un monde où la technologie accélère, le premier à partir n’est pas toujours le premier à arriver.