Après l'App Store : comment Codex a changé mon workflow de vibe-coding

La vraie vie commence après la validation Apple

La première version de Pugify était déjà une vraie app. Suivi du poids, repas, soins, vaccins, export PDF, Tip Jar avec StoreKit 2, zéro serveur, zéro analytics, zéro collecte de données. Je l'avais raconté dans Du vibe-coding à l'App Store en un week-end. Ce qui m'avait marqué à ce moment-là, c'était la vitesse.

Ce qui m'a marqué ensuite, c'est l'entretien.

La version 1.0.2 s'est concentrée sur la stabilité : meilleur suivi du poids à la création du profil, nettoyage plus fiable des champs texte, calculs plus précis pour les soins et les rappels, export PDF renforcé, Tip Jar consolidé, moins de rafraîchissements inutiles. Ce n'est pas une grande annonce marketing. C'est le genre de travail invisible qui évite qu'une app prometteuse devienne pénible à utiliser.

La version 1.0.3 a ajouté une couche plus sensible : un verrou interne pour protéger les informations d'identification, la santé et l'export du carnet de santé avec Face ID, Touch ID ou le code de l'appareil. Elle a aussi rafraîchi la direction visuelle, harmonisé l'accueil, l'onboarding, les soins et les écrans de santé, mis à jour les icônes et réduit des recalculs inutiles.

Autrement dit : ce n'était plus le vibe-coding "waouh, une app existe". C'était le vibe-coding de maintenance. Celui où l'on doit garder une branche propre, comprendre les régressions possibles, préparer une release, tester, documenter, publier, puis revenir plus tard avec assez de contexte pour continuer.

Et ça, dans mon ancien workflow, restait assez éclaté.

Avant : un bon agent, mais un workflow éclaté

Claude Code m'a énormément aidé pour créer Pugify. Je ne veux pas réécrire l'histoire. Sans lui, je n'aurais pas produit une app iOS native aussi vite, avec SwiftUI, SwiftData, StoreKit 2, notifications locales et tests unitaires.

Mais mon environnement de travail restait dispersé.

Il y avait le code dans Visual Studio Code. Il y avait Xcode pour compiler, tester et archiver. Il y avait le terminal pour Git. Il y avait GitHub pour les branches, les PR et les merges. Il y avait App Store Connect pour les notes de version, les builds, les métadonnées et la soumission. Il y avait des notes à côté pour ne pas perdre les décisions. Et il y avait moi, au milieu, à faire le lien entre toutes ces pièces.

Le problème n'était pas que chaque outil était mauvais. Le problème était la friction de passage.

Quand on est développeur de métier, cette friction est presque invisible. On sait naturellement où vérifier une branche, comment lire un diff, quand créer une PR, comment interpréter un échec de build, comment éviter de mélanger un changement de design avec une correction de données. Quand on n'est pas développeur de formation, chaque transition ajoute une petite charge mentale.

Je pouvais demander du code. Je pouvais demander une correction. Mais je devais souvent redevenir chef de gare : "maintenant on teste", "maintenant on commit", "maintenant on archive", "maintenant on documente", "attention, il y a une branche de release", "ne touche pas à ces fichiers", "reprends ce contexte".

Le vibe-coding fonctionne très bien quand la demande est claire. Il fonctionne moins bien quand tout le travail autour du code reste dans la tête de l'utilisateur.

Le basculement : Codex comme cockpit de travail

Codex a changé ce ressenti parce qu'il ne se limite pas à répondre dans une fenêtre de chat. Dans sa documentation, OpenAI présente Codex web comme un agent capable de lire, modifier et exécuter du code dans un environnement cloud, avec la possibilité de travailler en arrière-plan et de créer des pull requests depuis GitHub. L'application Codex ajoute de son côté les worktrees, les terminaux, les fichiers, le navigateur intégré, les automatisations et la prise en compte des consignes projet via AGENTS.md.

Dit plus simplement : je ne lui demande pas seulement "écris-moi ce composant". Je lui confie une boucle de travail.

Sur Pugify, cette boucle ressemble à ça :

La différence est subtile, mais énorme au quotidien. Codex devient moins un générateur de code et plus un environnement de production assistée.

Je peux lui demander de créer une branche, de travailler dessus, de vérifier ce qu'il a modifié, de préparer une PR, de me dire ce qui doit être testé, de relire une note de release, puis de reprendre un autre jour. Le code n'est plus une sortie isolée. Il fait partie d'un workflow complet.

Et pour quelqu'un comme moi, c'est exactement le maillon qui manquait.

Ce que ça change pour quelqu'un qui n'est pas développeur

Le point important n'est pas que Codex "code mieux" dans l'absolu. Ce genre de comparaison devient vite stérile. Ce qui change, c'est que Codex réduit la distance entre une intention produit et une modification livrable.

Je peux formuler une demande en termes d'usage : "les données d'identification sont sensibles, je veux pouvoir les protéger dans l'app". Derrière, il faut penser à LocalAuthentication, à l'état de session, au masquage quand l'app passe en arrière-plan, aux textes localisés, aux tests, à l'expérience utilisateur si Face ID n'est pas disponible. Ce n'est pas juste une vue SwiftUI.

Je peux aussi formuler une demande en termes de ressenti : "l'onboarding est encore trop dense, les actions sont mal placées quand le clavier apparaît". Derrière, il faut comprendre la hiérarchie des écrans, la navigation, les safe areas, les formulaires, les états de validation et la cohérence visuelle.

Avant, je devais souvent découper ces demandes en tâches techniques. Avec Codex, je peux davantage rester au niveau du produit, puis relire et arbitrer. Je ne disparais pas du processus. Au contraire, mon rôle devient plus clair : expliquer l'intention, refuser ce qui ne va pas, valider ce qui est acceptable, garder la cohérence.

C'est pour ça que je trouve Codex particulièrement intéressant pour le vibe-coding. Il ne supprime pas le besoin de comprendre ce qu'on construit. Il supprime une partie de la manutention technique qui empêche beaucoup de gens d'aller jusqu'au bout.

Le non-développeur ne devient pas magiquement ingénieur iOS. Il devient capable de piloter un système de développement, à condition d'être précis, patient et prêt à vérifier.

Le workflow concret d'une mise à jour Pugify

La release 1.0.3 de Pugify est un bon exemple. Elle n'a pas été une petite correction isolée. La branche release/1.0.3 a regroupé des changements de confidentialité, de design, d'onboarding, de navigation, de santé, d'assets, de performances, de documentation et de métadonnées App Store.

Ce qui a changé côté utilisateur :

• les sections Identification, Santé et export du carnet de santé peuvent être protégées par Face ID, Touch ID ou le code de l'appareil ;
• un écran de confidentialité masque les informations sensibles quand l'app passe en arrière-plan ;
• l'accueil, l'onboarding, les soins et les écrans de santé ont été harmonisés ;
• le clavier ne chevauche plus les actions dans l'onboarding ;
• les icônes et avatars ont été mis à jour ;
• les listes de vaccins, traitements antiparasitaires et conseils santé sont plus stables ;
• certains écrans recalculent moins de données pendant le rendu.

Ce qui a changé côté workflow :

• une branche de release a porté les changements jusqu'à la PR GitHub #2 ;
• les notes App Store françaises et anglaises ont été préparées et archivées ;
• les métadonnées App Store Connect ont été documentées sans stocker de coordonnées personnelles en clair ;
• les tests simulateur iPhone 17 et iPad A16 ont été passés ;
• un build Release et une archive iOS générique ont été produits ;
• l'upload App Store Connect a été relancé hors sandbox après un blocage local ;
• la publication App Store a été confirmée le 6 mai 2026.

Pris séparément, aucun de ces points n'est magique. Ensemble, ils forment une vraie chaîne de livraison. C'est là que je vois la différence entre "faire générer du code" et "faire avancer un produit".

Le plus intéressant, c'est que Codex peut garder les deux niveaux en même temps. Il peut parler de SensitiveAccessManager, de scenePhase, de tests et de PR. Puis il peut aussi reformuler les notes de version pour un utilisateur normal qui veut simplement savoir ce qui a changé dans Pugify.

Ce pont-là est très précieux. Dans une petite app indépendante comme Pugify, c'est confortable. Dans une PME, c'est encore plus important : les outils techniques n'ont de valeur que s'ils restent reliés aux usages métier, aux responsabilités, aux validations et aux risques.

Ce que Codex ne fait toujours pas à ma place

Il y a un risque avec ce genre d'article : donner l'impression que tout est devenu automatique. Ce n'est pas le cas.

Codex ne décide pas que les données d'identification d'un carlin méritent un verrou. C'est une décision produit. Il ne décide pas que l'app doit rester sans compte, sans serveur et sans collecte de données. C'est une décision de confiance. Il ne décide pas que l'interface doit être plus douce, plus lisible, moins technique. C'est une décision de goût.

Codex ne remplace pas non plus la vérification. Quand il modifie une app iOS, je dois relire. Je dois tester. Je dois vérifier que le résultat correspond à l'intention. Je dois accepter ou refuser les compromis. Je dois garder un oeil sur ce qui est envoyé à Apple.

La bonne nouvelle, c'est que cette responsabilité devient plus supportable. Je ne passe pas mon énergie à me souvenir de la syntaxe Git ou à recoller un fil technique cassé. Je la passe sur des questions plus utiles :

• est-ce que ce changement améliore vraiment l'expérience ?
• est-ce que cette donnée doit être visible sans authentification ?
• est-ce que cette note de version est compréhensible ?
• est-ce que cette release mérite d'être publiée maintenant ?
• est-ce que je comprends assez bien le diff pour l'assumer ?

Pour moi, c'est ça le vrai changement. Codex ne me retire pas la responsabilité. Il m'aide à la porter.

Ce que le vibe-coding devient

Le premier vibe-coding ressemblait à une accélération du développement. On écrivait une spec, l'IA produisait beaucoup de code, puis on corrigeait jusqu'à obtenir quelque chose d'utilisable.

Le vibe-coding avec Codex ressemble davantage à une collaboration de production.

On ne parle plus seulement de prompts. On parle de branches, de worktrees, de règles projet, de tests, de PR, de documentation, de sources, d'automatisations, de reprises de contexte. Le prompt reste important, mais il n'est plus seul. Il s'insère dans un environnement qui sait où sont les fichiers, quelles conventions respecter, quelles commandes lancer, quels risques surveiller.

C'est proche de ce que je construis pour des entreprises avec des agents IA ou de l'automatisation de workflows. Le vrai sujet n'est pas "l'IA répond bien". Le vrai sujet est : est-ce qu'elle entre dans le flux de travail réel, avec les bons garde-fous, les bons outils et les bonnes validations ?

Pugify est une petite app iOS. Mais la leçon dépasse largement Pugify. Beaucoup de dirigeants de PME ont déjà une forme de vibe-coding dans leur quotidien : des tableurs, des automatisations bricolées, des outils no-code, des prompts ChatGPT, des scripts qu'un prestataire a laissés derrière lui. Le problème n'est pas l'envie de faire. Le problème est de transformer cette énergie en système fiable.

Codex me donne un aperçu très concret de ce futur : l'IA ne se contente plus de produire un morceau de code. Elle accompagne la boucle de livraison.

Sources consultées

Sources consultées le 14 mai 2026 :

• Codex web, documentation OpenAI Developers
• Worktrees dans l'application Codex, documentation OpenAI Developers
• Code review GitHub avec Codex, documentation OpenAI Developers
• Instructions projet avec AGENTS.md, documentation OpenAI Developers
• Automations dans l'application Codex, documentation OpenAI Developers
• Codex for almost everything, OpenAI, 16 avril 2026

Conclusion

Le premier article se terminait sur une idée simple : le vibe-coding ne transforme pas n'importe qui en développeur. Il transforme quelqu'un qui sait ce qu'il veut construire en quelqu'un qui peut le construire.

Après les mises à jour de Pugify, j'ajouterais une nuance : Codex transforme aussi quelqu'un qui a construit quelque chose en quelqu'un qui peut le maintenir.

Ce n'est pas moins important. Créer une app en un week-end, c'est grisant. La faire évoluer proprement, publier des versions, documenter les changements, garder la qualité, protéger les données, vérifier les builds, c'est ce qui sépare le prototype du produit.

Je n'ai toujours pas envie de devenir développeur iOS à plein temps. Mais j'ai maintenant un environnement qui me permet de piloter une app iOS avec beaucoup moins de friction. Et ça change profondément ce que je considère possible.

Si vous réfléchissez à intégrer des agents dans votre entreprise, c'est exactement le type de frontière à regarder. Pas seulement "est-ce que l'IA peut répondre ?". Plutôt : est-ce qu'elle peut entrer dans vos vrais workflows, travailler avec vos outils, respecter vos règles, préparer les validations, et vous laisser décider ?

C'est ce que je construis dans mes projets d'agents IA et d'automatisation de workflows : pas des démonstrations isolées, mais des systèmes capables de faire avancer le travail réel.