Les sites créés par IA sont-ils adaptés au mobile ?
Les sites créés par IA sont-ils adaptés au mobile ?
Oui, dans la très grande majorité des cas. Les pages produites par Zugo sont conçues pour s'adapter à l'écran qui les ouvre : les colonnes se superposent, le menu se replie, le texte se réagence. Ce qui reste à votre charge, c'est le contrôle sur un vrai téléphone, avec vos propres contenus dedans.
Car c'est bien là que les choses se gâtent. La structure s'adapte toute seule, mais un titre trop long, un tableau à six colonnes et une photo sortie d'un appareil photo viennent de vous, et ce sont eux qui cassent la mise en page sur un écran de la largeur d'une main.
Que veut dire « adapté au mobile », exactement ?
Cinq propriétés distinctes que l'usage rassemble sous une seule expression, alors qu'elles échouent séparément.
La mise en page se réorganise au lieu d'obliger à écarter les doigts. Le texte se lit sans zoomer. Les zones tactiles sont assez grandes et assez espacées pour qu'un pouce touche la bonne. Rien ne déborde sur la droite. Et la page se charge en un temps décent en données mobiles, pas seulement sur la fibre du bureau.
Une page peut réussir les quatre premières et échouer lourdement sur la cinquième, ce qui est le cas le plus fréquent pour un beau site généré portant une photo de bandeau non compressée. Traitez ces points comme une liste de contrôle et non comme un verdict global : les corrections sont différentes pour chacun.
Qu'est-ce qui est déjà correct en sortie de génération ?
La structure. La logique de mise en page produite s'adapte à la largeur disponible, donc les colonnes s'empilent, la navigation se replie et le texte se réagence sans que vous ayez à le demander. C'est le comportement par défaut, pas une option à activer.
Ce que la génération ne peut pas anticiper, c'est votre matière. Un nom de produit qui tient sur une ligne en grand écran passe sur trois lignes sur un téléphone. Un tableau comparatif à six colonnes n'a aucune place sur une largeur de 390 pixels. Une photographie nette sur un portable pèse plusieurs fois ce dont un téléphone a besoin.
Chaque projet est lancé dans un bac à sable avant d'être livré, et une version qui ne s'ouvre pas est signalée comme un échec au lieu d'être remise. Ce contrôle confirme que la page s'affiche. Il n'ouvre pas la page sur un téléphone et ne juge pas si votre titre s'est coupé au mauvais endroit : cette revue visuelle vous revient.
Qu'est-ce qui casse le plus souvent sur téléphone ?
Quatre choses, et elles reviennent avec une régularité étonnante.
| Symptôme | Cause habituelle | Retouche à demander |
|---|---|---|
| La page glisse vers la droite | Un tableau large, une image à largeur fixe, un mot très long | « fais défiler le tableau dans son propre cadre » |
| Le titre paraît cassé | Un texte écrit pour un écran large | Raccourcir le titre ou demander une taille réduite sur mobile |
| Les boutons sont durs à toucher | Des liens serrés les uns contre les autres | « agrandis les boutons et écarte les davantage » |
| La page met une éternité | Une photo pleine résolution en bandeau | Redimensionner et compresser l'image avant de l'envoyer |
La dernière ligne n'est pas vraiment un problème de mise en page, et c'est pourtant celle qui coûte le plus de visiteurs. Une photo sortie telle quelle d'un appareil peut peser plus lourd que tout le reste de la page réuni, et aucune consigne ne répare un fichier déjà envoyé : il faut le remplacer par une version à la taille réellement affichée.
Le débordement latéral mérite aussi un mot, parce que c'est le plus difficile à repérer. Sur un écran d'ordinateur, vous ne le voyez jamais. Sur un téléphone, la page entière se décale et donne une impression de site cassé, à cause d'un seul élément qui refuse de rétrécir. La question du poids des pages est traitée dans ce qui décide de la vitesse d'une page.
Comment tester correctement en cinq minutes ?
Sur un vrai téléphone, à l'adresse publiée, en données mobiles. Chaque partie de cette phrase compte.
- Ouvrez
votre-slug.zugo.runsur votre propre téléphone. Une fenêtre de navigateur rétrécie n'est pas un téléphone : les polices s'affichent autrement et les zones tactiles n'existent pas à la souris. - Coupez le wifi. Le réseau du bureau masque exactement les poids de fichiers qui gênent vos visiteurs dans le train ou dans la rue.
- Utilisez le site d'une seule main, au pouce. Un pointeur de souris est infiniment plus précis qu'un pouce, et cette différence décide de la moitié des abandons.
- Tenez l'appareil à bout de bras. Un texte que vous lisez penché sur l'écran est souvent trop petit en usage réel.
- Envoyez réellement un formulaire. Le clavier recouvre les champs, et ce défaut n'apparaît sur aucun aperçu.
Deux personnes, deux téléphones, cinq minutes chacune : c'est un meilleur test que n'importe quel simulateur. Demandez leur d'accomplir l'action pour laquelle la page existe, et regardez à quel moment leur pouce hésite.
Le mobile change-t-il aussi ce qu'il faut mettre en avant ?
Oui, et c'est la partie que l'on oublie en ne parlant que de mise en page. Sur téléphone, le visiteur ne balaie pas la page du regard : il descend en colonne, donc l'ordre des sections devient l'ordre de lecture.
Remontez ce qui déclenche l'action. Pour un artisan, un restaurant ou un cabinet, le numéro de téléphone cliquable, l'adresse et les horaires valent plus haut dans la page que la présentation de l'entreprise. Une retouche du type « place le bloc contact juste sous le titre sur mobile » se demande en une phrase.
Raccourcissez aussi les formulaires. Chaque champ supplémentaire se paie beaucoup plus cher au clavier tactile qu'au clavier physique, et demander le bon type de saisie, clavier numérique pour un téléphone, clavier courriel pour une adresse, évite des erreurs de frappe qui vous coûtent des demandes de devis.
Comment formuler la retouche pour qu'elle porte ?
En décrivant le problème comme vous l'avez vu, pas en réclamant une qualité générale. « Rends le site adapté au mobile » donne peu de résultats, parce que la page l'est déjà dans sa structure : c'est un élément précis qui ne l'est pas.
Écrivez plutôt : « sur téléphone, le tableau des tarifs dépasse à droite, fais le défiler dans son propre cadre » ou « sur téléphone, le bouton de réservation passe sous la photo, remonte le au dessus ». La retouche vise alors un seul endroit et ne déplace pas le reste de la page.
Une correction par message, et un coup d'œil sur le téléphone entre chaque. À 3 crédits la retouche, cette boucle courte revient moins cher qu'une longue consigne parfaite écrite d'avance, et elle se trompe moins souvent. La mécanique de ces allers retours est détaillée dans modifier un projet après génération.
Les jeux 2D fonctionnent-ils aussi au doigt ?
Ils tournent dans le navigateur d'un téléphone, oui, mais le mode d'échec est différent et mérite sa propre vérification. Un jeu conçu au clavier n'a tout simplement aucune commande sur un écran tactile si vous ne les avez pas demandées.
Nommez donc les commandes tactiles dans la description : ce que fait un appui, ce que fait un balayage, où se placent les boutons. Testez ensuite avec votre pouce plutôt qu'en relisant la description. Les jeux sont produits en 2D et dans le navigateur, ce qui constitue à la fois une vraie couverture et une vraie frontière.
L'autre sujet propre au téléphone est la forme de l'écran. Une aire de jeu pensée large peut envoyer le score dans un coin inatteignable en mode portrait. Demander une disposition verticale est une retouche ordinaire. Le tour d'horizon complet se trouve dans l'IA peut-elle créer un jeu jouable.
Combien coûte une correction mobile ?
Une retouche dans presque tous les cas, puisqu'il s'agit de modifier votre projet et non la plateforme.
| Action sur Zugo | Crédits |
|---|---|
| Construction d'un site, d'une app ou d'un jeu | 6 |
| Retouche d'un projet existant | 3 |
| Plateforme multipage, trois premières pages | 12 |
| Chaque page supplémentaire ensuite | 3 |
| Construction en mode Hi-Fi | 12 |
| Retouche en mode Hi-Fi | 6 |
À 3 crédits la retouche, une série de corrections mobiles se tente sans arbitrage douloureux. Pro coûte $25 par mois pour 200 crédits, soit 66 retouches si vous ne dépensez que sur ce poste, donc le budget est rarement ce qui limite la finition. Business coûte $99 par mois pour 800 crédits, et le plan gratuit donne 5 crédits, de quoi voir l'outil fonctionner.
Quelles sont les limites honnêtes ?
Trois, dites simplement.
Un projet publié n'est pas une application native. Ce que vous obtenez tourne dans le navigateur mobile. La page s'ajoute à l'écran d'accueil, et cela ne vaut pas une fiche sur les boutiques d'applications, qui relève d'un autre travail.
Le contrôle en bac à sable porte sur l'ouverture, pas sur l'apparence. Il confirme que la version s'est affichée. Il ne note pas la mise en page et ne vous préviendra pas qu'un titre s'est coupé en quatre lignes.
L'optimisation poussée reste un travail d'ingénierie. Un tableau de bord branché sur des données réelles, ou un jeu chargé sur un téléphone ancien, pose des questions de performance qu'aucun conseil de mise en page ne couvre. Zugo ne remplace pas une équipe de développement sur ce terrain. La lisibilité pour tous les visiteurs est un sujet voisin, traité dans l'accessibilité d'un site créé par IA.
Par où commencer concrètement ?
Publiez une seule page avant d'ajouter quoi que ce soit, puis ouvrez son adresse sur votre téléphone, en données mobiles, une main dans la poche. Vous verrez en une minute ce que trois relectures sur ordinateur n'auraient pas montré.
Corrigez ensuite dans cet ordre : le débordement latéral, le poids des images, la taille des zones tactiles, puis l'ordre des sections. C'est la séquence qui donne le plus de résultat pour le moins de retouches. Vous pouvez décrire votre première page sur zugo.dev et faire ce test avant d'aller plus loin.