Création de site Internet à Douai, par votre agence web dynamique : nos devis sont gratuits

La souris désigne un point, le doigt désigne une surface. Cette différence, énoncée ainsi, semble anodine ; elle est à l'origine d'une bonne moitié des frustrations mobiles. Un pointeur de souris permet de viser un lien de douze pixels de haut sans hésiter, avec un retour visuel immédiat au survol et la possibilité de corriger avant de cliquer. Un doigt posé sur une dalle en verre couvre une zone bien plus large que le point que l'utilisateur croit viser, il masque la cible au moment même où il l'atteint, et il n'offre aucun état intermédiaire entre « pas encore » et « c'est fait ». Concevoir une interface tactile, c'est donc concevoir pour un instrument imprécis, opaque et sans droit à l'erreur. Les recommandations d'ergonomie mobile convergent depuis longtemps vers un ordre de grandeur : une cible interactive confortable occupe environ quarante-quatre à quarante-huit pixels de côté, avec un espacement suffisant pour que deux cibles voisines ne se confondent pas.

Dans la pratique, les manquements que nous relevons sont toujours les mêmes. Les icônes de réseaux sociaux alignées dans le pied de page, minuscules et collées les unes aux autres, où l'on atteint invariablement la mauvaise. Les liens du fil d'Ariane, séparés par des chevrons, qui forment une ligne de texte dans laquelle rien n'est visé de façon fiable. Les cases à cocher de consentement, dont la case elle-même mesure quinze pixels et dont le libellé n'est pas cliquable, alors qu'une case correctement associée à son étiquette offre une cible dix fois plus grande pour zéro effort de développement. Les boutons « plus / moins » d'un sélecteur de quantité sur une boutique en ligne, si serrés qu'on passe de un à trois articles sans le vouloir. Les onglets d'un tableau de tarifs, prévus pour être survolés et non touchés. Aucun de ces défauts n'apparaît sur une capture d'écran ; tous apparaissent à la première utilisation réelle.

La géométrie de la main, et le bas de l'écran

Il faut ensuite tenir compte d'un fait physique que les maquettes ignorent : la main tient le téléphone, et le pouce n'atteint pas confortablement toute la surface. Sur un appareil moderne, dont la diagonale dépasse souvent seize centimètres, la zone facile d'accès pour un usage à une main forme un arc dans la moitié basse de l'écran, du côté du pouce. Le haut de l'écran, et en particulier les coins supérieurs, demande de repositionner l'appareil dans la paume — un geste que l'on fait volontiers deux fois, moins volontiers dix. Or c'est précisément en haut à droite que la tradition du web place l'icône du menu, et en haut de page que se trouvent les liens principaux. Cette contradiction n'est pas dramatique en soi, elle explique cependant pourquoi les interfaces mobiles récentes ramènent les actions fréquentes vers le bas : barre d'action fixe, bouton d'appel flottant, navigation en pied d'écran.

Pour une entreprise de services du Douaisis, la traduction est simple et rentable. Un plombier de Lallaing, un couvreur de Râches, un dépanneur de Guesnain ont tout intérêt à disposer d'une barre discrète et permanente en bas de l'écran mobile, comportant deux actions et pas davantage : appeler, et demander un devis. Cette barre ne gêne pas la lecture si elle est fine et sobre, elle est atteignable sans changer la prise en main, et elle supprime la question « où est le numéro ? » à tout moment du parcours. Nous mesurons régulièrement l'effet de cet ajout sur des sites existants, et il est de ceux qui se voient dans les statistiques d'appel dès les premières semaines, pour un coût d'intégration qui se compte en heures. C'est le genre d'arbitrage qu'un site conçu par réduction du bureau ne fait jamais, parce que la question ne se pose pas sur un grand écran.

Un formulaire est l'endroit où votre site cesse d'être une brochure pour devenir un outil commercial, et c'est aussi l'endroit où le mobile est le plus impitoyable. Remplir douze champs au clavier physique d'un ordinateur, avec la souris pour passer de l'un à l'autre et le tabulateur pour aller vite, demande peu d'effort. Remplir ces mêmes douze champs sur un écran de six pouces, avec un clavier virtuel qui occupe la moitié basse de la surface, sans vision d'ensemble du formulaire, en tenant l'appareil d'une main dans une camionnette ou sur un quai, relève d'une autre catégorie d'exercice. Chaque champ superflu, chaque libellé ambigu, chaque erreur de validation mal formulée est une occasion d'abandonner, et l'abandon sur mobile est silencieux : personne ne vous écrit pour vous dire qu'il a renoncé à votre formulaire de devis.

Le défaut le plus fréquent et le plus facile à corriger concerne le clavier lui-même. Lorsqu'un utilisateur touche un champ situé dans la moitié basse de l'écran, le clavier virtuel apparaît et pousse ou recouvre le contenu. Sur un formulaire correctement intégré, le navigateur fait remonter le champ actif au-dessus du clavier et tout se passe bien. Sur un formulaire enfermé dans une fenêtre modale à hauteur fixe, ou dans un conteneur qui gère lui-même son défilement, ou surmonté d'un en-tête fixe trop haut, le champ actif se retrouve caché derrière le clavier : l'utilisateur tape à l'aveugle, ne voit pas ce qu'il écrit, ne voit pas non plus le message d'erreur qui s'affiche sous le champ, et abandonne. Ce défaut ne se voit jamais sur une maquette et rarement dans un simulateur de navigateur, parce que le simulateur n'affiche pas de vrai clavier. Il se voit en dix secondes sur un vrai téléphone, ce qui explique pourquoi il survit si souvent jusqu'en production.

Le bon clavier, du premier coup

Un deuxième levier, gratuit et massivement ignoré, consiste à demander au système le clavier adapté à chaque champ. Un champ de numéro de téléphone doit ouvrir le pavé numérique, un champ d'adresse électronique doit afficher l'arobase et le point directement accessibles, un champ de code postal doit proposer des chiffres. Cela se déclare en un attribut sur chaque champ, cela ne coûte rien, et cela supprime pour l'utilisateur une série de basculements entre claviers alphabétique et numérique qui, additionnés sur un formulaire de six champs, représentent un agacement réel. Dans le même esprit, l'attribut de remplissage automatique permet au téléphone de proposer le nom, l'adresse électronique et le numéro déjà enregistrés : un formulaire correctement annoté se remplit en trois touches sur un appareil bien configuré, contre une minute de saisie sur un formulaire qui ne déclare rien. Nous vérifions systématiquement ces attributs en recette, parce qu'ils font partie des rares améliorations dont le rapport entre effort et effet est sans discussion.

Restent les messages d'erreur, qui décident du sort d'une demande à moitié remplie. Une erreur doit apparaître à côté du champ concerné, en toutes lettres, et expliquer quoi corriger — « le numéro doit comporter dix chiffres » plutôt que « champ invalide ». Elle doit apparaître au moment où l'utilisateur quitte le champ, pas seulement après l'envoi, faute de quoi il découvre trois erreurs d'un coup en bas d'un formulaire qu'il croyait terminé. Et surtout, la validation ne doit jamais vider ce qui a été saisi : perdre un paragraphe de description de chantier tapé au pouce parce qu'un champ voisin était mal rempli est le meilleur moyen de ne jamais revoir ce prospect. Enfin, la page de confirmation doit exister et dire clairement ce qui va se passer et dans quel délai ; un formulaire qui se contente de se vider laisse l'utilisateur dans le doute, et le doute pousse à envoyer la même demande au concurrent pour être sûr.

Les images représentent, sur la grande majorité des sites vitrines que nous auditons, entre soixante et quatre-vingts pour cent du poids total des pages. C'est le premier poste de dépense en octets, très loin devant le code, et c'est aussi celui sur lequel les gains sont les plus immédiats. Le mécanisme du problème est toujours le même. Une photographie sort d'un appareil ou d'un téléphone récent en quatre à six mille pixels de large et pèse plusieurs méga-octets. Elle est déposée telle quelle dans le gestionnaire de contenu, affichée dans un emplacement qui fait huit cents pixels de large sur un écran de bureau et trois cent cinquante sur un téléphone. Visuellement, tout va bien : le navigateur réduit l'image à la taille demandée. En réalité, l'appareil a téléchargé l'intégralité du fichier d'origine, l'a décodé en mémoire, l'a redimensionné, et a dépensé pour cela du temps, de la batterie et du forfait. Multipliez par les douze images d'une page d'accueil et vous obtenez une page de quinze méga-octets qui s'affiche impeccablement sur l'ordinateur de celui qui l'a mise en ligne.

Sur une connexion en fibre, cette page se charge en une poignée de secondes et le problème reste invisible. C'est là que le contexte local cesse d'être un argument commercial pour devenir une donnée technique. Le déploiement de la fibre dans le bassin douaisien est avancé sur la ville-centre et sur les communes les plus denses, mais il reste inégal dès qu'on s'éloigne : des zones d'activité, des lotissements récents, des communes rurales de l'Arleusien ou du secteur de Marchiennes fonctionnent encore avec un cuivre fatigué qui plafonne à quelques mégabits. Et la couverture mobile suit la même géographie contrastée : très bonne le long des axes et dans les centres, plus capricieuse dans les zones intermédiaires, avec des replis en réseau plus ancien qui divisent le débit réel par dix sans prévenir. Le client qui consulte votre site depuis un chantier à Auberchicourt, un parking d'entreprise à Dechy ou une exploitation près d'Arleux ne subit pas votre page dans les conditions du studio où elle a été validée.

Le coût se paie deux fois

Une image trop lourde coûte du temps de transfert, ce que tout le monde comprend, mais elle coûte aussi du temps de traitement, ce que l'on oublie. Décoder un fichier de six mille pixels de large mobilise le processeur et la mémoire d'un appareil qui n'est pas forcément un modèle haut de gamme. Sur les téléphones d'entrée et de milieu de gamme, qui composent une part très importante du parc réel, ce décodage produit un blocage perceptible : le défilement saccade, le bouton touché ne réagit pas immédiatement, l'interface paraît engluée. L'utilisateur n'attribue pas cette sensation à une image, il l'attribue au site — et par extension à l'entreprise. Il y a une injustice là-dedans, mais elle est sans recours : la perception de sérieux se construit aussi avec des millisecondes.

Il y a enfin un coût que personne ne facture explicitement et que tout le monde ressent : le forfait de données. Une page de quinze méga-octets consommée trois fois dans la journée, c'est une entame sensible sur un forfait modeste, et un certain nombre de visiteurs — jeunes, saisonniers, personnes en fin de mois — arbitrent réellement en fonction de cela. Réduire ce poids n'est pas un raffinement d'ingénieur : c'est une politesse envers le visiteur, et c'est de la considération commerciale. Nous ramenons couramment le poids d'une page d'accueil de plusieurs méga-octets à quelques centaines de kilo-octets sans que le rendu visuel change de façon perceptible, simplement en préparant correctement les visuels et en servant à chaque appareil une version dimensionnée pour lui. C'est l'un des chantiers que nous chiffrons systématiquement dans un audit technique et sémantique mené sur Douai, parce qu'il figure presque toujours parmi les trois corrections les plus rentables du plan d'action.

Le choix typographique est l'un des rares sujets où une décision purement esthétique produit des conséquences techniques directes et mesurables. Une police personnalisée est un fichier que le navigateur doit télécharger avant de pouvoir dessiner le texte avec elle. Tant que ce fichier n'est pas arrivé, deux comportements sont possibles selon la configuration : soit le navigateur affiche le texte avec une police système en attendant, puis bascule quand la police définitive arrive — on voit alors le texte changer d'apparence en cours de lecture ; soit il n'affiche rien du tout pendant un délai qui peut atteindre trois secondes, et le visiteur regarde une page où les images sont là, la mise en page est en place, et les textes sont absents. Ce second comportement, le texte invisible, est de loin le plus dommageable, parce qu'une page sans texte est une page sans information : le visiteur ne peut ni lire, ni décider, ni comprendre où il est tombé.

La correction tient en une ligne de déclaration, et elle est trop peu appliquée. Il s'agit d'indiquer explicitement au navigateur qu'il doit afficher immédiatement le texte avec une police de substitution, puis échanger dès que la police définitive est prête. Le visiteur voit alors le contenu tout de suite, au prix d'un léger changement d'apparence quelques centaines de millisecondes plus tard. Ce changement peut lui-même être rendu presque imperceptible si l'on choisit une police de substitution dont les proportions sont proches de la police finale, et si l'on ajuste les métriques de repli. C'est un travail de finition, mais il fait la différence entre une page qui semble s'assembler proprement et une page qui tressaute.

Combien de polices, combien de graisses

Le deuxième levier est arithmétique. Chaque famille typographique, chaque graisse et chaque style constituent un fichier distinct. Un site qui utilise deux familles, chacune en régulier, semi-gras et gras, plus les italiques correspondantes, télécharge douze fichiers avant d'afficher son premier paragraphe complet. Nous ramenons presque toujours cela à deux ou trois fichiers, sans appauvrir le rendu : une seule famille bien choisie, deux graisses, et l'italique uniquement si le contenu en fait un usage réel. Les polices variables ont d'ailleurs largement changé la donne, puisqu'un seul fichier peut couvrir tout un continuum de graisses pour un poids à peine supérieur à celui d'une graisse unique. Il faut aussi limiter les jeux de caractères embarqués : une police qui inclut le cyrillique, le grec et les caractères vietnamiens pèse plusieurs fois le poids nécessaire à un site francophone, et le sous-ensemble latin étendu suffit dans l'écrasante majorité des cas.

Le troisième levier concerne la provenance des fichiers. Longtemps, la pratique dominante a consisté à appeler les polices depuis un service tiers, en une ligne. C'est commode et cela ajoute une résolution de nom de domaine, une négociation de connexion sécurisée et une dépendance à un serveur que vous ne maîtrisez pas, le tout sur le chemin critique de l'affichage. Héberger les fichiers de police sur votre propre domaine supprime ces étapes, permet de les précharger explicitement et donne la maîtrise des en-têtes de cache. Cette pratique a par ailleurs l'avantage de simplifier considérablement la situation au regard de la protection des données personnelles, puisqu'elle évite de transmettre l'adresse IP de vos visiteurs à un tiers sans leur consentement — un point sur lequel la vigilance des autorités s'est nettement renforcée ces dernières années, et que nous traitons par défaut sur tous les sites que nous livrons.

Google publie depuis quelques années trois indicateurs censés résumer l'expérience vécue par un visiteur sur une page. Leurs sigles anglais n'aident personne, et beaucoup d'entreprises se sont mises à parler de « bons scores » sans avoir jamais compris ce qu'ils décrivent, quitte à optimiser un chiffre plutôt qu'une expérience. Ces trois mesures ne sont pourtant ni ésotériques ni arbitraires : chacune correspond à une question très concrète que se pose un être humain devant un écran. Combien de temps avant que je voie quelque chose d'utile ? Est-ce que ça réagit quand je touche ? Est-ce que ça bouge sous mes yeux pendant que je lis ?

La première mesure, celle du plus grand élément affiché, répond à la question du délai avant contenu utile. Le navigateur repère l'élément le plus imposant visible dans la fenêtre — le plus souvent l'image de tête, parfois un gros titre ou un bloc de texte — et enregistre le moment où il apparaît. Ce moment marque, pour l'utilisateur, l'instant où la page cesse d'être une promesse et devient une information. Le seuil considéré comme bon se situe autour de deux secondes et demie chez de vrais visiteurs, ce qui est plus exigeant qu'il n'y paraît sur un réseau mobile ordinaire, et les causes de dépassement tiennent dans une liste courte : un serveur lent à répondre, une image de tête trop lourde ou différée à tort, des ressources bloquantes, ou un contenu principal fabriqué par script après coup.

La deuxième mesure évalue la réactivité aux interactions. Elle a remplacé un indicateur plus ancien qui ne regardait que le tout premier contact ; celle qui est en vigueur observe l'ensemble des interactions de la visite et retient la pire, ce qui est nettement plus honnête. Concrètement, elle chronomètre le délai entre le moment où vous touchez un bouton et le moment où l'écran montre le résultat de ce toucher. Le seuil de confort se situe autour de deux dixièmes de seconde : en dessous, l'interface paraît instantanée ; au-delà, elle paraît molle, puis cassée. La cause dominante est celle décrite plus haut, un fil d'exécution monopolisé par du JavaScript, et c'est la raison pour laquelle cet indicateur pénalise sévèrement les sites chargés de greffons. Il a aussi le mérite d'être le plus proche du ressenti : personne ne mesure une seconde et demie, tout le monde sent qu'un bouton n'a pas répondu.

La troisième mesure quantifie l'instabilité de la mise en page. Elle additionne les déplacements inattendus des éléments visibles pendant le chargement, pondérés par la surface concernée. C'est la traduction chiffrée d'une expérience que tout le monde a vécue : on commence à lire, un bloc surgit au-dessus, le texte descend, on perd sa ligne ; ou pire, on s'apprête à toucher un lien, une bannière s'insère, et le doigt atterrit sur un bouton que l'on ne voulait pas. Les causes tiennent en quatre points et se corrigent toutes en amont : les images sans dimensions déclarées, les publicités ou encarts insérés dans le flux sans espace réservé, le bandeau de consentement ajouté après le premier rendu, et la bascule de police mal gérée qui redimensionne les blocs de texte. Sur ce troisième indicateur, une page correctement construite atteint un score quasi parfait sans effort particulier ; un score dégradé signale presque toujours un défaut d'intégration, pas une fatalité.

Il faut ajouter une précision importante : ces trois mesures ne sont pas un facteur de classement dominant, et les présenter comme tel serait malhonnête. Un site rapide et stable ne dépassera pas un concurrent mieux positionné sur le fond et mieux entouré de liens. En revanche, à qualité comparable, elles départagent ; et surtout, elles agissent en amont du référencement, sur le comportement réel des visiteurs que le référencement vous amène. Un site lent gaspille son trafic, quelle que soit sa position. C'est de cette manière que nous les présentons dans nos missions de conseil en référencement : non comme un objectif en soi, mais comme la garantie que le travail de visibilité ne se déverse pas dans un seau percé.

Tout ce qui précède concerne ce que l'on envoie au navigateur. Reste la question de la vitesse à laquelle on commence à l'envoyer, et celle-ci se joue sur le serveur. Le temps de réponse initial — le délai entre la demande du navigateur et l'arrivée du premier octet — conditionne mécaniquement tout le reste : aucune optimisation d'image ne rattrape un serveur qui met huit cents millisecondes à se décider. Sur une offre mutualisée d'entrée de gamme, votre site partage une machine avec des dizaines, parfois des centaines d'autres, et il partage aussi le processeur, la mémoire et les accès disque. Tant que les voisins sont calmes, tout va bien. Quand l'un d'eux subit un pic de trafic, lance une sauvegarde ou fait tourner un script mal écrit, votre site ralentit sans que vous ayez rien changé, et sans que rien dans votre tableau de bord ne l'explique.

Il ne s'agit pas de condamner le mutualisé, qui reste un excellent rapport qualité-prix pour une grande partie des sites vitrines. Il s'agit d'en connaître les limites et de savoir les reconnaître quand on les atteint. Les symptômes sont assez caractéristiques : des temps de réponse très variables selon l'heure, une lenteur marquée en fin de matinée et en début de soirée, des pics d'attente inexpliqués qui apparaissent dans les journaux du serveur, une administration du gestionnaire de contenu devenue pénible alors que le site public paraît correct, des sauvegardes qui échouent faute de mémoire. Quand ces signes s'installent, changer d'image ou de script ne servira à rien : le goulot est ailleurs. Il faut alors envisager une offre avec des ressources garanties, un serveur privé virtuel ou un hébergement infogéré spécialisé, en gardant à l'esprit que la différence de prix se compte souvent en quelques dizaines d'euros par mois — un montant à comparer au coût d'une demande de devis perdue par semaine.

Ce qu'il faut regarder au-delà du prix mensuel

Plusieurs caractéristiques comptent davantage que la promesse d'espace disque illimité. La version de l'environnement d'exécution, d'abord : une version récente du langage serveur apporte des gains de vitesse substantiels par rapport à une version vieille de cinq ans, et beaucoup de sites tournent encore sur des versions dépassées, exposées de surcroît à des failles connues. La localisation physique du serveur ensuite : un site dont la clientèle est douaisienne n'a aucun intérêt à être hébergé sur un autre continent, chaque aller-retour réseau coûtant un temps incompressible dicté par la distance. La présence d'un cache serveur et d'un accélérateur d'objets, qui évite de reconstruire la page à chaque visite. La qualité des sauvegardes, leur fréquence, et surtout la possibilité de les restaurer soi-même sans passer par un support qui répond en trois jours. Et la disponibilité des journaux d'accès, indispensables pour comprendre à la fois le comportement des robots et les anomalies de performance.

Le réseau de diffusion de contenu mérite un mot, parce qu'il est souvent présenté comme la solution miracle. Il consiste à répliquer les fichiers statiques — images, feuilles de style, scripts, polices — sur des serveurs répartis géographiquement, afin que chaque visiteur les reçoive depuis un point proche. C'est très efficace pour une audience nationale ou internationale, et cela apporte en prime une protection contre les pics de charge. Pour une entreprise dont la clientèle se concentre sur le bassin douaisien et le département du Nord, le gain est plus modeste, puisqu'un bon hébergement français place déjà les fichiers à quelques millisecondes des visiteurs. Nous le recommandons donc quand il apporte une réponse à un besoin identifié — trafic dispersé, pics saisonniers, boutique en ligne exposée — et non comme un réflexe. C'est typiquement le genre d'arbitrage que nous documentons dans un audit technique et sémantique, chiffres à l'appui, plutôt que de le trancher par principe.

L'accessibilité souffre d'une réputation qui lui nuit : celle d'une contrainte réglementaire imposée au bénéfice d'une petite minorité, coûteuse et sans effet commercial. Cette représentation est fausse sur les trois points. Elle concerne d'abord une part de la population bien plus large qu'on ne l'imagine, dès lors qu'on cesse de penser au seul handicap permanent : une personne âgée dont la vue baisse, un utilisateur en plein soleil sur un chantier à Cuincy, quelqu'un qui consulte votre site d'une seule main en portant un carton, une personne temporairement immobilisée du poignet, un visiteur dont l'écran est fissuré. Toutes ces situations produisent les mêmes besoins qu'un handicap déclaré : des cibles plus grandes, des contrastes plus francs, un texte redimensionnable, une navigation prévisible. Concevoir pour les cas difficiles améliore mécaniquement l'expérience de tous les autres.

Le recoupement avec la performance est plus profond qu'une coïncidence heureuse, et il tient à une raison structurelle : les deux disciplines exigent la même chose, à savoir un document HTML propre et sémantiquement correct. Une page dont les titres sont de vrais titres hiérarchisés, dont les boutons sont de vrais boutons et non des blocs rendus cliquables par script, dont les images portent une description textuelle, dont les champs de formulaire sont associés à leur libellé, dont l'ordre du code correspond à l'ordre de lecture — cette page est simultanément plus accessible, plus légère, plus rapide à interpréter par le navigateur et plus facile à comprendre pour un moteur de recherche. À l'inverse, une page construite en empilant des blocs génériques dont le comportement est ajouté par des couches de script cumule tous les défauts à la fois : elle est lourde, lente, opaque aux technologies d'assistance et pauvre en signaux pour Google.

Ce qui se règle sans budget particulier

Une bonne part du travail d'accessibilité n'ajoute strictement rien au coût d'un projet, à condition d'être décidée au départ plutôt que constatée à l'arrivée. Utiliser les éléments natifs plutôt que de les reconstruire ne coûte rien et apporte gratuitement la navigation au clavier, la compatibilité avec les lecteurs d'écran et le comportement attendu sur chaque système. Vérifier les contrastes au moment de choisir la palette ne coûte rien, alors que les corriger après avoir décliné l'identité visuelle sur quarante pages coûte cher. Décrire les images au fil de la rédaction ne coûte rien, tandis que reprendre trois cents visuels a posteriori est un chantier à part entière. Prévoir un indicateur de focus visible pour la navigation au clavier ne coûte rien, et beaucoup de thèmes le suppriment activement parce qu'un designer a trouvé le contour disgracieux — c'est probablement la régression la plus fréquente et la plus facile à éviter.

Il faut ajouter les cas particuliers du mobile, moins connus. La possibilité de zoomer, déjà évoquée, est un point d'accessibilité avant d'être un point de confort. L'orientation : un site qui impose le mode portrait pénalise les personnes dont le téléphone est fixé sur un support en paysage, notamment en fauteuil. Les gestes complexes — glisser pour supprimer, pincer pour agrandir, appui long — doivent toujours avoir une alternative accessible d'un simple toucher. Les vidéos et animations en lecture automatique, enfin, posent un problème pour les personnes sensibles au mouvement et consomment de la bande passante à l'insu du visiteur ; le respect de la préférence système de réduction des animations règle le premier point et une lecture déclenchée par l'utilisateur règle le second.

La plupart des devis de création de site comportent la mention « site responsive » et rien d'autre sur le sujet. Cette mention n'engage à rien, puisqu'elle décrit une technique universellement employée et non un niveau de qualité. Ce qu'il faut obtenir, à la place ou en complément, ce sont des engagements formulés en critères vérifiables, écrits dans le devis ou dans le cahier des charges annexé. Un prestataire sérieux n'a aucune difficulté à les accepter, parce qu'ils correspondent à ce qu'il fait déjà. Un prestataire qui les refuse, les minimise ou explique qu'ils ne sont « pas réalistes » vous renseigne utilement, et gratuitement, avant que vous n'ayez signé. La discussion sur ces critères est d'ailleurs l'un des meilleurs révélateurs du sérieux technique d'une agence, bien plus que son portfolio, dont les visuels ne disent rien de ce qui se passe sous le capot.

Les clauses qui valent la peine d'être écrites

Nous conseillons d'inscrire noir sur blanc une demi-douzaine de points. Des seuils de terrain sur les trois indicateurs d'expérience, mesurés après mise en ligne sur les modèles de pages principaux, avec un délai de correction si les seuils ne sont pas atteints. Une taille de cible tactile minimale et un contraste conforme aux critères d'accessibilité de niveau AA sur l'ensemble des textes et des composants d'interface. La livraison des images en formats modernes avec variantes dimensionnées, dimensions déclarées et chargement différé correctement appliqué. Un inventaire écrit des scripts tiers présents, avec pour chacun sa justification et son mode de chargement. Une recette effectuée sur au moins un appareil réel de milieu de gamme, en données mobiles, et non sur un simulateur. Et la propriété pleine et entière du code, des accès d'hébergement, du nom de domaine et des comptes de mesure — point qui n'a rien à voir avec la performance mais qui décide de votre liberté de faire corriger par un autre ce qui ne le serait pas.

La recette est le moment où ces engagements se vérifient, et elle doit être organisée comme telle plutôt que subie comme une formalité. Concrètement, cela signifie disposer d'une liste de contrôle établie à l'avance, la parcourir point par point sur l'environnement de préproduction puis à nouveau après mise en ligne, et consigner les écarts par écrit. Vérifiez que chaque modèle de page est passé au crible, pas seulement la page d'accueil : c'est très souvent la page de service ou la fiche produit qui pose problème, parce qu'elle a été construite après la maquette validée. Vérifiez le formulaire de bout en bout, en envoyant réellement une demande et en constatant qu'elle arrive dans la bonne boîte, avec toutes les informations et un objet exploitable. Vérifiez le comportement avec le bandeau de consentement dans ses deux états, accepté et refusé, car beaucoup de sites ne sont mesurés et testés que dans un seul.

Un mot sur la période qui suit la mise en ligne, parce que c'est là que la performance se perd le plus souvent. Un site livré rapide ne le reste pas tout seul. Chaque nouvelle page publiée peut introduire une image non préparée, chaque extension installée ajoute son poids, chaque campagne publicitaire dépose son script de suivi, chaque évolution de la charte graphique alourdit un peu. Nous recommandons donc un point de contrôle trimestriel, court, portant sur trois éléments seulement : le poids et le temps de la page d'accueil et de deux pages stratégiques, l'évolution des indicateurs de terrain dans la Search Console, et la liste des scripts tiers actifs comparée à celle de la livraison. Un quart d'heure par trimestre suffit à repérer les dérives pendant qu'elles sont faciles à corriger, et cela s'intègre naturellement à un contrat de maintenance ou à un accompagnement en conseil en référencement.