Comment tester iPhone Duo ? Checklist CI entreprise 2026

L’erreur la plus coûteuse consiste à traiter l’adaptation iPhone Duo comme une simple nouvelle cible de compilation. Le sujet contient au moins six états différents : compatibilité de l’application, optimisation de l’interface, validation par simulateur, validation sur appareil réel, préparation des visuels et publication en production.

Ces états ne doivent pas partager automatiquement les mêmes preuves ni les mêmes autorisations. Une compilation réussie ne prouve pas que les fenêtres modales s’affichent correctement sur chaque posture. Une capture générée par le simulateur ne prouve pas non plus qu’une caméra, une animation ou une interaction matérielle se comporte comme prévu.

Le document de décision doit associer chaque application à son responsable, sa priorité métier, sa fenêtre de mise à disposition et ses incompatibilités inacceptables. Sans cette attribution, les échecs se déplacent entre développement, QA et infrastructure sans propriétaire clair.

L’équipe de développement doit commencer par un inventaire des écrans, et non par une demande de machine supplémentaire. Les éléments sensibles comprennent les barres de navigation, les fenêtres modales, les contrôles de caméra, les transitions, les vues personnalisées et les flux audio ou vidéo. Les outils de création graphique et les applications qui affichent des aperçus multimédias méritent une attention particulière : une simple adaptation de largeur peut masquer une rupture dans la hiérarchie visuelle ou dans le mode de prévisualisation.

Apple décrit les changements de conception et les nouvelles possibilités d’interface dans ses contenus techniques consacrés à iPhone Duo, notamment dans cette présentation technique sur les interfaces. Nous utiliserons ces indications pour définir les contrôles, sans assimiler une vérification classique du portrait et du paysage à une couverture complète.

La fiche d’un écran à risque doit contenir :

• le nom de l’écran et le chemin fonctionnel ;
• le fichier ou le composant responsable de la mise en page ;
• la posture concernée : écran externe, écran interne, appareil déplié, appareil replié ou rotation ;
• les conditions de reproduction ;
• l’état attendu après changement de posture ;
• la présence éventuelle d’une caméra, d’un flux vidéo ou d’un contenu audio ;
• le statut de correction et le responsable ;
• le degré d’automatisation possible ;
• la capture ou l’enregistrement qui servira de preuve.

La décision de correction doit rester indépendante de la décision de capacité. Si une vue est mal contrainte, ajouter des Mac ne résoudra rien. Si la vue est correcte mais que les tests attendent trop longtemps, le problème relève alors de la CI.

Nous recommandons une progression en couches. Les tests rapides doivent protéger chaque modification, tandis que les vérifications plus lourdes doivent être déclenchées par un changement pertinent ou par une campagne planifiée. Cette organisation évite de faire exécuter toute la matrice à chaque validation sans preuve que cette dépense apporte une information nouvelle.

Le simulateur est adapté aux contrôles déterministes de navigation, de mise en page et de conservation d’état. Il ne remplace pas la preuve sur appareil réel pour la caméra, la performance, les interactions physiques ou les comportements dépendant du matériel. Cette séparation doit figurer dans le rapport QA, sans laisser entendre qu’un résultat de simulateur vaut certification universelle.

Pour les visuels, App Store Connect documente les spécifications d’images, mais Apple indique que la prise en charge de l’envoi des ressources concernées doit être ouverte ultérieurement dans l’année (spécifications officielles des captures App Store Connect). Nous pouvons donc préparer une génération reproductible, mais nous ne devons pas annoncer une capacité de soumission qui n’est pas encore officiellement disponible.

Xcode 27 est officiellement publié selon les notes de version Apple. En revanche, la piste Xcode 27.1 destinée aux besoins iPhone Duo doit rester traitée comme une voie d’expérimentation tant que la version, le simulateur et la documentation complète ne sont pas tous confirmés comme disponibles dans l’environnement de l’entreprise. Les informations de version Xcode doivent être relues avant chaque changement d’image.

La configuration recommandée est la suivante :

• une image de production qui conserve la version Xcode approuvée ;
• une image expérimentale séparée pour Xcode 27.1 ;
• une étiquette de Runner qui empêche l’envoi accidentel d’une tâche vers le mauvais nœud ;
• une file d’attente indépendante ;
• un petit projet représentatif avant l’ouverture à l’ensemble des dépôts ;
• des journaux conservés pour l’installation, la compilation, les tests, la file d’attente et l’occupation du disque ;
• une procédure de reconstruction permettant de supprimer les identifiants et les caches.

Nous ne déduirons pas le nombre de nœuds à partir du nombre d’appareils ou de développeurs. La demande dépend de la durée d’occupation, de la fréquence de la campagne, des tâches concurrentes et de la priorité des publications. Une entreprise qui dispose d’un seul projet léger et d’une campagne ponctuelle n’a pas le même besoin qu’une organisation qui exécute plusieurs régressions multimédias en parallèle.

Le nœud d’adaptation ne doit pas recevoir par défaut les certificats, clés privées et identifiants utilisés pour les archives de production. La séparation doit être vérifiée par la sécurité, puis testée par une tentative contrôlée de publication : le nœud expérimental doit pouvoir compiler et tester sans pouvoir signer ou transférer un livrable de production.

La revue de sécurité doit couvrir :

• les comptes de test et leurs rôles ;
• les variables protégées de la CI ;
• les certificats et clés privées montés temporairement ;
• les dépendances internes téléchargées pendant la compilation ;
• les journaux contenant des chemins, jetons ou données applicatives ;
• la durée de conservation des artefacts ;
• le nettoyage après reconstruction du nœud ;
• la révocation des accès lors de la fin de la campagne.

Les équipes audio et vidéo doivent également vérifier que les fichiers de test ne contiennent pas de contenu client dans les artefacts conservés. Pour une application de design, un export intermédiaire peut révéler des informations sensibles même lorsque le code source reste absent du journal. La conservation doit donc être limitée à ce qui permet de reproduire l’échec.

Checklist d’acceptation interéquipes

• [ ] Le responsable produit a défini les écrans et flux iPhone Duo prioritaires.
• [ ] Chaque écran à risque possède une condition de reproduction et un propriétaire.
• [ ] Les états externe, interne, déplié, replié et rotation figurent dans la matrice lorsque l’application les utilise.
• [ ] Les scénarios de simulateur et les scénarios sur appareil réel sont séparés.
• [ ] Les fonctions caméra, audio, vidéo et interaction matérielle ont un niveau de preuve adapté.
• [ ] Le nœud Xcode 27.1 porte une étiquette et une file distinctes de la production.
• [ ] Un projet représentatif a été exécuté avant l’ouverture de la campagne à tous les dépôts.
• [ ] Les journaux enregistrent la durée de compilation, la durée des tests, l’attente et l’évolution du stockage.
• [ ] Les secrets de publication sont absents du nœud expérimental par défaut.
• [ ] La reconstruction du nœud efface les identifiants, caches et artefacts sensibles.
• [ ] Les ressources graphiques sont générées par une procédure reproductible.
• [ ] La sécurité a signé la séparation entre validation et publication.
• [ ] L’IT dispose d’un seuil documenté pour maintenir, étendre ou externaliser la capacité.
• [ ] Les lacunes de preuve sont inscrites dans la décision finale.

Postures couvertes par l’adaptation

Une couverture correcte distingue l’écran externe, l’écran interne, l’état déplié, l’état replié et les rotations pertinentes. Les équipes doivent ajouter la navigation, les modales, la caméra, les transitions et la conservation de l’état. Une campagne limitée aux orientations classiques ne suffit pas pour fermer le risque d’interface.

Déploiement isolé de Xcode 27.1

Nous déployons Xcode 27.1 sur une image et une file séparées de la production, avec une étiquette de Runner explicite. Le premier passage porte sur un projet représentatif et une petite régression. Les journaux deviennent la base de la décision ; ils doivent être relus après toute évolution des outils officiels.

Limites du simulateur iPhone Duo

Le simulateur permet de vérifier rapidement des scénarios déterministes, mais il ne remplace pas l’appareil réel pour la caméra, les interactions physiques, certaines performances et les comportements matériels. La matrice doit donc indiquer clairement quelle preuve est obtenue par simulation et laquelle exige une validation matérielle.

Décision d’extension de la CI

L’ajout de tests ne justifie pas automatiquement l’achat d’un Mac supplémentaire. Si la charge reste absorbée, nous conservons la capacité existante. Si un pic court crée une file excessive, un Mac distant pour une preuve de concept d’entreprise peut servir de voie isolée. Un nœud fixe n’est retenu que lorsque les journaux montrent une charge récurrente.

La capacité doit être décidée après la campagne représentative, non avant. Nous examinerons la fréquence des tâches iPhone Duo, l’occupation d’un nœud, l’attente maximale observée, les travaux de publication concurrents, les besoins d’isolement et la procédure de reprise. Ces éléments forment une preuve exploitable par les achats.

La décision peut prendre quatre formes :

• Maintien : les nouvelles tâches sont absorbées sans dégrader les publications et sans attente problématique.
• Extension temporaire : une campagne courte crée une surcharge, mais la charge ne justifie pas une machine permanente.
• Nœud fixe dédié : la régression devient régulière, prioritaire et suffisamment longue pour occuper durablement une capacité réservée.
• Architecture hybride : la production reste sur des nœuds de confiance, tandis que l’adaptation, la simulation et les pics sont exécutés sur une capacité séparée.

Un Mac distant est pertinent lorsque l’objectif est de mesurer une charge réelle sans engager immédiatement un achat, ou lorsque la campagne d’adaptation est concentrée dans une fenêtre limitée. Les responsables doivent néanmoins vérifier l’accès, les comptes, le stockage temporaire, les règles de conservation et le chemin de retour des artefacts. Les équipes qui comparent plusieurs zones peuvent examiner les options de Mac distant disponibles pour les équipes, puis appliquer leur propre contrôle de sécurité et de livraison.

Cette approche ne convient pas à toutes les situations. Une charge lourde et permanente, un besoin de contrôle physique direct ou une politique imposant un matériel présent dans les locaux peuvent justifier l’achat et l’exploitation d’un nœud dédié. À l’inverse, acheter plusieurs machines avant d’avoir mesuré la durée et la fréquence des régressions immobilise du capital, ajoute des images à maintenir et complique la gestion des certificats.

À la fin de l’essai, le responsable CI doit remettre un dossier contenant la matrice de postures, les rapports QA, les journaux Xcode 27.1, les preuves de séparation des signatures, les artefacts visuels et le relevé de capacité. Chaque résultat doit indiquer son propriétaire et la personne qui accepte ou refuse le risque.

Notre recommandation finale est de conserver la chaîne de production stable, puis d’utiliser une capacité isolée pour exécuter le projet représentatif et les régressions iPhone Duo. Si la file ou la durée deviennent réellement problématiques, un Mac distant loué par MESHLAUNCH peut fournir une mesure concrète avant une extension permanente. Cette comparaison est plus fiable qu’un achat fondé sur le nombre de développeurs : elle oppose une capacité actuelle mesurée à une capacité temporaire contrôlée, tout en laissant les signatures de production sur leur nœud de confiance.