De StretchTap à un workflow de skills IA : de l’idée à la soumission Apple

Avec StretchTap, j’ai expérimenté le développement d’une application Apple Watch avec Codex, jusqu’à sa soumission à Apple. Mon intervention a principalement porté sur les caractéristiques du produit et les décisions nécessaires à sa distribution. L’agent a pris en charge l’exécution technique, depuis le projet Swift jusqu’à la préparation d’App Store Connect.

Cette expérience m’a ensuite servi à construire un workflow de skills réutilisables : validation de l’idée, développement, audit qualité, publication et maintenance, coordonnés par un orchestrateur.

Le workflow s’est construit progressivement. StretchTap a été le terrain d’expérimentation qui a révélé les tâches à automatiser, les contrôles manquants et les décisions à conserver côté humain.

Le point de départ : éviter de relancer un minuteur

Pendant une séance d’étirements, un minuteur classique oblige à intervenir après chaque intervalle. Je voulais une application qui permette de choisir une durée une seule fois, puis d’enchaîner les cycles.

Le périmètre retenu pour StretchTap est volontairement réduit :

• intervalles de 20, 30, 45 ou 60 secondes ;
• démarrage en un geste ;
• répétition automatique ;
• alerte haptique à chaque nouveau cycle ;
• affichage du compte à rebours et du nombre de cycles ;
• arrêt immédiat.

L’application fonctionne de manière autonome sur Apple Watch, sans compte, serveur, publicité, analytics ou dépendance tierce. Elle a été préparée en français, anglais, allemand, italien et espagnol.

Ce choix simplifiait l’architecture et les questions de confidentialité. Il conservait cependant une difficulté propre à la montre : le minuteur devait rester utile lorsque l’écran s’éteignait.

Première étape : vérifier l’environnement réel

Avant de développer, j’ai demandé à Codex de vérifier le Mac : installation et configuration de Xcode, outils en ligne de commande, Swift, Git, SDK watchOS, simulateurs et possibilités de signature.

Cette étape paraît secondaire, mais elle évite de confondre un problème de projet avec un problème d’environnement.

L’agent pouvait ensuite utiliser plusieurs moyens d’action :

Moyen	Utilisation dans le projet
Outils de compilation	Vérification du Swift et préparation des builds
Xcode et Organizer	Configuration, signature, archivage, validation et upload
Simulator	Vérification de l’interface et du parcours, captures
Navigateur contrôlé	Configuration des services Apple et d’App Store Connect
Git et GitHub	Conservation du code et synchronisation des changements

Certaines opérations ont rencontré des restrictions d’accès à CoreSimulator depuis l’environnement d’exécution. Le parcours a alors continué dans Xcode. Cette distinction a ensuite été intégrée au workflow : identifier le canal disponible et vérifier le résultat obtenu avant de déclarer une tâche terminée.

Une petite application, plusieurs sujets techniques

L’application a été développée en Swift et SwiftUI. Le projet sépare notamment le point d’entrée, l’interface et la logique de minuterie dans des fichiers comme StretchTapApp.swift, ContentView.swift et IntervalTimer.swift.

Cette séparation permet de faire évoluer le comportement du minuteur sans concentrer toute la logique dans l’écran.

Le travail a aussi couvert :

• la compatibilité avec les versions de watchOS ciblées ;
• les ressources localisées ;
• l’icône et son catalogue d’assets ;
• les identifiants d’application ;
• les réglages de signature ;
• le schéma Xcode utilisé pour l’archive ;
• la structure du package distribué.

La cible minimale a été abaissée à watchOS 9 au cours du projet. Le schéma d’archivage a également été corrigé pour produire le conteneur distribuable avec l’application Watch intégrée.

Ces éléments montrent pourquoi « le code compile » reste une étape intermédiaire. Le livrable doit aussi être correctement assemblé et signé pour la distribution.

Le minuteur a révélé un défaut après un premier upload

L’une des difficultés les plus instructives concernait l’exécution lorsque l’écran s’éteint.

Le travail a conduit à utiliser une session d’exécution prolongée watchOS, avec une configuration de type physical-therapy, et à prévoir un arrêt à la limite système de cette session.

Un premier build avait pourtant été envoyé à Apple avant qu’un défaut soit identifié : le mode nécessaire n’était pas intégré au fichier de configuration final.

L’agent a corrigé ce point, vérifié le démarrage et le passage automatique au deuxième cycle, puis préparé un build 2.

La leçon est précise : une configuration présente dans le projet ou attendue par le code peut manquer dans le résultat construit. Les vérifications doivent donc porter sur le package final et son comportement.

Cette expérience a nourri les contrôles ajoutés ensuite au workflow : identifier le build exact, vérifier son contenu et éviter de réutiliser les preuves d’un build précédent après une modification.

Signature, archive et identité du build

La préparation de la distribution a nécessité un certificat Apple Distribution et des profils de provisionnement adaptés aux identifiants du projet.

L’agent a utilisé Xcode et les interfaces Apple pour préparer la signature, créer l’archive et la faire valider avant l’envoi à App Store Connect.

Le parcours distingue plusieurs états :

1. le projet compile ;
2. une archive Release signée existe ;
3. l’archive passe la validation Apple ;
4. le build est envoyé et traité dans App Store Connect ;
5. le build est sélectionné pour la soumission ;
6. Apple examine l’application ;
7. l’application devient éventuellement disponible au public.

Ces états ont été formalisés dans les skills. Un upload réussi ne prouve ni l’approbation ni la publication.

Le workflow consolidé prévoit aussi de transmettre une identité de release : version, numéro de build, identifiants, commit source, équipe de signature et empreinte SHA-256 de l’archive.

L’objectif est de pouvoir vérifier que le package audité correspond bien à celui préparé pour la publication.

Le travail de publication déborde largement de Xcode

L’agent a préparé les descriptions, sous-titres, mots-clés et textes promotionnels dans les cinq langues. Deux captures Apple Watch ont été produites : l’écran de sélection et le minuteur actif.

Le site d’assistance et de confidentialité a été publié sur GitHub Pages dans un dépôt distinct :

StretchTap          → code de l’application, privé
stretchtap-support  → site public d’assistance et de confidentialité

Cette séparation permet de rendre les pages accessibles sans exposer le code source.

La déclaration de confidentialité a été préparée après examen du code : absence de comptes, d’accès réseau, de suivi, de publicité et de SDK tiers. Les textes publics et la fiche App Store devaient rester cohérents avec ces caractéristiques.

J’ai également choisi le prix de 1,99 € et la sortie automatique après approbation. Les choix commerciaux et les déclarations réglementaires ont nécessité mes confirmations.

L’agent réalisait les opérations ; je conservais la responsabilité des décisions et des informations déclarées.

Le retour d’Apple : démontrer l’application sur une vraie montre

Après la soumission, Apple a demandé des informations supplémentaires au titre de Guideline 2.1 — Information Needed. Le message mentionnait un historique limité de revue pour le compte développeur.

Apple demandait notamment une démonstration sur appareil physique, la description du public et du problème résolu, les instructions d’utilisation, les services externes et les éventuelles différences régionales.

Le scénario préparé pour StretchTap était concret :

• lancer l’application sur une vraie Apple Watch ;
• sélectionner 20 secondes ;
• montrer le compte à rebours ;
• laisser apparaître le deuxième cycle ;
• arrêter le minuteur.

L’agent a préparé une réponse structurée couvrant les points demandés. La démonstration et les observations physiques restaient à fournir.

Le simulateur permet de vérifier des écrans et des interactions. Il ne permet pas d’affirmer ce que ressent l’utilisateur au poignet ni de remplacer les observations sur matériel réel.

À ce stade du récit, StretchTap a été soumise à Apple et a reçu cette demande complémentaire. L’approbation et la disponibilité publique restent des résultats distincts.

Transformer le parcours en skills

Une fois cette expérience réalisée, j’ai voulu conserver la méthode pour d’autres applications.

Un skill est ici un ensemble d’instructions réutilisables, accompagné selon les besoins de références, de modèles et de scripts de validation. Il guide Codex dans une mission ; les outils disponibles réalisent les opérations.

Les responsabilités ont été réparties ainsi :

Skill	Responsabilité
apple-app-product-validator	Clarifier et évaluer une idée, préparer le brief
apple-app-child-idea-validator	Accompagner une idée d’enfant avec validation adulte
apple-app-builder	Développer, tester et produire le package signé
apple-app-quality-auditor	Examiner le package dans une phase d’audit distincte
app-store-publisher	Préparer App Store Connect et gérer la soumission
apple-app-maintainer	Examiner les signaux après publication
apple-app-lifecycle-orchestrator	Coordonner les étapes et conserver l’état

L’audit est séparé du développement : l’auditeur ne modifie pas le code. Un défaut retourne au Builder, puis le package corrigé doit être contrôlé à nouveau.

Cette séparation des responsabilités ne garantit pas, à elle seule, l’absence d’erreur. Elle rend les passages de relais et les preuves attendues plus explicites.

Un état persistant pour reprendre le travail

L’orchestrateur organise une chaîne principale :

Idée → Validation → Développement → Audit → Publication → Maintenance
                         ↑            |
                         └─ Correction┘

Il prévoit un dossier de contrôle contenant notamment :

AppleAppWorkflow/
├── workflow-status.json
├── owner-profile.json
├── workflow-journal.md
└── decision-log.md

Le statut conserve l’étape courante et la prochaine action. Le journal retrace les transitions. Le registre de décisions permet de réutiliser une autorisation ou une préférence déjà donnée dans son périmètre.

Ce point répond à une difficulté du premier parcours : les confirmations étaient parfois répétitives. Une décision déjà prise ne devrait pas être redemandée simplement parce que le travail change d’étape.

Le workflow conserve toutefois les décisions propres à chaque application, comme le prix, le mode de sortie et les déclarations légales.

Les contrôles du workflow avaient aussi besoin de tests

L’audit des skills a révélé des failles dans les validateurs eux-mêmes.

Certains contrôles faisaient trop confiance aux champs déclaratifs d’un dossier. D’autres bloquaient des situations légitimes, comme l’enregistrement d’une information vérifiée ou le démarrage de la maintenance avant la constitution de son dossier initial.

Les corrections ont renforcé plusieurs points :

• existence des fichiers et cohérence de leurs empreintes ;
• correspondance entre application, plateforme, build et signature ;
• distinction entre audit du site et audit du package ;
• refus des captures vides et des preuves obligatoires manquantes ;
• traitement spécifique des changements de métadonnées ou de prix ;
• reprise d’un projet sans inventer son historique.

Une campagne ultérieure a rapporté 116 tests réussis, complétés par des scénarios simulés de reprise et de rejet.

Ces résultats portent sur les contrats et les validateurs du workflow. Ils ne certifient pas la qualité physique de StretchTap et ne constituent pas une approbation d’Apple.

Mon rôle dans cette automatisation

Mon intervention a principalement concerné les caractéristiques de l’application. L’agent a effectué le travail technique et les manipulations dans les outils, mais le chat comprend aussi des confirmations, des décisions commerciales et réglementaires, ainsi que des étapes d’authentification.

Je décrirais donc cette expérience comme une exécution largement automatisée, pilotée par mes choix produit et encadrée par des points de décision humaine.

StretchTap a permis d’atteindre une soumission réelle et de construire une méthode plus explicite à partir des difficultés rencontrées. La prochaine validation consiste à utiliser la chaîne consolidée dès le début d’un nouveau projet, puis à observer son comportement jusqu’à la publication et aux mises à jour.

Une expérience aussi en famille

J’ai également ajouté un skill pour accompagner ma fille de 9 ans dans la définition d’une application : apple-app-child-idea-validator.

Ce skill adapte la conversation avec une ou deux questions courtes à la fois. Il aide l’enfant à préciser qui utilisera l’application, ses trois fonctions principales et le parcours souhaité, puis reformule l’idée pour lui permettre de la corriger.

Techniquement, il prépare deux restitutions : une synthèse accessible à l’enfant et une analyse destinée à l’adulte, avec les points de faisabilité et de confidentialité. Après validation du périmètre par l’adulte, il produit un fichier product-brief.md que le skill apple-app-builder peut reprendre pour développer l’application.

La chaîne devient ainsi : idée de l’enfant → brief validé par l’adulte → développement → essai dans le simulateur Xcode.

Ma fille a ensuite pu tester son application sur simulateur et découvrir comment ses choix se traduisaient dans une interface utilisable. Les comportements propres au matériel restent à vérifier sur un appareil réel.

Cette expérience donne aussi au workflow une dimension pédagogique : permettre à un enfant, accompagné d’un adulte, de suivre le chemin entre une idée et une première application.

Pour poursuivre sur un sujet complémentaire : Personnaliser Dynamics 365 Business Central avec Cursor : une nouvelle approche assistée par l’IA ?.