Comment nous avons utilisé Codex pour créer Sora pour Android en 28 jours

À compter du 26 avril 2026, Sora n’est plus disponible.

En novembre, nous avons lancé l’appli Sora pour Android à l’échelle mondiale, offrant à toute personne possédant un appareil Android la possibilité de transformer un court prompt en une vidéo vivante. Le jour du lancement, l’application a atteint la première place sur le Play Store. Les utilisateurs Android ont généré plus d’un million de vidéos au cours des premières 24 heures.

Derrière le lancement se cache une histoire : la version initiale de l’appli Android de production de Sora a été construite en 28 jours, grâce au même agent que celui mis à la disposition de toute équipe ou de tout développeur : Codex.

Du 8 octobre au 5 novembre 2025, une équipe d’ingénierie Lean travaillant aux côtés de Codex et consommant environ 5 milliards de tokens a livré Sora pour Android, du prototype au lancement mondial. Malgré son ampleur, l’application présente un taux de stabilité de 99,9 % et une architecture dont nous sommes fiers. Si vous vous demandez si nous avons utilisé un modèle secret, sachez que nous avons employé une version précoce du modèle GPT‑5.1‑Codex, la même version que n’importe quel développeur ou entreprise peut utiliser aujourd’hui via CLI, une extension IDE ou une application web.

Lorsque Sora a été lancée sur iOS, son utilisation a explosée. Les gens ont immédiatement commencé à générer un flux de vidéos. En revanche, sur Android, nous ne disposions que d’un petit prototype interne et d’un nombre croissant d’utilisateurs préinscrits sur Google Play.

Une réaction courante à un lancement à enjeux élevés et à délais serrés est d’accumuler les ressources et d’ajouter des processus. Une appli de production de cette envergure et de cette qualité impliquerait normalement de nombreux ingénieurs travaillant pendant des mois, ralentis par la coordination. 

L’architecte informatique américain Fred Brooks a lancé un avertissement devenu célèbre : « Ajouter davantage de personnes à un projet logiciel en retard ne fait que le retarder davantage. » En d’autres termes, lorsque vous essayez de livrer rapidement un projet complexe, ajouter plus d’ingénieurs peut souvent ralentir l’efficacité en augmentant le travail de communication supplémentaire, la fragmentation des tâches et les coûts d’intégration. Nous nous sommes appuyés sur cette idée au lieu de l’ignorer ; nous avons constitué une équipe solide de quatre ingénieurs, tous équipés de Codex pour augmenter considérablement l’impact de chaque ingénieur. 

En travaillant de cette manière, nous avons livré un build interne de Sora pour Android aux employés en 18 jours et l’avons lancée publiquement 10 jours plus tard. Nous avons maintenu un niveau élevé de pratiques d’ingénierie Android, investi dans la maintenabilité et imposé à l’application le même niveau de fiabilité que celui que l’on attendrait d’un projet plus traditionnel. (Nous continuons également à utiliser Codex de manière intensive pour faire évoluer l’application en lui apportant de nouvelles fonctionnalités.)

Pour comprendre comment nous avons travaillé avec Codex, il est bon de connaître ses points forts et les domaines où il nécessite d’être guidé. Le traiter comme un ingénieur senior récemment embauché était une bonne approche. Les capacités de Codex nous ont permis de consacrer plus de temps à diriger et à revoir le code plutôt qu’à l’écrire nous-mêmes.

Les domaines dans lesquels Codex a besoin d’être guidé

1. Codex n’est pas encore très performant pour déduire ce qui ne lui a pas été communiqué (par exemple, vos modèles d’architecture préférés, votre stratégie produit, le comportement réel des utilisateurs et les normes ou raccourcis internes).
2. De même, Codex ne pouvait pas voir l’appli fonctionner réellement : il ne pouvait pas ouvrir Sora sur un appareil, remarquer qu’un défilement semblait incorrect ou sentir que la navigation était source de confusion. Seule notre équipe pouvait couvrir ces tâches relevant de l’expérience utilisateur.
3. Chaque instance nécessite un travail d’onboarding. Partager le contexte avec des objectifs clairs, des contraintes et des directives sur « notre façon de procéder » a été essentiel pour que Codex exécute correctement les tâches.
4. Dans le même ordre d’idées, Codex a eu du mal avec le jugement architectural approfondi : laissé à lui-même, il aurait pu introduire un modèle de vue supplémentaire là où nous voulions vraiment étendre un modèle existant ou insérer dans la couche UI une logique qui appartenait clairement à un référentiel. Son instinct est de faire fonctionner quelque chose, pas de privilégier la propreté à long terme.

Nous avons trouvé utile que Codex créér et maintienne une quantité généreuse de fichiers AGENT.md dans l’ensemble de la base de code. Cela a rendu facile l’application des mêmes conseils et bonnes pratiques d’une session à l’autre. Par exemple, pour s’assurer que Codex écrivait du code conformément à nos directives de style, nous avons ajouté ce qui suit à notre fichier AGENTS.md de niveau supérieur :

Les domaines dans lesquels Codex excelle

1. Lire et comprendre rapidement de grandes bases de code : Codex connaît pratiquement tous les principaux langages de programmation, ce qui facilite l’exploitation des mêmes concepts sur de nombreuses plateformes sans abstractions complexes.
2. Couverture des tests : Codex est (uniquement) enthousiaste à l’idée de rédiger des tests unitaires pour couvrir une large variété de cas. Tous les tests n’étaient pas approfondis, mais l’étendue de la couverture permettait d’éviter les régressions. 
3. Application des commentaires : de la même manière, Codex réagit bien aux commentaires. Lorsque l’intégration continue échoue, nous pouvons coller la sortie de journal dans un prompt et demander à Codex de proposer des corrections.
4. Exécution massivement parallèle et jetable : la plupart ne pousseront pas les limites du nombre de sessions qu’ils pourraient réellement exécuter simultanément. Il est tout à fait possible de tester plusieurs idées en parallèle et de considérer le code comme jetable.
5. Offrir une nouvelle perspective : lors des discussions de conception, nous avons utilisé Codex comme outil génératif pour explorer les points de défaillance potentiels et découvrir de nouvelles manières de résoudre un problème. Par exemple, alors que nous concevions des optimisations de mémoire pour le lecteur vidéo, Codex a examiné plusieurs SDK pour proposer des approches que nous n’aurions pas eu le temps d’explorer. Les informations issues de la recherche de Codex se sont révélées inestimables pour réduire l’empreinte mémoire dans l’application finale.
6. Permettre un travail à plus forte valeur ajoutée   dans la pratique, nous avons fini par passer plus de temps à revoir et à diriger le code qu’à l’écrire nous-mêmes. Cela dit, Codex est également très performant dans la révision de code, détectant souvent des bugs avant qu’ils ne soient fusionnés, ce qui améliore la fiabilité.

Une fois ces caractéristiques reconnues, notre modèle de travail est devenu plus simple. Nous nous sommes appuyés sur le Codex pour effectuer une grande partie des tâches lourdes à l’intérieur de modèles bien compris et de champs d’application bien délimités, tandis que notre équipe s’est concentrée sur l’architecture, l’expérience utilisateur, les changements systémiques et la qualité finale.

Même la meilleure nouvelle recrue senior n’a pas immédiatement le recul nécessaire pour faire des compromis à long terme. Pour tirer parti de Codex et s’assurer que son travail était robuste et maintenable, il était essentiel que nous supervisions nous-mêmes la conception des systèmes de l’application et les principaux compromis. Cela comprenait la conception de l’architecture de l’appli, la modularisation, l’injection de dépendances et la navigation ; nous avons également mis en œuvre l’authentification et les flux de réseau de base. 

À partir de cette base, nous avons développé quelques fonctionnalités représentatives de bout en bout. Nous avons utilisé les règles que nous souhaitions que l’ensemble de la base de code respecte et avons documenté les modèles à l’échelle du projet au fur et à mesure. En indiquant au Codex des caractéristiques représentatives, il a pu travailler de manière plus indépendante dans le respect de nos normes. Pour un projet que nous estimons avoir été rédigé à 85 % par Codex, une base soigneusement planifiée a évité des retours en arrière et des refactorisations coûteuses. C’était l’une des décisions les plus importantes que nous ayons prises. 

L’idée n’était pas de faire « quelque chose qui fonctionne » le plus rapidement possible, mais plutôt de créer « quelque chose qui fonctionne comme nous le souhaitons ». Il existe de nombreuses manières « correctes » d’écrire du code. Nous n’avions pas besoin de dire à Codex exactement quoi faire ; nous devions montrer à Codex ce qui est « correct » dans notre équipe à nous. Une fois notre point de départ et notre manière de construire bien établis, Codex était prêt à commencer.

Pour voir ce qui se passerait, nous avons essayé de demander : « Construis l’appli Sora Android à partir du code iOS. », mais nous avons rapidement abandonné cette idée. Ce que Codex créait fonctionnait techniquement, mais l’expérience utilisateur était en dessous de la moyenne. Et sans une compréhension claire des points de terminaison, des données et des parcours des utilisateurs, le code à un coup de Codex était peu fiable (même sans utiliser un agent, il est risqué de fusionner des milliers de lignes de code). 

Nous avons émis l’hypothèse que Codex prospérerait dans une sandbox d’exemples bien écrits, et nous avions raison. Demander à Codex de « construire cet écran de paramètres » avec presque aucun contexte s’est avéré peu fiable. Demander à Codex de « construire cet écran de paramètres en utilisant la même architecture et les mêmes modèles que cet autre écran que tu viens de voir » a bien mieux fonctionné. Les humains ont pris les décisions structurelles et défini les invariants ; Codex a ensuite rempli de grandes quantités de code à l’intérieur de cette structure.

L’étape suivante pour tirer le meilleur parti des capacités de Codex a consisté à lui permettre de travailler sur de longues périodes (récemment, plus de 24 heures d’affilée⁠), sans supervision.

Au début de l’utilisation de Codex, nous avons rapidement adopté des prompts tels que  : « Voici la fonctionnalité. Voici des fichiers. Construis-la, s’il te plaît. » Parfois, cela fonctionnait, mais le plus souvent, cela produisait du code qui compilait techniquement, tout en s’écartant de notre architecture et de nos objectifs.

Nous avons donc modifié le flux de travail. Pour tout changement non trivial, nous avons d’abord demandé à Codex de nous aider à comprendre comment le système et le code fonctionnent. Par exemple, nous lui demandions de lire un ensemble de fichiers connexes et de résumer le fonctionnement de cette fonctionnalité ; par exemple, comment les données circulent depuis l’API à travers la couche de référentiel, le modèle de vue et l’interface utilisateur. Ensuite, nous corrigions ou affinions sa compréhension. Par exemple, nous indiquions qu’une abstraction particulière appartient réellement à une couche différente ou qu’une classe donnée existe uniquement pour le mode hors ligne et ne devrait pas être étendue.

Comme vous le feriez pour un nouveau coéquipier très compétent, nous avons travaillé avec Codex pour créer un plan de mise en œuvre solide. Ce plan ressemblait souvent à un document de conception miniature indiquant quels fichiers devaient être modifiés, quels nouveaux états devaient être introduits et comment la logique devait s’enchaîner. Ce n’est qu’ensuite que nous demandions à Codex de commencer à appliquer le plan, étape par étape. Un conseil utile : pour les tâches très longues, lorsque nous atteignions la limite de notre fenêtre contextuelle, nous demandions à Codex d’enregistrer son plan dans un fichier, ce qui nous permettait d’appliquer les mêmes directives dans toutes les instances.

Cette boucle de planification supplémentaire s’est avérée utile. Cela nous a permis de laisser Codex s’exécuter « sans supervision » pendant de longues périodes, car nous connaissions ses plans. Cela a facilité la révision de code, car nous pouvions vérifier l’implémentation par rapport à notre plan, plutôt que de lire un diff sans contexte. Et lorsqu’il y avait un problème, nous pouvions d’abord déboguer le forfait et ensuite le code. 

Cette dynamique s’apparente à la manière dont un bon document de conception donne confiance à un responsable technique dans le cadre d’un projet. Nous ne nous contentions pas de générer du code : nous produisions du code qui soutenait une feuille de route commune.

Au plus fort du projet, nous organisions souvent plusieurs sessions Codex en parallèle. L’un travaillait sur la lecture, un autre sur la recherche, un autre sur la gestion des erreurs, et parfois un autre sur les tests ou les refactorisations. Cela ressemblait moins à l’utilisation d’un outil et plus à la gestion d’une équipe.

Chaque session nous faisait régulièrement un compte rendu des progrès réalisés. L’un pouvait dire « J’ai fini de préparer ce module ; voici ce que je propose », tandis qu’un autre pouvait proposer un grand diff pour une nouvelle fonctionnalité. Chacun nécessitait de l’attention, des commentaires et une révision. C’était étrangement similaire à être un chef d’équipe technique encadrant plusieurs nouveaux ingénieurs progressant tous et ayant tous besoin de conseils.

Le résultat a été un flux collaboratif. La capacité brute de codage de Codex nous a libérés de beaucoup de saisie manuelle. Nous avons eu plus de temps pour réfléchir à l’architecture, lire attentivement les pull requests et tester l’application. 

En même temps, cette vitesse supplémentaire signifiait que nous avions toujours quelque chose en attente dans notre file de révision. Codex n’a pas été bloqué par le changement de contexte, mais nous l’avons été. Notre goulot d’étranglement dans le développement est passé de l’écriture de code à la prise de décisions, aux commentaires et à l’intégration des modifications.

C’est là que les idées de Brooks trouvent un nouvel écho. Vous ne pouvez pas simplement ajouter des sessions Codex et vous attendre à des accélérations linéaires, pas plus que vous ne pouvez continuer à ajouter des ingénieurs à un projet et espérer que le calendrier se réduise linéairement. Chaque « paire de mains » supplémentaire, même virtuelle, ajoute une surcharge de coordination. Nous étions devenus le chef d’orchestre d’un orchestre plutôt que simplement des solistes plus rapides.

Nous avons commencé notre projet avec un atout majeur : Sora avait déjà été lancé sur iOS. Nous avons fréquemment orienté Codex vers les bases de code iOS et backend pour l’aider à comprendre les exigences et contraintes clés. Tout au long du projet, nous plaisantions en disant que nous avions réinventé l’idée d’un framework multiplateforme. Oubliez React Native ou Flutter ; l’avenir du développement multiplateforme, c’est Codex.

Derrière cette boutade se cachent deux principes :

1. La logique est portable. Que le code soit écrit en Swift ou en Kotlin, la logique d’application sous-jacente – modèles de données, appels réseau, règles de validation, logique Business – reste la même. Codex est très performant pour lire une implémentation en Swift et produire un équivalent en Kotlin qui conserve la sémantique.
2. Des exemples concrets offrent un contexte puissant. Une nouvelle session Codex capable de montrer « voici exactement comment cela fonctionne sur iOS » et « voici l’architecture Android » est bien plus efficace qu’une session qui ne repose que sur des descriptions en langage naturel.

En appliquant ces principes, nous avons mis à disposition les référentiels iOS, backend et Android dans le même environnement. Nous avons donné à Codex des prompts tels que :

« Lis ces modèles et points de terminaison dans le code iOS, puis propose un plan pour implémenter le comportement équivalent sur Android en utilisant notre client API et nos classes de modèles existants. »

Une petite astuce utile a été de détailler dans ~/.codex/AGENTS.md où se trouvaient les référentiels locaux et ce qu’ils contenaient. Cela a permis à Codex de découvrir et de parcourir plus facilement les codes pertinents.

Nous faisions du développement multiplateforme par le biais d’une traduction au lieu d’une abstraction partagée. Codex s’étant chargé de la majeure partie de la traduction, nous avons évité de doubler les coûts de mise en œuvre.

La leçon principale est que pour Codex, le contexte est primordial. Codex était le plus efficace lorsqu’il avait une connaissance du fonctionnement de la fonctionnalité sous iOS, combinée à une bonne compréhension de la structure de notre application Android. Lorsque Codex ne disposait pas de ce contexte, il ne « refusait pas de coopérer », il faisait des suppositions. Plus nous le traitions comme un nouveau coéquipier et nous investissions pour lui donner les bonnes informations, plus il était performant.

À la fin de notre sprint de quatre semaines, l’utilisation de Codex a cessé de ressembler à une expérience pour devenir notre boucle de développement par défaut. Nous l’avons utilisé pour comprendre le code existant, planifier des modifications et mettre en œuvre des fonctionnalités. Nous avons examiné son travail de la même manière que nous examinerions celui d’un collègue. C’était simplement notre façon de livrer des logiciels.

Il est devenu clair que le développement assisté par l’IA ne réduit pas le besoin de rigueur, mais l’accroît. Aussi performant que soit Codex, son objectif est d’aller d’un point A à un point B sans détour. C’est pourquoi le codage assisté par l’IA ne fonctionne pas sans intervention humaine. Les ingénieurs logiciels peuvent comprendre et appliquer les contraintes réelles des systèmes, les meilleures façons de concevoir des logiciels, et comment construire en tenant compte des plans de développement et de produits futurs. Les super-pouvoirs de l’ingénieur logiciel de demain seront une compréhension approfondie des systèmes et la capacité de travailler en collaboration avec l’IA sur de longues périodes. 

Les aspects les plus intéressants du génie logiciel sont la construction de produits convaincants, la conception de systèmes évolutifs, l’écriture d’algorithmes complexes et l’expérimentation avec des données, des modèles et du code. Cependant, les réalités de l’ingénierie logicielle d’hier et d’aujourd’hui sont souvent plus banales : centrer les boutons, câbler les points d’arrivée et écrire du code standard. Désormais, Codex permet de se concentrer sur les aspects les plus significatifs du génie logiciel et sur les raisons pour lesquelles nous aimons notre métier.

Une fois Codex configuré dans un environnement riche en contexte où il comprend vos objectifs et votre manière de construire, n’importe quelle équipe peut multiplier ses capacités. Notre rétro de lancement n’est pas une recette universelle, et nous ne prétendons pas avoir résolu le problème du développement assisté par l’IA. Mais nous espérons que notre expérience vous permettra de trouver plus facilement les méthodes optimales pour rendre Codex capable de décupler votre propre efficacité. 

Lorsque Codex a été lancé en avant-première il y a sept mois, l’ingénierie logicielle était très différente. Grâce à Sora, nous avons pu explorer le prochain chapitre de l’ingénierie. À mesure que nos modèles et nos systèmes continuent de s’améliorer, l’IA deviendra une partie de plus en plus indispensable du développement. 

Que ferez-vous avec votre propre équipe Codex ?