OpenAI a surpris le monde du développement avec Sora, une application qui a été créée en un temps record grâce à l’intelligence artificielle. Quatre ingénieurs ont dirigé cette innovation, utilisant Codex pour transcender les approches traditionnelles de codage et redéfinir le processus de développement rapide.
L’équipe de développement de Sora, l’application de génération de vidéos d’OpenAI, a fourni des instructions précises pour permettre à l’IA de « traduire » la version iOS
Dans le développement logiciel, une règle tacite (réellement écrite, appelée la Loi de Brooks) stipule que « l’ajout de main-d’œuvre à un projet logiciel en retard le retarde encore plus ». Pour lancer une application complexe, stable et massive dans des délais records, la logique traditionnelle exige un grand nombre d’ingénieurs et des mois de planification.
OpenAI a prouvé que cette logique traditionnelle est en train de s’essouffler.
En novembre dernier, la société a lancé Sora sur Android. L’application s’est immédiatement hissée au sommet du Google Play Store, et dans les 24 premières heures, les utilisateurs ont généré plus d’un million de vidéos. Si cela marque le succès attendu d’un produit viral, la nouveauté réside dans comment elle a été réalisée.
Un groupe de quatre ingénieurs seulement a bâti la version de production de Sora pour Android en 28 jours. Le prototype fonctionnel était prêt en seulement 18 jours. Comment est-ce possible ? Parce que ces quatre ingénieurs ne travaillaient pas seuls. Ils dirigeaient une légion d’agents IA alimentés par Codex (une version précoce de GPT-5.1).
Ignorer les règles pour gagner en rapidité
Lorsque Sora a été lancée sur iOS et a connu une explosion d’utilisateurs, la pression pour arriver sur Android était immense. Normalement, il aurait fallu embaucher une grande équipe de développeurs Android, coordonner des sprints, concevoir des architectures et supposer que le lancement prendrait des mois.
Au lieu de cela, OpenAI a décidé de s’appuyer sur une extrême agilité. Ils ont gardé l’équipe petite afin d’éviter la bureaucratie et la surcharge de communication, mais ont équipé chaque ingénieur avec Codex. Au cours du processus, ils ont consommé environ 5 000 millions de tokens.
Le résultat est une application avec un taux de stabilité de 99,9 % construite en moins d’un mois. Ils n’ont pas utilisé de modèle secret inaccessibilité; ils se sont servis de la même technologie désormais disponible pour les développeurs via l’API et les outils d’OpenAI.
Codex est le « Ingénieur Senior » nécessitant supervision
Patrick Hum et RJ Marsan, du département technique d’OpenAI, expliquent que la clé n’a pas été de demander à l’IA de « créer l’application », mais de considérer Codex comme un nouvel ingénieur senior nouvellement embauché.
Son potentiel est surhumain : il connaît tous les langages, écrit des tests unitaires à une vitesse fulgurante et peut lire des bases de code entières en quelques secondes. Toutefois, comme tout nouvel arrivant, il manque de contexte. Codex excelle dans l’exécution brute :
- Couvrement des tests : il adore écrire des tests unitaires, ce qui a aidé à prévenir les régressions.
- Travail en parallèle : les ingénieurs pouvaient exécuter plusieurs sessions de Codex simultanément. Pendant qu’une instance corrigeait un bug, une autre refactorisait un module et une nouvelle en concevait une autre fonction.
- Traduction de logique : il comprend Swift (iOS) et peut écrire son équivalent en Kotlin (Android) tout en maintenant la sémantique.
Cependant, il a besoin de directives. Codex ne peut pas « voir » l’application. Il ne sait pas si une animation semble rugueuse ou si un flux utilisateur est confus. Et, s’il est laissé seul, il a tendance à privilégier que les choses « fonctionnent » plutôt que d’assurer un code propre à long terme.
Pour y remédier, l’équipe a créé des fichiers dans le dépôt qui étaient, fondamentalement, des manuels d’instructions pour l’IA : « Voilà comment nous procédons ici », « Exécute toujours cette commande avant d’effectuer un commit », « Utilise cette architecture spécifique ».
Planifier avant de programmer
Logo d’OpenAI sur un smartphone
L’équipe a rapidement découvert que demander à l’IA « de construire cet écran » donnait des résultats médiocres. Le code compilait, mais l’architecture était chaotique.
Ils ont modifié leur approche. Avant d’écrire une seule ligne de code, ils demandaient à Codex de lire les fichiers, de comprendre le système et de proposer un plan.
« Lis ces modèles et ces points de terminaison dans le code iOS et propose un plan pour mettre en place un comportement équivalent sur Android en utilisant notre client API existant ».
Ce n’est qu’une fois le plan (agissant comme un mini-document de conception) approuvé par les humains que Codex commençait à l’exécuter. Cela a permis de laisser l’IA travailler sans supervision pendant de longues périodes, car ils savaient déjà ce qu’elle allait faire, pas seulement comment.
Le bottleneck (goulot d’étranglement) n’était plus « écrire du code » mais « réviser du code et prendre des décisions ». Les ingénieurs humains sont passés de solistes pianotant sur des claviers à chefs d’orchestre gérant plusieurs fils de travail simultanément.
La fin de Flutter et React Native ?
Il existe une lecture fascinante dans ce cas d’étude qui pourrait transformer le développement mobile pour l’avenir. Pendant des années, nous avons utilisé des frameworks multiplateformes comme React Native ou Flutter pour gagner du temps, en écrivant le code une seule fois et en l’exécutant sur iOS et Android, au détriment d’un certain rendement ou d’une sensation native.
OpenAI plaisante en disant qu’ils ont réinventé le concept multiplateforme. « Oubliez React Native ou Flutter; l’avenir des plateformes croisées repose uniquement sur Codex ».
Ils n’ont pas utilisé une couche d’abstraction. Ils ont utilisé l’IA pour traduire. Ils donnaient à Codex le code natif iOS (Swift) et lui demandaient d’écrire le code natif pour Android (Kotlin). La logique restait la même, seule la syntaxe changeait. Cela leur a permis d’avoir deux applications 100 % natives, avec la performance et la qualité que cela engendre, mais avec la rapidité de développement d’une seule base de code.
Conclusion : La nouvelle ère de l’ingénierie
L’histoire de Sora pour Android nous offre une leçon claire : l’IA ne remplace pas l’ingénieur, mais éléve son niveau. Sundar Pichai, PDG d’Alphabet, a déjà plaidé pour ce type de stratégies, et OpenAI a été l’une des premières à appliquer ces techniques au développement d’un produit à grande échelle.
Le travail « bâtard » (positionner des boutons, connecter des API, écrire du code répétitif) disparaît. L’ingénieur de demain (et du présent, dans le cas d’OpenAI) se consacre à la conception de systèmes, assurant la qualité, définissant l’expérience utilisateur et orchestrant l’IA.
Si quatre personnes peuvent réaliser en 18 jours ce qui nécessitait auparavant un département entier, la question n’est plus de savoir s’il faut utiliser l’IA dans son flux de travail. La question est de savoir ce que vous allez faire avec tout ce temps que vous allez gagner.