Le tree shaking et la taille des bundles, dans les règles de l'art

Points clés

• Tree shaking : élimination du code mort basée sur les imports et exports statiques des modules ES
• Prérequis : du code écrit en modules ES avec des imports sans effets de bord
• Mesure la plus utile : Importer uniquement les fonctions que vous utilisez.
• Erreur la plus courante : Importer des bibliothèques utilitaires entières pour une seule fonction.
• Faites appel à de l'aide si l'une des situations décrites sous « Quand faire appel à de l'aide » ci-dessous correspond à votre projet.

Pourquoi c'est important

Le JavaScript est la ressource la plus coûteuse par octet, car il doit être téléchargé, analysé et exécuté, et le code de bibliothèque inutilisé est courant dans les bundles modernes.

Les chiffres, au même endroit

Voici les chiffres que les normes et la documentation des plateformes spécifient réellement.

À quoi ressemble un bon résultat

Voici les pratiques les mieux étayées. Commencez par celle qui coûte le moins cher à mettre en place.

• Importer uniquement les fonctions que vous utilisez
• Analyser les bundles avec un outil de visualisation
• Déclarer les paquets sans effets de bord lorsque c'est exact
• Remplacer les bibliothèques lourdes par des alternatives plus légères
• Définir un budget JavaScript par type de page

Ce qu'il faut éviter

Ces erreurs reviennent sans cesse, et plusieurs d'entre elles semblent de bonnes décisions sur le moment.

• Importer des bibliothèques utilitaires entières pour une seule fonction
• Des dépendances CommonJS qui bloquent le tree shaking
• Livrer des polyfills à des navigateurs qui n'en ont pas besoin
• Ignorer la croissance des bundles d'une version à l'autre

Où cela se situe dans Performance et accessibilité

Le tree shaking et la taille des bundles font partie de notre approche des projets Performance & Accessibilité. Le sujet arrive rarement seul : les décisions ci-dessus interagissent avec tout le reste du projet, c'est pourquoi mieux vaut les trancher tôt plutôt qu'au moment de la recette.

À qui cela s'adresse vraiment

Personne ne se documente sur le tree shaking et la taille des bundles par plaisir. Vous êtes ici parce que cela s'apprête à vous coûter du temps ou de l'argent, et vous préférez le découvrir maintenant plutôt qu'à l'échéance.

Chacune de ces situations est une bonne raison d'être ici. La suite couvre l'ensemble : en quoi consiste le travail, ce qu'il coûte aux États-Unis, combien de temps il prend, ce dont nous avons besoin de votre part et comment savoir si ce que vous recevez est de bonne qualité. Allez directement à la partie qui vous intéresse.

Quand l'occasionnel devient permanent

Il y a généralement un moment où la performance et l'accessibilité cessent d'être un sujet que l'on traite entre deux autres pour devenir un véritable chantier. Cela ressemble souvent à ceci :

• Le travail retombe sur quelqu'un dont le vrai métier est tout autre, et ce vrai métier en pâtit.
• Le volume n'est plus occasionnel, il est devenu hebdomadaire.
• La qualité varie selon la personne qui était disponible ce jour-là.
• Vous refusez des opportunités parce que la production ne suit pas.
• On refait sans cesse la même correction parce que personne n'a noté comment bien la faire.
• Vous payez des licences logicielles utilisées quelques jours par mois.

Si deux ou trois de ces points sont vrais, la question n'est pas vraiment de savoir s'il faut se faire aider. C'est de savoir s'il faut recruter, faire appel à un freelance ou travailler avec un studio, et une section plus bas présente honnêtement les avantages et inconvénients, y compris les cas où faire appel à nous est la mauvaise réponse.

Comment le travail se déroule concrètement

Voici la séquence que suit réellement un projet de performance et d'accessibilité. Ce n'est pas un schéma marketing : c'est l'ordre dans lequel les choses doivent se faire, et la plupart des problèmes coûteux dans ce domaine viennent d'une étape réalisée dans le désordre ou carrément sautée.

1. Mesurer la réalité

D'abord les données terrain (ce que de vrais visiteurs sur de vrais appareils ont réellement vécu), puis les tests en laboratoire pour l'expliquer. Un score de laboratoire sur un ordinateur portable rapide est une hypothèse, pas une mesure.

2. Auditer l'accessibilité

Les tests automatisés détectent peut-être un tiers des problèmes. Le reste exige un clavier, un lecteur d'écran et une personne. Les deux passes, dans cet ordre.

3. Prioriser

Des constats classés selon le nombre de personnes concernées et la difficulté de correction. L'indice de gravité d'un outil d'audit n'est pas une liste de priorités.

4. Corriger d'abord les gros problèmes

Images, polices et scripts tiers sont généralement le trio de tête pour la vitesse. États de focus, libellés et titres sont généralement le trio de tête pour l'accessibilité.

5. Corriger les problèmes structurels

Balisage sémantique, hiérarchie des titres, régions de repère, gestion du focus. C'est plus lent, et c'est ce qui rend réellement un site utilisable plutôt que simplement conforme.

6. Vérifier avec des personnes

Des tests de technologies d'assistance avec quelqu'un qui les utilise au quotidien. Rien d'autre ne vous dit si le site est vraiment utilisable.

7. Fixer des budgets

Des budgets de performance et des contrôles d'accessibilité dans le pipeline de build, pour que la prochaine version ne puisse pas défaire le travail en silence.

8. Documenter

Une déclaration d'accessibilité qui décrit honnêtement l'état actuel, les lacunes connues et la façon de signaler un problème.

Où s'inscrivent le tree shaking et la taille des bundles ? Généralement quelque part au milieu de ce processus, en héritant de chaque décision prise auparavant. C'est l'argument pour fixer le périmètre tôt : un changement à l'étape deux est une conversation, le même changement à l'étape sept est une reconstruction.

Les chiffres, et leur provenance

Ce sont des seuils publiés, pas nos opinions. Lorsqu'un organisme de normalisation ou une plateforme a indiqué un chiffre, ce chiffre figure ici et l'organisme est cité en bas de page. Lorsque personne n'en a publié, vous ne trouverez pas de chiffre inventé pour combler le vide.

Combien cela coûte aux États-Unis

Les prix d'abord, puisque c'est ce que vous êtes venu chercher. Voici les fourchettes du marché américain pour la performance et l'accessibilité. Votre chiffre se situera quelque part à l'intérieur, selon les facteurs indiqués ci-dessous.

Ce sont des fourchettes larges, et elles le sont pour une raison. Voici ce qui fait passer un projet d'un extrême à l'autre.

Ce qui détermine réellement le prix

Taille du site et nombre de templates

Corriger six templates corrige mille pages. Corriger mille pages construites à la main, non.

La gravité de la situation de départ

Un site construit de façon sémantique a besoin d'ajustements. Un site fait de divs imbriquées et de gestionnaires de clic a besoin d'être reconstruit.

Scripts tiers

Les parties les plus lentes de la plupart des sites appartiennent à quelqu'un d'autre. Les supprimer relève autant de la négociation commerciale que de la tâche technique.

Profondeur des tests d'accessibilité

Le scan automatisé coûte peu. Les tests manuels avec des technologies d'assistance et de vrais utilisateurs sont ce qui révèle l'essentiel.

Contraintes du framework

Certaines stacks rendent le balisage accessible plus difficile que d'autres, et contourner cela prend du temps.

La pérennité des corrections

Les budgets et les contrôles automatisés en CI coûtent un peu à mettre en place et évitent que tout le travail ne régresse.

Comment la rémunération est généralement structurée

Au-delà du montant se pose la question des modalités. Cinq modèles couvrent presque tous les cas dans ce secteur, et le bon dépend de la précision avec laquelle le travail peut être décrit avant de commencer.

À l'unité

Un prix fixe par image, par minute, par page, par élément. Idéal quand le travail est réellement répétitif et que vous pouvez décrire précisément une unité. C'est le modèle le plus simple à budgéter et le plus facile à contester, car tout dépend de la correspondance entre votre définition d'une unité et la nôtre. Mettez-vous d'accord sur un échantillon avant de vous mettre d'accord sur une facture.

Taux horaire ou journalier

Vous achetez du temps, et le résultat est ce que ce temps produit. C'est honnête quand personne ne peut encore cadrer le travail : un sauvetage, des archives inconnues, une phase exploratoire. Demandez malgré tout un montant plafond. Un accord horaire ouvert sans plafond est un budget sans limite.

Forfait projet

Un montant unique pour un périmètre défini, généralement avec un nombre déterminé de cycles de révision. C'est le modèle que préfèrent la plupart des clients, et celui qui pénalise le plus durement un brief flou. Le forfait n'est fixe que si le périmètre l'est, alors attendez-vous à un document de cadrage plus précis que ce qui vous semble confortable. C'est cette précision qui vous protège.

Abonnement mensuel

Une capacité définie réservée pour vous chaque mois. Intéressant dès que le travail est continu plutôt qu'occasionnel : un catalogue qui se renouvelle, une chaîne qui publie chaque semaine, un site qui évolue sans cesse. En dessous d'environ dix à quinze heures par mois, cela revient généralement plus cher que d'acheter le travail au fil de l'eau.

Rémunération à la valeur ou au résultat

Une tarification liée à un résultat business plutôt qu'à l'effort. Rare, et rarement aussi simple qu'il y paraît. Elle fonctionne quand le résultat est sans ambiguïté et attribuable, et s'effondre quand il n'est ni l'un ni l'autre. Examinez une proposition de rémunération au résultat avec la même rigueur que toute autre affirmation en matière d'attribution.

Si vous voulez un vrai montant plutôt qu'une fourchette, le plus rapide est de nous envoyer le vrai brief : périmètre, volume, échéance, et quelques fichiers d'exemple si vous en avez. Cela suffit généralement pour un prix fixe plutôt qu'une estimation.

Combien de temps cela prend

La version honnête d'un calendrier. Les phases se chevauchent, et celle qui dérape est rarement celle pour laquelle on a prévu de la marge.

Une chose mérite d'être dite clairement : la cause la plus fréquente d'un projet en retard n'est pas la production. C'est l'attente : d'un contenu, d'une décision, d'une personne qui doit jeter un œil à quelque chose. Si vous voulez qu'un projet avance vite, le levier le plus puissant dont vous disposez est de désigner une personne habilitée à dire oui et de vous assurer qu'elle est disponible. Ce seul changement vaut plus que toutes les relances du monde.

Le travail en urgence est possible, et il coûte réellement plus cher, car il implique de vraies personnes qui font de vraies heures supplémentaires, ou un projet qui passe devant celui de quelqu'un d'autre. Nous vous dirons toujours ce que coûte réellement une urgence avant que vous vous engagiez.

Ce qu'il faut nous envoyer

Tout ce qui suit, vous seul le savez. Le consigner au même endroit dès le départ fait gagner plus de temps que tout ce que l'un ou l'autre pourra faire ensuite.

Ce que doit contenir le brief

À qui il s'adresse

Le public, en une phrase, avec vos propres mots. Pas un document de persona : une phrase.

Ce qu'il doit accomplir

L'action que vous voulez que quelqu'un réalise, ou la décision que vous voulez lui permettre de prendre.

Où il sera diffusé

Chaque emplacement, à chaque format. C'est l'oubli le plus fréquent, et c'est celui qui entraîne de nouvelles prises de vue et de nouveaux recadrages.

Ce qui existe déjà

Charte graphique, travaux antérieurs, les fichiers que personne n'aime. Surtout les fichiers que personne n'aime, et pourquoi.

Ce qui est figé

Couleurs, polices, mentions légales, exigences des plateformes, tout ce qui n'est pas négociable.

À quoi ressemble un bon résultat

Deux ou trois références, plus un exemple de quelque chose que vous n'aimez vraiment pas. Ce que vous n'aimez pas est plus utile que ce que vous aimez.

La vraie échéance

La date à laquelle quelque chose doit être en ligne, pas celle à laquelle vous aimeriez voir une ébauche. Précisez laquelle vous nous donnez.

Qui valide

Un seul nom. Un brief avec quatre validateurs et aucun décideur est un brief qui vous coûtera deux cycles de révision supplémentaires.

Deux d'entre eux méritent d'être soulignés, car ce sont ceux qui coûtent de l'argent quand ils manquent. Où il sera diffusé (chaque emplacement, à chaque format) est l'oubli qui entraîne de nouvelles prises de vue et de nouveaux recadrages. Et qui valide est celui qui ajoute discrètement des cycles de révision : un projet avec quatre validateurs et aucun décideur coûtera toujours plus cher qu'un projet avec un seul nom.

Spécifique au tree shaking et à la taille des bundles

En plus du brief général, ce type de projet gagne à ce que vous ayez tranché les points suivants avant que quiconque ne commence :

• Importer uniquement les fonctions que vous utilisez
• Analyser les bundles avec un outil de visualisation
• Déclarer les paquets sans effets de bord lorsque c'est exact
• Remplacer les bibliothèques lourdes par des alternatives plus légères

Si vos fichiers sont déjà prêts, vous pouvez nous les envoyer directement : ils sont déposés sur un stockage privé plutôt que dans une boîte de réception, et rien n'est public. Si vous préférez juger de notre niveau avant de vous engager, testez-nous d'abord sur quelques fichiers. Sans carte bancaire, sans engagement, et si cela ne correspond pas à vos besoins, vous n'aurez perdu qu'un après-midi.

Comment vérifier ce que vous recevez

Cette section mérite d'être lue même si vous n'engagez jamais personne. Une mauvaise relecture coûte cher, quel que soit le prestataire.

Vérifiez-le là où il sera utilisé

Validez un visuel web dans un navigateur, un visuel imprimé sur papier, un mixage audio sur un haut-parleur de téléphone. Valider un livrable dans l'outil qui l'a produit, c'est ainsi que les problèmes arrivent jusqu'au public.

Vérifiez les bords, pas le centre

Le centre est presque toujours correct. Regardez les coins, le plus petit format, la chaîne de texte la plus longue, la zone la plus sombre, les dix dernières secondes.

Vérifiez une chose à la fois

La couleur, puis la typographie, puis les espacements, puis le contenu. Une relecture qui cherche à tout voir d'un coup voit ce qui saute le plus aux yeux et rate le reste.

Rassemblez les retours avant de les envoyer

Une seule liste consolidée vaut mieux que six e-mails. Les contradictions au sein de votre propre organisation se règlent à moindre coût de votre côté que du nôtre.

Soyez précis sur ce qui ne va pas

« Rendez-le plus percutant » coûte un cycle de révision. « Le titre est difficile à lire sur le ciel, pouvez-vous assombrir la zone derrière ? » coûte dix minutes.

Dites aussi ce qui va bien

Pas par politesse. Si vous ne signalez que les problèmes, le cycle suivant risque de faire disparaître ce que vous aimiez sans que personne ne sache que c'était important.

Le niveau d'exigence que nous nous imposons

Pour que vous sachiez à quoi vous comparer, voici ce qui est vérifié de notre côté avant que quoi que ce soit ne vous parvienne. Rien de tout cela n'est facultatif, et rien n'est facturé en supplément.

• Des Core Web Vitals évalués sur les données terrain de vrais utilisateurs, et non sur un score de laboratoire obtenu sur une machine rapide
• LCP inférieur à 2,5 secondes, INP inférieur à 200 millisecondes, CLS inférieur à 0,1, au 75e percentile
• Chaque élément interactif utilisable au clavier, avec un état de focus réellement visible
• Testé avec un vrai lecteur d'écran, par quelqu'un qui sait s'en servir
• Contraste vérifié à 4,5:1 pour le texte courant et à 3:1 pour le texte de grande taille et les composants d'interface
• Une déclaration d'accessibilité qui indique ce qui n'est pas encore corrigé, plutôt que de prétendre que tout l'est

Signaux d'alerte propres au tree shaking et à la taille des bundles

Si vous repérez l'un de ces points dans ce qui vous est livré, signalez-le. Tous peuvent être corrigés, et tous coûtent moins cher à corriger maintenant qu'après la mise en ligne.

• Importer des bibliothèques utilitaires entières pour une seule fonction
• Des dépendances CommonJS qui bloquent le tree shaking
• Livrer des polyfills à des navigateurs qui n'en ont pas besoin
• Ignorer la croissance des bundles d'une version à l'autre

Vous pouvez voir comment nous présentons nos travaux finalisés, avant/après compris, dans le portfolio. Tout ce qui est marqué comme exemple est une réalisation de démonstration de notre part et non un projet client, et c'est indiqué sur l'élément.

Trois situations que vous reconnaîtrez peut-être

Un conseil abstrait est facile à approuver et difficile à appliquer. Voici les formes que prend concrètement ce type de problème, et ce que nous ferions dans chaque cas.

Un site qui obtenait 98 en laboratoire et paraissait lent

Le test de laboratoire tournait sur une connexion rapide avec un cache chaud. Les données terrain montraient que de vrais utilisateurs atteignaient huit secondes à cause de deux tags tiers et d'une image d'en-tête non compressée. Aucun des deux n'apparaissait dans le score que tout le monde communiquait.

Un overlay d'accessibilité qui a aggravé les choses

Un widget promettant la conformité en une ligne a été ajouté au lieu de corriger le balisage. Il a cassé la navigation au clavier sans traiter les problèmes de fond. Le retirer et corriger le balisage a pris plus de temps, et a réellement fonctionné.

Des états de focus supprimés pour des raisons esthétiques

Un reset CSS avait supprimé tous les contours de focus. Pour les utilisateurs du clavier, le site était devenu un labyrinthe invisible. Rétablir un état de focus visible et soigné a pris un après-midi.

Aucun de ces cas n'exigeait d'exploit. Il fallait simplement que quelqu'un regarde le bon point suffisamment tôt, ce qui est l'essentiel de ce que l'expérience apporte dans ce domaine.

En interne, freelance, studio ou modèle d'IA ?

C'est la décision qui se cache derrière « combien ça coûte », et elle mérite une réponse franche plutôt qu'un argumentaire. Il existe quatre façons de faire réaliser un travail de performance & accessibilité, et nous ne sommes le bon choix que pour certaines d'entre elles.

Garder le travail en interne

Un membre de votre personnel s'en charge.

Les avantages : la boucle de retour la plus rapide qui soit, la connaissance produit la plus approfondie, aucun effort de briefing pour les petites modifications.

Les inconvénients : vous achetez une personne, pas un travail : ses congés, ses arrêts maladie, ses limites, et les logiciels. Cela cesse d'avoir du sens dès que la demande est irrégulière, car vous payez le pic toute l'année.

Engager un freelance

Un spécialiste, engagé directement.

Les avantages : le moyen le moins cher d'acheter une vraie expertise, et vous traitez directement avec la personne qui fait le travail.

Les inconvénients : une seule personne, c'est un point de défaillance unique. Pas de remplaçant, une capacité limitée, et si elle part en cours de projet, vous héritez de ses fichiers et de ses conventions.

Faire appel à un studio

Une équipe avec un process, un niveau de relecture et des remplaçants.

Les avantages : absorbe le volume et la diversité, prend en charge le contrôle qualité, et ne disparaît pas quand une personne est malade.

Les inconvénients : plus cher à l'heure qu'un freelance, et vous êtes un client parmi d'autres. Intéressant quand la cohérence sur un grand volume de production compte davantage que le tarif le plus bas.

Utiliser un modèle d'IA

Des outils génératifs ou automatisés, avec ou sans vérification humaine.

Les avantages : réellement rapide et réellement bon marché sur ce qu'il fait bien, et il ne se fatigue pas à la page quatre cents.

Les inconvénients : il se trompe avec aplomb, d'une manière difficile à repérer au premier coup d'œil, et ses points faibles sont justement ceux qu'un client remarque : les mains, le texte, les dénombrements, les contours, la continuité. Rien ne devrait être livré sans avoir été vu par une personne, c'est pourquoi nos prestations IA sont tarifées relecture comprise plutôt que présentées comme une remise.

En bref : si le travail est constant et au cœur de votre activité, recrutez. S'il est irrégulier, ou s'il requiert un éventail de compétences que vous ne pouvez pas justifier d'employer, faites appel à un studio. S'il s'agit d'une spécialité précise et que vous avez trouvé le bon spécialiste, faites appel à lui. Nous préférons vous le dire d'emblée plutôt que d'accepter un projet pour lequel nous ne sommes pas adaptés.

Les règles américaines à connaître

Ceci n'est pas un avis juridique et nous ne sommes pas avocats. C'est une liste des règles américaines qui reviennent assez souvent dans ce type de travail pour que les ignorer coûte cher. Si l'une d'elles vous concerne, cela vaut vingt minutes avec quelqu'un qui est avocat.

Titre III de l'ADA

Les tribunaux américains ont largement appliqué le titre III de l'Americans with Disabilities Act aux sites web commerciaux, et les poursuites et mises en demeure en matière d'accessibilité web sont courantes. Les WCAG 2.1 AA sont la référence de fait utilisée dans les transactions et les décisions par consentement.

Section 508

Les agences fédérales et les organisations qui leur vendent doivent respecter la Section 508, qui adopte les WCAG comme norme technique. Si vous vendez au gouvernement fédéral, un rapport de conformité en matière d'accessibilité fait partie de la procédure d'achat, et n'est pas ajouté après coup.

Règles étatiques et sectorielles

Plusieurs États ont leurs propres exigences d'accessibilité pour les entités publiques, et des secteurs comme l'éducation, la santé et la finance sont soumis à des obligations supplémentaires. Le dénominateur commun à toutes reste les WCAG 2.1 AA.

Et les questions commerciales générales

Quelle que soit la discipline, l'achat de services professionnels aux États-Unis soulève toujours la même poignée de questions. Voici celles que nos clients nous posent le plus.

Contrats et descriptifs de prestations (SOW)

Un statement of work (cahier des charges contractuel) qui précise les livrables, le nombre de cycles de révision, les conditions de propriété et l'échéancier de paiement vaut bien l'heure nécessaire pour le lire. La plupart des litiges dans ce secteur ne portent pas sur la qualité : ils viennent de deux personnes qui ont compris « terminé » différemment.

Propriété et work made for hire

En vertu du droit d'auteur américain, une œuvre créée par un prestataire indépendant appartient en général au prestataire, sauf cession écrite ou si elle relève de l'une des catégories légales restreintes de « work made for hire ». Cela surprend beaucoup d'acheteurs. Obtenez la cession par écrit ; un studio qui hésite vous apprend quelque chose d'utile.

Payer un prestataire externe

Une entreprise américaine qui rémunère un prestataire américain recueille normalement un Form W-9 et peut devoir déposer un 1099-NEC ; pour un prestataire non américain, il s'agit généralement plutôt d'un W-8BEN ou d'un W-8BEN-E. Votre comptable voudra ces documents avant la première facture, pas après la dernière.

Taxe de vente sur les services

Le caractère imposable d'un service créatif ou numérique varie selon les États, et plusieurs États taxent certains livrables numériques mais pas d'autres. Mieux vaut poser une question à votre comptable avant une mission importante que recevoir un courrier de l'administration fiscale d'un État après.

Allégations publicitaires

La Federal Trade Commission tient les annonceurs pour responsables des allégations faites dans leur marketing, y compris celles véhiculées par les images. Une photo produit retouchée qui ne représente plus le produit est un problème publicitaire avant d'être un problème de design, et la responsabilité incombe à l'annonceur plutôt qu'au retoucheur.

Accessibilité

Le titre III de l'Americans with Disabilities Act a été interprété par les tribunaux américains comme s'appliquant aux sites web dans de nombreux cas, et les agences fédérales ainsi que leurs sous-traitants sont tenus par la Section 508, qui renvoie aux WCAG. L'accessibilité coûte moins cher quand elle est intégrée dès la conception que quand elle est réglée devant les tribunaux.

Nos propres conditions sont publiées plutôt qu'envoyées sur demande : vous pouvez lire les conditions générales, les conditions de paiement, la politique de remboursement et notre position en matière de confidentialité et de NDA avant même de parler à qui que ce soit. Si quelque chose ne vous convient pas, dites-le tôt : la plupart des points sont négociables, et tout se règle mieux avant le travail qu'après.

Les questions à poser à tout prestataire qui vous fait un devis

Nous compris. Si un prestataire se montre évasif sur l'une d'entre elles, c'est la réponse à la question que vous vous posiez vraiment.

Qui fait réellement le travail ?

Demandez si le travail reste entre les mains de votre interlocuteur, passe à une équipe ou est sous-traité. Aucune de ces options n'est mauvaise. Ne pas le savoir, si.

Qu'est-ce qu'une révision, exactement ?

Demandez ce qui compte comme une révision par rapport à un nouveau brief, et combien sont incluses. C'est la source la plus fréquente d'une facture inattendue.

À qui appartient le résultat ?

Faites-le mettre par écrit, fichiers de travail compris. « Le fichier final vous appartient » et « tout vous appartient » sont deux positions très différentes, et la seconde coûte plus cher pour une bonne raison.

Que se passe-t-il en cas d'erreur ?

Demandez combien coûte une reprise et dans quel délai elle est faite. Un studio qui a une réponse claire a déjà eu cette conversation.

Puis-je voir des travaux similaires aux miens ?

Pas une bande démo : des travaux dans votre catégorie, à votre volume, avec vos contraintes. Un superbe portfolio dans une autre catégorie prouve le goût, pas l'adéquation.

Comment traitez-vous mes fichiers ?

Où ils sont stockés, qui peut y accéder, combien de temps ils sont conservés et ce qu'il advient à la fin. Si vous envoyez quoi que ce soit de non publié, faites-le inscrire au contrat.

De quoi avez-vous besoin de ma part ?

Un prestataire incapable de répondre à cette question n'a pas réfléchi à votre côté du projet, et vous le découvrirez à l'échéance.

Une dernière, et c'est celle que l'on ose le moins poser : qu'est-ce qui vous ferait refuser ce projet ? Un studio qui n'a jamais refusé de travail est un studio qui accepte tout, et cela en dit long sur le soin avec lequel le vôtre sera traité.

Le jargon qu'on vous servira

Chaque domaine a un vocabulaire qui sert de raccourci et finit par faire obstacle. Voici ce que signifient réellement, en termes simples, les termes courants en performance & accessibilité. Vous ne devriez pas en avoir besoin pour acheter la prestation, mais cela raccourcit la conversation.

Données terrain

Ce que de vrais visiteurs ont vécu, recueilli à partir de sessions réelles. La mesure qui compte.

Données de laboratoire

Un test synthétique dans des conditions contrôlées. Utile pour le diagnostic, trompeur comme verdict.

75e percentile

Le seuil utilisé par Google pour les Core Web Vitals : trois visites sur quatre doivent atteindre l'objectif, de sorte que le quart le plus lent ne peut pas être ignoré.

WCAG 2.1 AA

La norme d'accessibilité à laquelle renvoient la plupart des réglementations, et l'objectif pratique de presque tous les sites commerciaux.

Lecteur d'écran

Un logiciel qui lit une interface à voix haute. C'est ce qui donne au balisage sémantique une importance que rien d'autre ne lui confère.

État de focus

L'indication visible de l'élément sur lequel se trouve le clavier. Le supprimer pour des raisons esthétiques rend un site inutilisable au clavier.

Repère (landmark)

Des régions structurelles (en-tête, navigation, contenu principal, pied de page) qui permettent aux technologies d'assistance de naviguer rapidement dans une page.

Texte alternatif

Une alternative textuelle à une image. Elle décrit la fonction, pas l'apparence, et reste vide pour les images purement décoratives.

Ressources bloquant le rendu

Des ressources qui doivent se charger avant que quoi que ce soit n'apparaisse. Généralement les polices et les feuilles de style, généralement corrigeable.

Budget de performance

Un plafond convenu de taille ou de temps, appliqué dans le build pour que les régressions fassent échouer le pipeline plutôt que l'utilisateur.

Une bibliothèque de référence plus complète est disponible si vous souhaitez approfondir l'un de ces sujets, et tout y est rédigé de la même manière : simplement, avec les sources.

Les questions posées avant de faire appel à nous

Voici les questions qui reviennent dans presque toutes les demandes concernant le tree shaking et la taille des bundles, avec des réponses directes. Si la vôtre n'y figure pas, posez-la — personne ne vous inscrira à une liste de diffusion pour autant.

Combien cela coûte-t-il ?

Aux États-Unis, les tarifs du marché pour rendre un site rapide sur des téléphones ordinaires et utilisable par des personnes qui ne naviguent pas comme vous commencent autour de 2 500 $ – 10 000 $ pour les travaux les plus simples, puis augmentent avec la complexité, le volume et les délais. Nous établissons un prix par projet une fois le cahier des charges examiné, car un chiffre annoncé sans avoir vu les fichiers est un chiffre qui change ensuite.

Pouvez-vous me proposer un prix forfaitaire ?

En général, oui, une fois le périmètre mis par écrit. Un prix forfaitaire exige un périmètre fixe : attendez-vous donc à un document de cadrage plus précis que ce qui vous semble nécessaire. C'est cette précision qui vous protège d'une facture d'avenant.

Dans quels délais pouvez-vous commencer ?

La mesure et l’audit prennent normalement 2 à 4 semaines. Le délai avant le démarrage dépend de la file d’attente, et nous vous donnerons la date réelle plutôt que celle que vous aimeriez entendre.

De quoi avez-vous besoin de ma part pour commencer ?

Un brief, les fichiers et le nom de la seule personne habilitée à valider. Ce troisième point compte plus qu'on ne le pense : les projets avec un décideur unique se terminent nettement plus vite que ceux pilotés par un comité.

À qui appartient le travail final ?

À vous, fichiers de travail compris, et c'est inscrit dans les conditions plutôt que laissé à l'appréciation de chacun. Selon le droit d'auteur américain, le travail d'un prestataire externe n'est pas cédé automatiquement sans cession écrite : c'est donc un point à vérifier avec tout prestataire.

Et si le résultat ne me plaît pas ?

Dites-nous précisément ce qui ne va pas et nous le corrigerons. Le nombre de cycles de révision est indiqué dans le devis, pour que personne n'ait à deviner. Si le niveau de qualité ne correspond vraiment pas à vos besoins, la politique de remboursement précise ce qui se passe, par écrit, avant que vous ne dépensiez quoi que ce soit.

Travaillez-vous avec des clients américains ?

Oui, et nos horaires recouvrent la journée de travail américaine. Les prix sont en dollars US et les livrables sont spécifiés selon les normes américaines applicables (ATSC, l'ADA et la Section 508, les règles publicitaires de la FTC, les exigences des marketplaces américaines) plutôt que selon les équivalents européens que de nombreux studios appliquent par défaut.

Puis-je faire un essai avant de m'engager ?

Oui. Envoyez-nous quelques fichiers réels et nous réaliserons le travail selon votre brief, gratuitement, sans carte bancaire et sans engagement. C'est un meilleur test que n'importe quel portfolio, car il s'agit de vos contenus et de vos exigences.

Mes contenus restent-ils confidentiels ?

Oui. Les fichiers sont déposés sur un stockage privé plutôt que dans une boîte de réception, rien n'est publié sans votre accord, et nous signerons votre NDA ou utiliserons le nôtre, selon votre préférence.

Quelle est la cause la plus fréquente de retard sur ce type de projet ?

L'attente d'une décision. Pas la production, pas les révisions : l'attente. Si vous ne retenez qu'une chose de cette page, retenez celle-là.

Pour aller plus loin

• Compression de texte avec Brotli et Gzip : ce qui fonctionne vraiment
• CSS critique : les décisions qui comptent

Quand faire appel à de l'aide

Faites appel à un spécialiste lorsque les bundles JavaScript sont volumineux, lorsque les builds ont grossi au fil du temps ou lorsque la performance mobile est à la traîne.

Nos sources

• MDN Web Docs — Tree shaking
• web.dev — Reduce JavaScript payloads with tree shaking

Comment cette page a été élaborée

Chaque chiffre, pratique et avertissement ci-dessus est tiré des normes, de la documentation des plateformes et des recherches publiées citées dans la section Nos sources. Rien ici n'est déduit ni généralisé au-delà de ce que publient ces organismes : lorsqu'ils donnent un chiffre, c'est leur chiffre, et lorsqu'ils se taisent, nous aussi. Les pages sont régénérées dès que les sources sous-jacentes changent. Nos propres opinions, lorsque nous en avons, figurent dans les études de cas et sont signées.

Vous travaillez sur un projet similaire ?

Nous prenons en charge des projets de performance & accessibilité pour les équipes qui veulent que le travail soit fait une fois, et bien fait. Dites-nous ce que vous construisez et nous vous dirons honnêtement si nous sommes le bon studio pour vous. Démarrer un projet.

Autres pistes utiles

Suivez ces liens pour poursuivre avec le sujet pratique, le service ou le guide de décision le plus proche.

• Bibliothèque d’articles Performance & Accessibilité
• Guide pratique : la taille excessive du DOM
• Tree testing : ce qui fonctionne vraiment
• Performance de chargement des vidéos : les décisions qui comptent
• WCAG 3 et la suite, dans les règles de l’art
• Audit d'accessibilité (WCAG 2.2 AA) vs réduction du bundle JavaScript