Le futur du développement a commencé hier

Ce n’est pas demain que le monde du développement va changer. Ce n’est même pas aujourd’hui.

C’était hier.

L’année dernière encore, une grande partie des démonstrations autour du développement assisté par IA consistait à générer une interface : une landing page, un dashboard, quelques cartes, une sidebar et deux graphiques.

C’était impressionnant, mais cela restait souvent une démonstration visuelle.

Aujourd’hui, ce que je vois passer est différent. Des jeux complets commencent à émerger en quelques heures ou quelques jours. Des outils spécialisés sont développés pour un seul besoin. Des éditeurs, moteurs, générateurs de niveaux, systèmes physiques, outils 3D et applications métier apparaissent en permanence.

Ils sont même devenus trop nombreux pour que je puisse raisonnablement les citer tous.

Le vrai changement : accéder au savoir et l’exécuter

Ce qui me semble révolutionnaire n’est finalement pas que l’intelligence artificielle sache écrire du code.

C’est la disparition progressive du délai entre une question et son exécution.

Je veux comprendre comment déplacer correctement un objet autour d’une sphère ? Je peux accéder immédiatement aux vecteurs, quaternions, transformations et méthodes utiles, puis les tester directement dans mon jeu.

Je veux ajouter de la physique ? Le moteur existe déjà, sa documentation existe, les principes mathématiques existent, et l’agent peut m’aider à relier tout cela à mon architecture.

Je veux produire un outil spécifique à mon projet ? Je ne dois plus nécessairement passer plusieurs semaines à apprendre chaque détail avant d’obtenir une première version fonctionnelle.

La connaissance existait déjà. Ce qui vient de changer radicalement, c’est son accessibilité opérationnelle.

On a d’abord construit des outils pour construire

Je pensais depuis le début qu’une première phase serait consacrée à cela : utiliser les LLM pour fabriquer des outils permettant ensuite de fabriquer d’autres choses.

Cette phase est désormais bien installée.

Les DCC, pour Digital Content Creation, ne sont plus nécessairement de gigantesques logiciels généralistes. On voit apparaître des outils beaucoup plus spécialisés : éditeurs de scènes, générateurs d’assets, interfaces de création procédurale, outils de placement, pipelines de textures ou environnements construits autour d’un seul projet.

Et désormais, certains de ces outils intègrent directement un agent capable de participer à leur utilisation.

OpenAI pousse cette logique assez loin avec Codex. L’outil est aujourd’hui présenté comme un agent capable de prendre en charge une tâche d’ingénierie de bout en bout : modifier une codebase, développer une fonctionnalité, effectuer une migration, lancer les tests et préparer le résultat pour révision. Source : OpenAI — Codex.

Avec Symphony, OpenAI va encore plus loin dans l’orchestration. Dans le projet interne ayant conduit à cet outil, l’équipe explique avoir imposé une règle particulière : le dépôt devait être construit sans code écrit directement par un humain, chaque ligne étant générée avec Codex. Symphony a ensuite été développé pour orchestrer plusieurs agents autour du travail à accomplir. Source : OpenAI — Symphony.

C’est probablement le prochain outil que je vais tester.

La 3D montre particulièrement bien ce qui se passe

Dans le jeu vidéo, le changement devient spectaculaire parce que beaucoup de briques existaient déjà.

Three.js permet depuis longtemps de construire un monde 3D dans un navigateur. Des moteurs comme Cannon.js ou cannon-es apportent la physique. Les mathématiques nécessaires aux trajectoires, collisions, caméras ou générations procédurales sont documentées depuis des années.

Mais auparavant, utiliser correctement toutes ces connaissances demandait énormément de temps.

Aujourd’hui, on peut les assembler presque au rythme où l’on formule les problèmes.

À cela viennent maintenant s’ajouter des outils capables de produire directement les éléments nécessaires au monde 3D.

Microsoft développe par exemple TRELLIS.2, un pipeline capable de transformer une image en asset 3D exportable. Le projet propose notamment des sorties GLB et différentes résolutions de génération. Source : Microsoft — TRELLIS.2.

Un projet comme img2threejs prend une direction différente et particulièrement intéressante : reconstruire l’objet visible dans une image sous la forme de code Three.js procédural, lisible et modifiable, plutôt que de simplement produire un fichier mesh. Source : img2threejs.

Nous sommes donc en train de passer d’un monde où l’on cherchait pendant des heures le bon asset, le bon tutoriel ou le bon morceau de code, à un monde où une grande partie de ces éléments peut être comprise, adaptée ou produite au moment exact où elle devient nécessaire.

Deux heures ne remplacent pas vingt ans

Il faut évidemment rester raisonnable.

Un jeu développé en deux heures ne remplace pas vingt années de développement. Il ne possède pas automatiquement le contenu, le polish, la direction artistique, l’équilibrage et les milliers de décisions accumulées dans une grande production.

Mais ce n’est pas vraiment la comparaison intéressante.

Ce qui me frappe, c’est qu’en deux heures de développement intensif, il devient possible d’atteindre un niveau de réalisation qui aurait auparavant demandé plusieurs jours, parfois plusieurs semaines, simplement parce qu’il fallait chercher, apprendre, tester, comprendre les API et résoudre successivement chaque problème.

Ce temps de recherche n’a pas totalement disparu.

Il a été compressé.

Le dashboard aussi a changé

C’est exactement la même chose pour une application métier.

Un dashboard n’est pas une collection de jolies cartes avec des chiffres.

Derrière l’interface se trouvent des données, des relations, des permissions, des filtres, des migrations, de la journalisation, des tests, des règles métier et parfois une architecture entière.

Là encore, ce ne sont plus uniquement les pixels qui peuvent être produits rapidement.

C’est désormais la structure qui se trouve derrière.

Et maintenant ?

Plus je développe de projets, moins j’ai l’impression que la véritable révolution soit la génération automatique de code.

Le code n’est que la partie visible.

La révolution est peut-être simplement celle-ci :

nous avons réduit de manière brutale la distance entre savoir quelque chose, comprendre comment cela fonctionne et être capable de l’exécuter.

Une personne curieuse peut aujourd’hui toucher à la physique, au rendu 3D, aux bases de données, aux shaders, à la génération procédurale, à l’architecture logicielle ou à des domaines qu’elle aurait auparavant mis des mois à approcher.

Cela ne remplace pas l’expertise.

Mais cela permet d’y accéder, de l’expérimenter et surtout de produire avec elle beaucoup plus rapidement.

Et quand des milliers de développeurs, créateurs et simples curieux obtiennent simultanément cette capacité, le résultat devient visible partout : une quantité complètement folle de jeux, d’outils et d’applications.

Voilà pourquoi je ne pense plus que nous attendions une révolution du développement.

Elle a déjà commencé.

1. OpenAI — Codex : https://openai.com/codex/
2. OpenAI — Open source Codex orchestration with Symphony : https://openai.com/index/open-source-codex-orchestration-symphony/
3. Microsoft — TRELLIS.2 : https://github.com/microsoft/TRELLIS.2
4. img2threejs — Image to procedural Three.js : https://github.com/img2threejs/img2threejs