Comment nous avons utilisé Codex pour développer Sora sur Android en 28 jours

À compter du 26 avril 2026, le produit 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 une courte invite en une vidéo vivante. Le jour du lancement, l'appli 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 disponible pour toute équipe ou développeur : Codex.

Du 8 octobre au 5 novembre 2025, une équipe d'ingénierie allégée, travaillant aux côtés de Codex et consommant environ 5 milliards de tokens, a lancé Sora pour Android, passant du prototype au lancement mondial. Malgré son ampleur, l'appli a 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 utilisé une version préliminaire du modèle GPT‑5.1‑Codex, la même version que celle dont peuvent bénéficier aujourd'hui tous les développeurs et toutes les entreprises via CLI, l'extension IDE ou l'appli Web.

Lorsque Sora a été lancé sur iOS, l'utilisation a explosé. 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éponse courante à un lancement à enjeux élevés et sous pression temporelle consiste à accumuler des ressources et à ajouter des processus. Une appli de production de cette envergure et de cette qualité impliquerait généralement de nombreux ingénieurs travaillant pendant des mois, ralentis par la coordination. 

L'architecte informatique américain Fred Brooks a averti célèbrement que « ajouter plus de personnes à un projet logiciel en retard le rend encore plus en retard ». Autrement dit, lorsqu'on cherche à livrer rapidement un projet complexe, ajouter davantage d'ingénieurs peut souvent réduire l'efficacité en augmentant la surcharge de communication, la fragmentation des tâches et les coûts d'intégration. Nous nous sommes appuyés sur cette intuition au lieu de l’ignorer; nous avons réuni une équipe solide de quatre ingénieurs – tous équipés de Codex pour augmenter considérablement l’impact de chaque ingénieur. 

En procédant ainsi, nous avons livré une construction 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é pour les pratiques d'ingénierie Android, investi dans la maintenabilité, et maintenu l'appli au même niveau de fiabilité que celui que nous attendrions d'un projet plus traditionnel. (Nous continuons également à utiliser Codex de manière intensive aujourd'hui pour faire évoluer et apporter de nouvelles fonctionnalités à l'appli).

Pour comprendre comment nous avons travaillé avec Codex, il est utile de savoir où il excelle et où il a besoin de directives. Le traiter comme un ingénieur·e senior nouvellement embauché·e était une bonne approche. La capacité de Codex nous a permis de passer plus de temps à diriger et à vérifier le code plutôt qu'à l'écrire nous-mêmes.

Où Codex a besoin de conseils

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 qu'un flux était déroutant. Seule notre équipe pouvait couvrir ces tâches expérientielles.
3. Chaque instance nécessite une intégration. Partager le contexte avec des objectifs clairs, des contraintes et des directives sur « comment nous procédons » était essentiel pour que Codex fonctionne efficacement.
4. Dans le même ordre d'idées, Codex a eu du mal avec le jugement architectural profond : laissé à lui-même, il pourrait introduire un modèle de vue supplémentaire là où nous souhaitions réellement étendre un modèle existant ou déplacer la logique dans la couche UI qui devait clairement se trouver dans un dépôt. Son instinct est de faire fonctionner quelque chose, pas de privilégier la propreté à long terme.

Nous avons trouvé utile que Codex crée et maintienne un grand nombre de fichiers AGENT.md dans toute la base de code. Cela a facilité l'application des mêmes conseils et bonnes pratiques lors des sessions. 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 :

Où Codex excelle

1. Lire et comprendre rapidement de grandes bases de code : Codex maîtrise essentiellement tous les principaux langages de programmation, ce qui facilite l'application des mêmes concepts sur de nombreuses plateformes sans recourir à des abstractions complexes.
2. Couverture des tests : Codex est (de façon unique) enthousiaste à l’idée d’écrire des tests unitaires couvrant une grande variété de cas. Tous les tests n'étaient pas approfondis, mais avoir une couverture étendue a été utile pour prévenir les régressions. 
3. Appliquer les commentaires : Dans le même ordre d'idées, Codex réagit bien aux commentaires. Lorsque l'intégration continue échouait, nous pouvions coller la sortie des journaux dans une invite et demander à Codex de proposer des solutions.
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 faisable de tester plusieurs idées en parallèle et de considérer le code comme jetable.
5. Offrir une nouvelle perspective : Dans les 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 les lecteurs vidéo, Codex a examiné plusieurs SDK pour proposer des approches que nous n'aurions pas eu le temps d'explorer. Les résultats de la recherche de Codex se sont révélés inestimables pour réduire l'empreinte mémoire dans l'appli finale.
6. Permettre un travail à plus forte valeur ajoutée : En pratique, nous avons fini par passer plus de temps à vérifier et à diriger le code qu'à l'écrire nous-mêmes. Cela dit, Codex est également très performant en vérification de code, détectant souvent les bogues avant qu'ils ne soient fusionnés, ce qui améliore la fiabilité.

Une fois que nous avons reconnu ces caractéristiques, notre modèle de travail est devenu plus direct. Nous nous sommes appuyés sur Codex pour effectuer un travail considérable dans le cadre de modèles bien compris et de périmètres bien délimités, tandis que notre équipe s'est concentrée sur l'architecture, l'expérience utilisateur, les modifications systémiques et la qualité finale.

Même le meilleur nouvel employé senior n’a pas immédiatement la perspective adéquate pour effectuer des compromis à long terme. Pour tirer parti de Codex et garantir que son travail soit robuste et maintenable, il était essentiel que nous supervisons nous-mêmes la conception des systèmes de l'appli 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 rédigé quelques fonctionnalités représentatives de bout en bout. Nous avons appliqué les règles que nous souhaitions que l'ensemble du code respecte et avons documenté les modèles à l'échelle du projet au fur et à mesure. En orientant Codex vers des fonctionnalités représentatives, il a pu travailler de manière plus autonome selon nos normes. Pour un projet que nous estimons avoir été rédigé à 85 % par Codex, une base soigneusement planifiée a permis d'éviter des retours en arrière et des refontes coûteuses. C'était l'une des décisions les plus importantes que nous ayons prises. 

L'idée n'était pas de créer « quelque chose qui fonctionne » le plus rapidement possible, mais plutôt de créer « quelque chose qui saisit comment nous voulons que les choses fonctionnent ». Il existe de nombreuses façons « 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. Une fois que nous avions établi notre point de départ et notre méthode de création, Codex était prêt à commencer.

Pour voir ce qui se passerait, nous avons essayé de demander : « Développez l'appli Sora pour Android à partir du code iOS. Go », mais a rapidement abandonné cette voie. Bien que ce que Codex a créé fonctionnait techniquement, l'expérience du produit était en deçà des attentes. Et sans une compréhension claire des points de terminaison, des données et des flux d'utilisateurs, le code à exécution unique 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 s'épanouirait dans un bac à sable d'exemples bien écrits, et nous avions raison. Demander à Codex de « développer cet écran de paramètres » avec presque aucun contexte s'est avéré peu fiable. Demander à Codex de « développer cet écran de paramètres en utilisant la même architecture et les mêmes modèles que cet autre écran que vous venez de voir » a donné de bien meilleurs résultats. Les humains ont pris les décisions structurelles et défini les invariants; Codex a ensuite intégré de grandes quantités de code dans cette structure.

Notre étape suivante pour maximiser le potentiel de Codex était de déterminer comment activer Codex pour fonctionner pendant de longues périodes (récemment, plus de 24 heures⁠), sans supervision.

Au début de l'utilisation de Codex, nous avons rapidement adopté des invites telles que : « Voici la fonctionnalité. Voici quelques fichiers. Veuillez le développer. » Cela fonctionnait parfois, mais produisait principalement du code qui, bien qu'il soit techniquement compilé, s'écartait de notre architecture et de nos objectifs.

Nous avons donc modifié le flux de travail. Pour toute modification non triviale, nous avons d'abord demandé à Codex de nous aider à comprendre comment le système et le code fonctionnent. Par exemple, nous lui demanderions de lire un ensemble de fichiers connexes et de résumer le fonctionnement de cette fonctionnalité, par exemple comment les données circulent de l'API à travers la couche de dépôt, le modèle de vue et dans l'interface utilisateur. Ensuite, nous corrigerions ou affinerions sa compréhension. (Par exemple, nous indiquerions qu'une abstraction particulière devrait appartenir à une autre couche ou qu'une classe donnée est uniquement destinée au mode hors ligne et ne devrait pas être étendue.)

De la même manière que vous pourriez engager un nouveau coéquipier très compétent, nous avons collaboré avec Codex pour créer un plan 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 être structurée. Ce n'est qu'alors que nous avons demandé à Codex de commencer à appliquer le plan, une étape à la fois. Un conseil utile : pour les tâches très longues, lorsque nous atteignons la limite de notre fenêtre de contexte, nous demandons à Codex d'enregistrer son plan dans un fichier, ce qui nous permet d'appliquer la même direction à travers les instances.

Cette boucle de planification supplémentaire s'est avérée valoir le temps investi. 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 du code, car nous pouvions vérifier l'implémentation par rapport à notre plan plutôt que de lire un diff sans contexte. Et lorsque quelque chose tournait mal, nous pouvions d'abord déboguer le plan, puis le code. 

La dynamique était semblable à celle d'un bon document de conception qui inspire confiance à un chef de projet technique. Nous ne faisions pas que générer du code : nous produisions du code qui soutenait une feuille de route commune.

Au sommet du projet, nous exécutions 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 refontes. Cela ressemblait moins à l'utilisation d'un outil et plus à la gestion d'une équipe.

Chaque session nous ferait périodiquement un retour sur les progrès. On pourrait dire : « J'ai fini de planifier ce module; voici ce que je propose », tandis qu'un autre proposerait un grand changement pour une nouvelle fonctionnalité. Chacun nécessitait de l'attention, des commentaires et une vérification. C'était étrangement similaire à être un chef d'équipe technique avec plusieurs nouveaux ingénieurs, tous progressant, tous ayant besoin de conseils.

Le résultat fut 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'appli. 

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

C'est ici que les idées de Brooks prennent une nouvelle tournure. 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 ensemble plutôt que simplement des musiciens solo plus rapides.

Nous avons entamé notre projet avec un atout majeur : Sora avait déjà été déployé sur iOS. Nous avons fréquemment dirigé 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 multiplateforme, c’est Codex.

Sous la plaisanterie se trouvent 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 excelle à lire une implémentation Swift et à produire un équivalent en Kotlin qui conserve la sémantique.
2. Les exemples concrets fournissent 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 mettant ces principes en pratique, nous avons rendu les référentiels iOS, arrière-plan et Android disponibles dans le même environnement. Nous avons donné à Codex des invites telles que :

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

Un petit truc utile consistait à détailler dans ~/.codex/AGENTS.md où se trouvaient les dépôts locaux et ce qu'ils contenaient. Cela a rendu plus facile pour Codex de découvrir et de naviguer dans le code pertinent.

Nous réalisions effectivement du développement multiplateforme par la traduction plutôt que par l'abstraction partagée. Étant donné que Codex a pris en charge la majorité de la traduction, nous avons évité de doubler les coûts d'implémentation.

La leçon principale est que pour Codex, le contexte est essentiel. Codex a fait son meilleur travail lorsqu'il comprenait comment la fonctionnalité fonctionnait déjà dans iOS, en parallèle avec une compréhension de la structure de notre appli Android. Lorsque Codex manquait de ce contexte, il ne « refusait pas de coopérer » : il devinait. Plus nous le traitions comme un nouveau collègue et investissions à lui fournir les bonnes Entrées, mieux il performait.

À la fin de notre sprint de quatre semaines, l'utilisation de Codex a cessé de ressembler à une expérience et est devenue notre boucle de développement par défault. Nous l'avons utilisé pour comprendre le code existant, faire un plan des changements et mettre en œuvre des fonctionnalités. Nous avons vérifié sa sortie de la même manière que nous examinerions celui d’un collègue. C'était simplement ainsi que nous distribuions des logiciels.

Il est devenu évident que le développement assisté par l'IA n'élimine pas le besoin de rigueur; au contraire, il l'accroît. Aussi capable que soit Codex, son objectif est de passer du point A au point B, maintenant. C'est pourquoi le codage assisté par l'IA ne fonctionne pas sans intervention humaine. Les ingénieurs en logiciel sont capables de comprendre et d'appliquer les contraintes réelles des systèmes, les meilleures méthodes pour concevoir des logiciels, et de construire en tenant compte des plans futurs de développement et de produit. 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 de l'ingénierie logicielle sont la création de produits captivants, la conception de systèmes évolutifs, la rédaction d'algorithmes complexes et l'expérimentation avec les données, les modèles et le code. Cependant, les réalités du génie logiciel, passées et présentes, sont souvent plus banales : centrer des boutons, connecter des points de terminaison et rédiger du code standard. Désormais, Codex permet de se concentrer sur les aspects les plus significatifs de l'ingénierie logicielle et sur les raisons pour lesquelles nous aimons notre métier.

Une fois que Codex est mis en place dans un environnement riche en contexte où il comprend vos objectifs et comment vous aimez construire, n’importe quelle équipe peut multiplier ses capacités. Notre rétrospective de lancement n'est pas une solution universelle, et nous ne prétendons pas avoir résolu le développement assisté par l'IA. Mais nous espérons que notre expérience facilitera la recherche des meilleures façons de permettre à Codex de vous autonomiser. 

Lorsque Codex a été lancé en version préliminaire de recherche il y a sept mois, l'ingénierie logicielle était très différente. Grâce à Sora, nous avons pu explorer le chapitre suivant de l'ingénierie. À mesure que nos modèles et nos outils continuent de s'améliorer, l'IA deviendra une partie de plus en plus indispensable de la construction. 

Que ferez-vous avec votre propre équipe de Codex?