Chaque mise en page de votre app porte une hypothèse que personne n'a écrite : l'écran est un rectangle, il garde la même forme tant que l'app est ouverte, et l'utilisateur la tient d'une main à environ trente centimètres du visage.
Trois de ces hypothèses sont désormais optionnelles.
L'hypothèse qui casse vraiment
Il est tentant de classer ça dans le responsive design et de passer. Les développeurs gèrent des tailles d'écran multiples depuis quinze ans — ce ne sont que quelques tailles de plus.
Ce cadrage rate ce qui a changé. Le responsive suppose que le viewport est fixé au lancement. On vérifie la largeur une fois, on choisit une mise en page, on rend. Les pliables cassent cela : l'écran change de forme pendant que votre app tourne — en pleine tâche, parfois en pleine frappe. Une app qui lit ses dimensions au démarrage et met en cache une décision de mise en page fera quelque chose de visiblement faux au premier dépliage.
La deuxième hypothèse cassée : que tout l'écran est utilisable. Un appareil plié a une charnière qui le traverse. Un contenu placé sous ce pli n'est pas seulement laid — il est illisible, et un bouton à cet endroit n'est pas fiable.
Pliables : un appareil, deux appareils
Le bon modèle mental : un pliable, ce sont deux appareils qui partagent un processus — et votre app doit être les deux.
Plié, c'est un téléphone étroit — souvent plus étroit qu'un téléphone standard, ce qui surprend les équipes dont les largeurs minimales ont été calées sur un iPhone. Déplié, c'est une petite tablette au format plus carré que toutes celles où vous avez testé.
La transition entre les deux est là où vit l'ingénierie. Quand quelqu'un déplie en pleine tâche, trois choses doivent survivre : sa position de défilement, son état de saisie et son focus. Perdre un message à moitié tapé parce que l'utilisateur a ouvert l'appareil, c'est le genre de bug qui fait supprimer une app — et c'est le comportement par défaut si vous laissez l'OS recréer votre activité sans le gérer.
Il y a aussi un état intermédiaire. Les appareils qui restent à demi ouverts — posés sur un bureau, caméra en haut, contenu en bas — permettent des modes réellement utiles pour la visio et la photo. Le prendre en charge est optionnel. Savoir qu'il existe, pour que votre mise en page ne s'effondre pas en quelque chose d'absurde, ne l'est pas.
Fig. — Une app, trois postures. Le dur, ce sont les transitions, pas les mises en page.
Les wearables ont un tout autre budget
Une montre n'est pas un petit téléphone — et la traiter comme tel produit les apps que personne n'ouvre deux fois.
La contrainte n'est pas la taille de l'écran. C'est le budget d'interaction — l'attention totale qu'un utilisateur dépensera avant d'abandonner. Sur un téléphone, ce budget se compte en minutes. Sur une montre, c'est à peu près le temps qu'on tient le bras levé — quelques secondes.
Ce seul fait devrait décider de ce que vous construisez. Une app de montre qui exige de faire défiler une liste, sélectionner un élément et confirmer a déjà dépassé le budget. Une app qui montre la seule chose pertinente, avec au plus une action, tient dedans.
La réponse honnête pour la plupart des produits : la surface montre est une notification et un coup d'œil, pas une app. Le suivi de livraison, la carte d'embarquement, le seul chiffre qui compte. Construire une hiérarchie de navigation complète pour une montre est une erreur courante et coûteuse — l'effort y passe, l'usage ne vient jamais, et l'équipe conclut que les wearables ne comptent pas, alors que ce qu'elle a construit était une app de téléphone sur petit écran.
Le spatial : intéressant — et pas encore votre problème
Les casques attirent une part de conversations stratégiques disproportionnée par rapport à leur parc installé, et il vaut la peine d'être direct sur le calendrier.
Pour l'écrasante majorité des apps, la bonne stratégie spatiale cette année est de s'assurer que l'app existante tourne correctement dans une fenêtre de compatibilité — et de dépenser l'ingénierie ailleurs. Le nombre d'appareils ne justifie pas encore un build dédié pour une app généraliste.
Les exceptions sont réelles mais étroites : formation et simulation, données 3D complexes, assistance à distance où voir les mains de l'autre change réellement le résultat. Si votre produit est dans un de ces champs, le calcul est différent et mérite un investissement sérieux. Sinon, une présence sur un store à faible parc est un projet de vanité avec un coût d'entretien.
Le problème du test
Voici l'obstacle pratique qui arrête la plupart des équipes — et ce n'est ni le design ni le code.
On ne teste pas correctement un pliable sans pliable. Les émulateurs gèrent la géométrie — ils montrent une mise en page pliée et dépliée, et déclenchent le changement de configuration. Ce qu'ils ne reproduisent pas : la sensation de la charnière sous un pouce, le pli qui tombe sur votre action principale, ou la transition à pleine vitesse sur du vrai matériel.
Même chose pour les montres, en plus aigu. Un cadran rendu à 400 % sur un écran de bureau ne dit rien de la lisibilité au poignet, en plein jour, en marchant.
Budgétez au moins un appareil physique par facteur de forme que vous prétendez prendre en charge. C'est un coût matériel modeste face à l'alternative : découvrir votre problème de mise en page dans un avis une étoile qui le décrit mal.
Le test automatisé aide sur la partie mécanique. Un test qui passe par chaque classe de taille de fenêtre et vérifie que rien ne déborde, qu'aucun élément interactif ne tombe sous la charnière, et que l'état survit au changement de configuration attrape la plupart des régressions à bas coût. Monté une fois, il vous protège sur chaque appareil qui sortira ensuite.
Ce qui change vraiment dans votre code
Cessez de lire le type d'appareil et lisez la taille de la fenêtre — en continu. Les deux grandes plateformes exposent désormais des classes de taille qui décrivent la fenêtre courante plutôt que le matériel, et toutes deux émettent des mises à jour quand elle change. Le code qui branche sur « est-ce une tablette » est déjà faux sur un pliable.
Rendez la survie de l'état explicite. Supposez que votre interface peut être détruite et recréée à tout instant — et que tout ce qui n'est pas délibérément sauvegardé est perdu. Terrain bien connu sur Android ; nouvellement pertinent pour beaucoup de code iOS.
Construisez pour une plage, pas pour des points de rupture. Les mises en page accrochées à trois largeurs précises cassent sur le quatrième appareil — et il y a toujours un quatrième appareil. L'adaptation continue — un contenu qui se recompose au lieu de basculer entre des designs figés — coûte plus au départ et plus rien ensuite.
Et gérez la charnière, que les API des plateformes décrivent pour vous : où elle est, dans quel sens elle court, si l'appareil est plié. L'ignorer, c'est mettre un bouton dans un pli.
Encore une chose qui piège les équipes : les méthodes d'entrée se multiplient avec les écrans. Un appareil déplié est assez grand pour qu'on y branche un clavier. Une montre prend la voix et une couronne. Un pliable format tablette s'utilise au stylet. Le code qui suppose que le tactile est la seule entrée semblera subtilement cassé sur tous — pas de raccourcis clavier, pas d'anneau de focus, pas d'ordre de tabulation sensé.
Ce travail est surtout du travail d'accessibilité sous un autre chapeau. Une app avec un vrai ordre de focus et un vrai support clavier en gère déjà l'essentiel — une raison de plus pour laquelle l'investissement accessibilité continue de payer à des endroits que personne n'avait prédits.
Comment prioriser
Vérifiez vos analytics avant toute décision. La part des pliables varie énormément selon les marchés — significative dans certaines parties d'Asie, négligeable ailleurs — et le bon investissement dépend de vos utilisateurs, pas de la tendance générale.
Si vous trouvez un vrai usage pliable, le travail vaut d'être fait proprement et il n'est pas énorme : mises en page continues, préservation d'état, conscience de la charnière. L'essentiel améliore au passage votre expérience tablette — et c'est la partie qui fait le business case.
Si vous trouvez des utilisateurs de montre, construisez le coup d'œil, pas l'app.
Il y a un angle commercial à soulever avec qui tient le budget. Les possesseurs de pliables penchent vers le haut de gamme de chaque marché où ils existent — ce sont des appareils chers, achetés délibérément. Si votre produit monétise, ce segment vaut disproportionnellement plus que sa part d'installations — et une app qui se comporte mal une fois dépliée échoue devant précisément les utilisateurs que vous voudriez le plus garder.
Le même argument court en sens inverse pour les montres. Les utilisateurs de montre sont engagés, mais la surface ne génère presque aucun revenu direct — le dossier d'investissement repose donc sur la rétention et l'habitude, pas la conversion. Être honnête sur lequel des deux vous achetez évite l'issue classique : une équipe livre une app montre, ne voit aucun mouvement de revenu, et l'abandonne en silence.
Et si vous ne trouvez ni l'un ni l'autre, le geste utile est d'arrêter d'écrire du code qui rendra tout cela difficile plus tard. Une app bâtie sur l'adaptation à la taille de fenêtre et une gestion d'état disciplinée portera la prochaine forme venue sans réécriture. Une app bâtie sur trois points de rupture codés en dur et des décisions de mise en page en cache en exigera une — à chaque fois.
