Figma convient pour préparer et transmettre une interface iPhone Duo, mais une maquette statique ne prouve pas que l’application native se comporte correctement selon les postures de l’appareil. Cette semaine, préparez les écrans, les annotations et les points à vérifier ; ne planifiez une validation sur Mac qu’après confirmation d’un build exécutable et d’un environnement de test adapté.

Ce guide s’adresse aux designers UI qui conçoivent dans Figma et doivent décrire plusieurs dispositions.
Il est également destiné aux responsables produit qui transmettent des attentes à des développeurs Apple, ainsi qu’aux équipes Windows qui doivent distinguer préparation graphique et contrôle natif.

Mise à jour : 10 octobre 2026. Les ressources de conception, les indications pour iPhone Duo et les informations de prise en charge ont été vérifiées dans les ressources Apple Developer, le guide de conception iPhone Duo et les informations de préparation au développement. La disponibilité d’un appareil, d’un simulateur ou d’une prise en charge particulière doit être revérifiée avant chaque campagne de tests.

01

Avant le prototype, définissez ce que vous devez réellement livrer

Le terme « validation » recouvre souvent des travaux différents. Si vous ne les séparez pas avant de commencer, votre équipe risque de traiter une décision visuelle comme la preuve d’un comportement logiciel.

Distinguez ces livrables dès le départ :

  • Une proposition visuelle : les écrans montrent l’apparence visée et la hiérarchie des contenus. Elle se prépare dans Figma.
  • Une description d’interaction : elle précise ce qui se passe après une action, le changement d’état attendu et les éventuelles transitions. Un prototype cliquable peut illustrer une partie de cette intention, sans démontrer que le code la réalise.
  • Un build de l’application : il permet à l’équipe de vérifier le résultat réellement compilé, si elle dispose d’un environnement compatible et confirmé.
  • Une validation sur l’appareil ou le simulateur visé : elle concerne le comportement observé dans cet environnement précis. Elle ne peut pas être remplacée par une capture d’écran ou un prototype.

Cette distinction est particulièrement importante pour un projet iPhone Duo. Apple a publié des indications de conception qui abordent les postures de l’appareil et les mises en page dynamiques sur deux écrans. En revanche, la présence de ces recommandations ne confirme pas à elle seule la disponibilité d’un appareil, d’un simulateur ou d’une chaîne de test particulière. La documentation de préparation au développement d’iPhone Duo est à consulter pour vérifier les éléments nécessaires au projet.

Avant de dessiner, formulez une question de livraison à laquelle l’équipe pourra répondre : « Devons-nous approuver l’intention visuelle, vérifier le comportement du build, ou confirmer la compatibilité dans un environnement précis ? » Si la réponse contient plusieurs éléments, inscrivez-les comme des vérifications distinctes. C’est plus utile qu’un statut unique « validé », qui ne dit pas ce qui a réellement été testé.

02

Préparez le fichier Figma avec des preuves de conception lisibles

Apple a annoncé des ressources de conception comprenant des indications pour iPhone Duo et un Figma UI Kit pour iOS et iPadOS 27. Consultez l’annonce Apple sur l’actualisation des ressources de conception, puis ouvrez la page officielle des ressources de conception pour accéder aux éléments disponibles. Le kit fournit une base de travail ; son utilisation ne certifie ni la conformité de votre écran ni le rendu d’une application en cours d’exécution.

Dans votre fichier, facilitez la lecture par une personne qui n’a pas suivi les discussions de conception :

  • Donnez aux pages et aux écrans des noms compréhensibles. Évitez les séries de versions dont la différence n’apparaît qu’en ouvrant chaque calque.
  • Regroupez les écrans par parcours ou par fonction. Un développeur doit pouvoir retrouver rapidement le point d’entrée, l’action, puis le résultat attendu.
  • Ajoutez une note près de chaque zone dont le comportement dépend de la posture ou de la disposition. La note doit préciser l’intention, pas seulement dire « à adapter ».
  • Séparez les décisions prises des questions en attente. Une proposition encore discutée ne doit pas être présentée comme une règle finalisée.
  • Indiquez les contenus représentatifs et les limites de la maquette : par exemple, une transition illustrée n’est pas nécessairement une animation implémentée.

Si votre équipe prépare le fichier depuis Windows, vous pouvez organiser le prototype et l’annoter dans Figma dès lors que l’accès fonctionne dans votre navigateur. La documentation Figma sur la configuration du navigateur peut aider à résoudre des difficultés d’accès ou de configuration. Cela ne transforme pas le navigateur en environnement de compilation iOS : le travail de conception et le travail sur un build restent des étapes différentes.

Enfin, vérifiez les conditions d’utilisation des ressources avant de les incorporer ou de les redistribuer. Les conditions de licence des ressources de conception Apple précisent le cadre applicable. Ne supposez pas que la présence d’un élément dans un kit autorise n’importe quel usage hors de ce cadre.

03

Décrivez les postures sans faire passer la maquette pour un test

Le point délicat n’est pas de multiplier les variantes visuelles. Il est de montrer les changements qui influencent la compréhension, l’action ou la continuité du parcours. Pour chaque scénario retenu, indiquez ce qui reste stable et ce qui doit évoluer.

Suivez cette grille pour chaque écran représentatif :

  • Contenu prioritaire : quelle information doit rester immédiatement repérable ? Nommez le titre, l’action ou le contenu essentiel plutôt que de vous limiter à une note générale sur la lisibilité.
  • Répartition des zones : décrivez où se trouvent les éléments importants dans la disposition considérée. Si un élément change de zone, expliquez la raison de conception.
  • Action principale : précisez ce que l’utilisateur peut faire et quel état visuel doit suivre son action.
  • Continuité du parcours : dites si la progression garde le contexte ou si une nouvelle composition est attendue. Ajoutez l’écran de retour ou d’annulation lorsqu’il est pertinent.
  • États particuliers : représentez les cas que votre application doit réellement gérer, par exemple un contenu indisponible ou une action en cours, si ces cas font partie du produit.

Les recommandations Apple pour concevoir sur iPhone Duo doivent guider le choix des scénarios et le vocabulaire employé. Évitez toutefois de transformer une illustration de conception en promesse sur l’interface finale : seule l’application implémentée, exécutée dans un environnement pertinent, peut fournir une observation du comportement natif.

Cas concret : vous concevez un parcours de consultation de projet pour une équipe créative. Une disposition peut mettre en avant la prévisualisation, tandis qu’une autre doit rendre les commandes et les informations de contexte compréhensibles. Votre prototype doit montrer quelles commandes restent accessibles, ce qui change de place et ce qui arrive après une sélection. Si ces éléments ne sont pas encore décidés, marquez-les « à arbitrer » au lieu de choisir arbitrairement une variante et de la remettre comme spécification.

Questions fréquentes avant le transfert au développement

Comment transmettre un prototype Figma pour iPhone Duo à l’équipe de développement ?
Partagez un fichier ordonné et joignez une note qui désigne les écrans importants, les changements d’état, les interactions attendues et les décisions encore ouvertes. Pour une mise en page conditionnelle, expliquez le changement voulu et son objectif. Signalez également ce qui n’a pas été testé dans une application native : une image ou une interaction simulée dans le prototype ne prouve pas le comportement d’un build.

Quels états faut-il montrer pour expliquer une interface à deux écrans ?
Présentez les compositions et postures pertinentes pour le parcours réellement conçu. Pour chaque cas, indiquez les éléments qui se déplacent, les actions prioritaires, les contenus qui restent visibles et les transitions attendues. Appuyez-vous sur les indications Apple disponibles, puis écartez les variantes sans rapport avec votre produit. Si une posture ou une règle reste incertaine, demandez un arbitrage au lieu de la présenter comme une exigence confirmée.

Peut-on préparer un prototype iPhone Duo dans Figma depuis Windows ?
Oui, vous pouvez préparer les écrans, organiser les pages, rédiger les annotations et partager le fichier depuis Windows si votre accès Figma fonctionne dans le navigateur utilisé. Cette préparation permet de transmettre l’intention au développement, mais ne valide pas l’application native. Pour vérifier un build, vous devrez confirmer séparément les outils, les autorisations et l’environnement de test effectivement disponibles pour votre projet.

La validation native impose-t-elle toujours un Mac ?
Non, pas pour le travail de conception ou la clarification des exigences. Un Mac est à envisager lorsque votre contrôle nécessite des outils macOS ou une étape de développement qui ne peut pas être faite dans votre environnement actuel. Vérifiez d’abord que le build et la cible de test sont pris en charge. Ne réservez pas une machine en présumant qu’un simulateur iPhone Duo est disponible.

04

Transmettez une demande que l’équipe peut reproduire

Une passation efficace ne consiste pas à déposer un lien et à attendre que les développeurs devinent les intentions. Votre message doit permettre de retrouver le scénario concerné, de reproduire le problème ou la question, et de distinguer les décisions de conception des choix d’implémentation.

Pour chaque écran représentatif, transmettez :

  • le lien vers l’écran ou le parcours dans le fichier Figma ;
  • le contexte d’accès à l’écran et l’action qui mène à l’état montré ;
  • la posture ou la disposition visée, avec l’effet attendu sur les éléments visibles ;
  • les contenus et commandes prioritaires ;
  • le résultat attendu après l’interaction ;
  • les questions sans réponse, identifiées comme telles ;
  • la preuve disponible : spécification, capture de conception, observation d’un build ou observation sur un environnement de test confirmé.

Précisez qui doit répondre à chaque question. Le designer peut définir la hiérarchie visuelle et la continuité souhaitée ; le développeur doit confirmer la faisabilité de l’implémentation et signaler les contraintes observées dans son build. L’équipe produit peut trancher un comportement qui relève d’une décision fonctionnelle. Cette répartition ne doit pas empêcher les échanges : elle évite simplement de présenter une hypothèse technique comme une décision déjà vérifiée.

Si un défaut est signalé, décrivez les conditions de reproduction sans conclure à sa cause. Par exemple : « Dans cette disposition, après cette action, le contenu attendu devrait rester visible ; le résultat du build est à vérifier. » Ajoutez une capture de conception si elle aide à comprendre l’intention, mais étiquetez-la comme référence de conception. Ne l’utilisez pas comme preuve que l’application a été testée sur iPhone Duo.

05

Réservez la validation Mac après confirmation de l’environnement

Passez à la vérification native lorsque vous avez un objectif qui dépasse l’apparence du prototype : contrôler un comportement implémenté, reproduire un défaut dans le build ou examiner un parcours dans un environnement déclaré compatible. Avant d’organiser cette étape, demandez à l’équipe de développement ce qui est réellement prêt et ce que les ressources officielles confirment.

Le point de contrôle porte sur trois éléments :

  • Le build : l’application est-elle disponible dans une forme que l’équipe peut installer et exécuter pour le contrôle envisagé ?
  • La cible : l’appareil ou le simulateur nécessaire est-il confirmé pour ce cas de test ? Vérifiez l’information dans la documentation officielle actuelle, sans déduire la prise en charge de la seule présence d’un guide de conception.
  • Les outils : la version de Xcode et le système disponibles conviennent-ils au build et à la procédure retenue ? Consultez les notes de publication de Xcode 27.1 et les indications Apple associées avant de planifier la vérification.

Une ressource Apple explique également des opérations liées au simulateur dans Xcode. Elle peut aider votre équipe à comprendre le flux de travail du simulateur ; elle ne constitue pas, à elle seule, une confirmation que le simulateur prend en charge iPhone Duo. Si l’information manque ou reste ambiguë, faites confirmer la cible par les ressources Apple à jour ou par l’équipe qui prépare le build.

À ce stade, un Mac local et un Mac distant sont deux moyens possibles d’accéder à un environnement macOS ; aucun ne dispense de vérifier la prise en charge requise. Si vous travaillez sous Windows et devez seulement préparer la conception, un Mac n’est pas une condition à ajouter par réflexe. Si vous devez ouvrir des outils natifs pour une tâche identifiée, comparez les contraintes d’accès, de durée, de compte et de transfert de fichiers avant de choisir. Vous pouvez consulter les tarifs de location Mac de VpsMesh pour examiner les conditions affichées, puis vérifier qu’elles correspondent au besoin réel. Les détails commerciaux ne disent pas si un environnement donné prend en charge votre cible de test : ce point doit être confirmé séparément.

06

Décidez entre une préparation Figma et une validation native

Appliquez ces conditions avant de faire évoluer le statut du livrable :

  • Si le besoin porte sur la hiérarchie visuelle, les variantes et les interactions attendues, livrez le prototype Figma avec ses annotations. Indiquez explicitement que le comportement natif reste à vérifier.
  • Si les développeurs n’ont pas encore de build exécutable, poursuivez la préparation et la clarification des règles. Ne présentez pas l’absence de test natif comme un résultat positif ou négatif.
  • Si un build existe, mais que la compatibilité de la cible n’est pas confirmée, demandez une vérification de l’environnement avant de réserver du temps de test ou un Mac.
  • Si le build et la cible sont confirmés et que le contrôle exige des outils macOS, comparez un Mac local et un Mac distant selon l’accès, la durée et le transfert nécessaires au projet.
  • Si le test doit utiliser un appareil physique ou une interface matérielle particulière, vérifiez que l’environnement retenu donne réellement accès à cet équipement. Une machine distante ne garantit pas par elle-même un accès physique à un appareil.
  • Si aucune étape native n’est prévue, n’ajoutez pas de location Mac uniquement parce que le projet concerne une plateforme Apple. La conception, les annotations et la passation peuvent rester dans vos outils existants.

Le bénéfice de ce tri est concret : vous évitez de payer ou de mobiliser un environnement avant de savoir ce qu’il doit vérifier. À l’inverse, compter uniquement sur Figma alors que le livrable attendu est une validation de build laisse une lacune que les captures ne peuvent pas combler.

07

Fermez la livraison avec un statut vérifiable

À la fin du transfert, consignez les résultats sous trois statuts simples : vérifié, à vérifier et non applicable. Pour chaque ligne, ajoutez la nature de la preuve et son origine. Une annotation Figma prouve qu’une intention a été documentée ; une observation d’un build prouve un résultat dans le contexte où il a été exécuté ; une vérification sur appareil ne vaut que pour l’appareil et les conditions réellement utilisés.

Votre compte rendu peut suivre cette structure :

  • Conception vérifiée : les écrans et les intentions de mise en page ont été examinés dans le fichier partagé.
  • Comportement du build vérifié : l’équipe a décrit ce qu’elle a exécuté et ce qu’elle a observé.
  • Cible non confirmée : les informations officielles ou l’environnement de test ne permettent pas encore de conclure.
  • Limite de livraison : les éléments non testés sont nommés, avec la personne ou l’équipe qui doit les reprendre.

N’écrivez pas « compatible » si vous n’avez vérifié que les écrans statiques. N’écrivez pas « validé sur iPhone Duo » si aucune observation correspondante n’a été faite dans un environnement confirmé. Cette précision aide les personnes qui reprendront le projet et empêche qu’une maquette soit confondue avec un procès-verbal de test.

Pour une tâche native clairement identifiée, un Mac peut éviter de dépendre d’un poste personnel indisponible ou d’installer localement des outils que vous n’utiliserez que pour un contrôle ponctuel. En contrepartie, il faut encore organiser l’accès, le transfert de fichiers et la confirmation de la cible ; la location ne résout pas une prise en charge inconnue. Si votre équipe veut comparer cette option à un achat ou à un environnement déjà disponible, examinez les conditions de commande Mac de VpsMesh uniquement après avoir défini ce que le build doit valider. Si le projet n’exige encore que des écrans et des annotations, restez sur Figma ; si le test natif est requis et que l’environnement est confirmé, vous pourrez alors décider si un Mac distant répond à cette étape.