Ce qui se passe entre la décision et la publication : les étapes de la création d’un site web

Le contrat est signé, l’acompte est versé, et alors s’installe le silence. L’entreprise attend que le site web apparaisse, le développeur attend les textes et les photographies, et aucun des deux ne pense attendre exactement la même semaine, si bien qu’un mois plus tard les deux parties sont mécontentes, et aucune n’a rien fait de travers ; simplement, personne n’avait consigné qui livre quoi, et pour quelle date.

Cet article porte sur ce qui se passe entre la décision et la publication, et surtout sur le partage du travail entre les deux parties, parce que c’est lui qui tranche le délai bien plus souvent que la vitesse du développement ou la technologie choisie. Nous avons déjà traité à part, dans l’article sur les dix erreurs à éviter lors de la création d’un site web, les erreurs des commanditaires, et nous ne les répétons pas ici. Il n’y a pas non plus de prix, ni de comparaison entre le faire soi-même et le faire commander, parce que les deux sont le sujet d’autres articles : il n’est question ici que de la séquence, et de ce qu’il faut préparer à chaque étape.

Le cadrage n’est pas le début de la construction

Presque tout processus de développement commence par une phase appelée cadrage ou analyse, et c’est précisément cette phase que l’on comprend le plus souvent de travers, parce que le commanditaire la traite comme une formalité avant le vrai travail. Nielsen Norman Group, qui emploie ce concept à titre professionnel, le définit comme une phase préparatoire où l’on étudie le problème lui-même et son contexte, où l’on formule ce qui est soluble et où l’on rassemble assez de preuves pour savoir quoi faire ensuite, et souligne précisément que, pendant le cadrage, on ne vérifie pas de solutions.

Dans le secteur public, cette idée est formalisée plus strictement encore, parce que le Service Manual du GDS, le service numérique du gouvernement britannique, distingue cinq phases, à savoir discovery, alpha, beta, live et retirement, et de la discovery il est écrit simplement : à ce stade, on ne commence pas à construire le service. À la fin de la phase, l’équipe décide d’avancer ou de s’arrêter, et le manuel lui-même n’impose pas de durée déterminée, même s’il indique qu’en pratique cette phase dure d’ordinaire de quatre à huit semaines.

Il faut ici poser d’emblée une réserve, sans quoi naît une image fausse : ce manuel décrit le cycle de vie d’un service numérique de l’État, non le site d’entreprise de dix pages, et en transposer les délais à un projet de réalisation ordinaire serait trompeur. Ce qui vaut, c’est le principe, non le calendrier : avant la construction, il y a une phase dont le but est de comprendre la tâche, et le résultat de cette phase peut aussi être la décision de ne pas construire du tout.

Dans un projet concret, cette phase prend d’ordinaire la forme d’une conversation sur les processus, les rôles des utilisateurs et le périmètre, et le résultat est un plan écrit, non un croquis de design, même si le commanditaire voudrait souvent voir précisément le second. Pour le commanditaire, il en résulte deux conséquences directes, et la première est que, sans un résultat écrit du cadrage, il n’y a plus tard simplement rien à quoi comparer ce qui a été construit, si bien qu’un litige sur le périmètre reste sans preuve pour les deux parties. La seconde est que, précisément à cette phase, changer d’avis est bon marché, alors qu’après le début de la construction chaque modification coûte aussi ce qui a déjà été construit et qu’il faudra refaire.

Le prototype est l’endroit le moins cher pour changer d’avis

Entre le plan et la construction, il y a une phase que les commanditaires tiennent parfois pour une dépense superflue, et c’est précisément la phase qui, le plus souvent, économise de l’argent. Le prototype est une version cliquable du site, sans le vrai code, dans laquelle on peut parcourir les chemins principaux et voir où il manque quelque chose, et son seul but est de permettre de changer d’avis tant que changer d’avis est encore bon marché.

Le manuel du gouvernement britannique le dit sans ménagement, en écrivant de la phase alpha qu’il faut s’attendre à jeter, à la fin de la phase, tout le code écrit à cette phase et une grande part des idées éprouvées, et cela ne contredit pas un bon travail, c’en est le sens : jeter un prototype est bon marché, jeter un système déjà construit ne l’est pas. À l’échelle d’un site d’entreprise, le même principe opère dans un plus petit volume, et c’est précisément pour cela que nous préparons le prototype avant la première ligne de code de production.

Pour le commanditaire, il en résulte une exigence pratique, qu’il vaut la peine de dire à voix haute : valider le prototype n’est pas cocher une case formelle, mais le seul moment où les modifications ne coûtent que du temps, donc c’est précisément à cet instant qu’il vaut la peine d’appeler à la table les personnes qui diront plus tard que personne ne leur a rien demandé. Après la validation du prototype, chaque conversation de ce type coûte déjà ce qui a été construit.

L’autre chose qui, à cette phase, en vaut la peine, c’est le contenu en brouillon, parce qu’un prototype avec du texte de remplissage se valide facilement, et l’on découvre ensuite que les vrais textes ne tiennent pas, ou qu’une section à laquelle on destinait un paragraphe en demande en réalité trois. Si les textes ne sont pas encore prêts, il vaut la peine de mettre dans le prototype au moins des brouillons d’une longueur à peu près juste, parce que la longueur change la mise en page plus que n’importe quelle couleur.

La plus grande part de l’attente se joue du côté du client

Le délai d’un projet, le plus souvent, n’est pas fixé par la vitesse du développement, mais par la rapidité avec laquelle le commanditaire livre le contenu, et dans notre expérience c’est la cause de retard la plus fréquente. Il n’existe pas, dans le métier, d’étude indépendante sur ce point, avec une méthodologie et une date, donc nous le disons comme notre expérience et nous ne faisons pas semblant qu’il y ait des pourcentages derrière.

Il vaut ici de poser encore une réserve, sans quoi cette section sonnerait comme un rejet de la faute : dans le secteur public, la production de contenu est un métier distinct et un rôle d’équipe, et dans le manuel du gouvernement le concepteur de contenus figure parmi les compétences requises, mais il ne s’ensuit pas que, dans un projet de réalisation ordinaire, les textes soient écrits par le développeur. Qui les écrit est une question d’accord, et la seule mauvaise réponse est que personne ne l’ait clarifié avant le début des travaux.

Concrètement, du côté du commanditaire, il y a d’ordinaire cinq livraisons, et à chacune il vaut la peine d’assigner dès le contrat une date précise, plutôt que de la laisser au niveau de la conversation. La première, ce sont les textes, et c’est la plus lourde de toutes, parce qu’on ne les écrit pas en une soirée et que, d’ordinaire, c’est une personne pour qui écrire ne fait pas partie du travail principal, et qui doit les insérer entre ses autres devoirs. La deuxième, ce sont les photographies et les logos au format vectoriel, la troisième les accès aux systèmes existants, s’il faut en déplacer quelque chose, la quatrième les validations à des points déterminés du projet, et la cinquième, qui n’est pas un document mais une personne, un seul décideur qui, au nom de l’entreprise, a le droit de dire oui.

Cette cinquième est celle qui manque le plus souvent, et son absence coûte plus que n’importe quelle complication technique : un projet où la validation est donnée par un comité s’allonge non parce que quelqu’un travaille mal, mais parce que chaque validation demande une réunion, que les réunions ont lieu une fois toutes les deux semaines, et qu’entre les deux le travail est simplement à l’arrêt. S’il y a dans l’entreprise plusieurs parties prenantes, la bonne solution n’est pas d’essayer de les écarter, mais de convenir lequel d’entre eux est le décideur final et dans quel délai on attend une réponse.

En France, aucune norme n’assigne au chef de l’institution la responsabilité des contenus du site officiel. Pour une entreprise privée, cela n’est de toute façon pas contraignant, mais l’idée est la même et peut s’adopter volontairement : la responsabilité des contenus appartient au commanditaire, et elle doit être mise à la charge d’une personne concrète, nominativement.

Les images sont une question de droits, non une question de fichiers

Les photographies sont l’endroit où les commanditaires agissent avec les meilleures intentions et créent pourtant un risque, parce que l’on tient pour acquis que le fichier qui est sur l’ordinateur est aussi un fichier que l’on a le droit d’utiliser ; au sens du Code de la propriété intellectuelle, les œuvres photographiques sont des œuvres de l’esprit, le droit d’auteur naît du seul fait de la création, sans aucun enregistrement, et l’auteur est toujours la personne qui a pris l’image.

Il en résulte une conclusion qui surprend presque chaque entreprise : le paiement d’une séance photo ne signifie pas, à lui seul, que le commanditaire a acquis les droits patrimoniaux. Le photographe reste l’auteur, le droit moral, y compris le droit d’être nommé, est inaliénable, et les droits patrimoniaux ne passent que par une licence ou une cession : l’article L. 131-3 du code exige que chacun des droits cédés fasse l’objet d’une mention distincte et que le domaine d’exploitation soit délimité, et pour une entreprise qui prévoit d’utiliser les photographies sur le site, les réseaux sociaux et à l’impression, cela signifie que la licence ou la cession doit viser précisément ces modes d’exploitation.

Avec les banques d’images, c’est exactement la même chose, seulement là les conditions sont écrites clairement et publiquement, donc on peut les lire avant d’acheter : la licence Standard de Shutterstock donne un droit non exclusif et non transférable d’utiliser l’image, y compris sur des sites web, et sur la même page il est indiqué que le client n’acquiert ni la propriété ni des droits exclusifs. Il y a là aussi des limites que l’on finit par enfreindre par accident : l’image ne peut pas être transmise à autrui, ne peut pas servir de logo ou de marque, et les images marquées pour un usage éditorial uniquement ne peuvent pas servir à des fins commerciales. Une entreprise qui a acheté une licence Standard a obtenu le droit d’utiliser l’image sur le site, non un fichier à remettre au développeur comme un bien à soi.

Il y a encore un cas que l’on comprend presque toujours de travers. Le Code de la propriété intellectuelle prévoit une exception pour les reproductions et représentations d’œuvres architecturales et de sculptures placées en permanence sur la voie publique, mais seulement lorsqu’elles sont réalisées par des personnes physiques, à l’exclusion de tout usage à caractère commercial. Un site web d’entreprise est un usage commercial, donc cette exception ne le couvre pas, et une image d’un bâtiment ou d’une sculpture d’autrui exige encore l’autorisation.

Enfin, les personnes dans les images sont une question de données à caractère personnel, non seulement une question de politesse : au sens du règlement (UE) 2016/679, la photographie d’une personne identifiable est une donnée à caractère personnel, et la base juridique peut être le consentement ou le contrat ; le consentement doit être libre, spécifique, éclairé et univoque. Le point pratique le plus important est que le consentement peut être retiré, et qu’après le retrait les images doivent être ôtées de l’environnement public, donc les photographies d’équipe sur le site doivent être organisées de telle sorte qu’un salarié qui part ne devienne pas un problème.

L’environnement de préproduction et l’erreur que l’on commet avec les meilleures intentions

Avant la publication, le travail se fait dans un environnement distinct, et c’est nécessaire pour une raison simple : le commanditaire doit voir une vraie page dans un vrai navigateur, non une image d’un outil de design, et les erreurs doivent être attrapées là où les clients ne les voient pas. La question est seulement comment fermer cet environnement, et c’est précisément ici que l’on commet une erreur qui a l’air juste.

La solution répandue est d’inscrire une interdiction dans le fichier robots.txt, et cela ne fait pas ce que les gens croient, parce que la documentation de Google l’écrit directement : ce fichier indique aux robots d’exploration à quelles adresses ils peuvent accéder, et il sert principalement à ne pas surcharger le site de demandes, mais ce n’est pas un mécanisme pour tenir une page hors de Google. Pour qu’une page n’apparaisse pas dans les résultats de recherche, il faut utiliser la règle noindex, ou protéger l’environnement par un mot de passe.

Vient ensuite le détail à cause duquel les deux méthodes ensemble marchent moins bien que chacune toute seule. La règle noindex n’opère que si la page est explorable, parce que le robot doit la lire ; si la page est interdite dans le fichier robots.txt, le robot ne verra jamais cette règle, et la page peut encore apparaître dans les résultats, par exemple si des liens d’ailleurs y mènent ; de plus, Google ne permet pas de spécifier la règle noindex dans le fichier robots.txt.

Il y a aussi une seconde raison pour laquelle ce n’est pas un problème théorique, à savoir que si l’environnement de préproduction contient le même contenu que le site achevé, le moteur de recherche peut tenir précisément celui-là pour la version principale et l’afficher dans les résultats à la place de votre site, ce qui signifie que le visiteur atterrit sur une page inachevée, avec des données de test. Cette erreur est difficile à remarquer, parce que le site lui-même fonctionne impeccablement et que le problème n’est visible que dans les résultats de recherche.

La réponse pratique est donc simple, et il vaut la peine de la demander directement : l’environnement de préproduction se protège par un mot de passe. C’est la seule solution qui, indépendamment du comportement des robots d’exploration, garantit qu’un site inachevé n’apparaît nulle part, et qui en même temps écarte le second risque, auquel on pense plus rarement, à savoir qu’un environnement de préproduction au même contenu puisse être tenu pour la version principale et se mettre à concurrencer le vrai site.

Quelles décisions, après la mise en ligne, coûtent le plus cher

La plupart des décisions dans un projet de site web restent modifiables aussi après la mise en ligne, et il vaut la peine de le dire clairement, parce que les commanditaires s’inquiètent souvent précisément des choses que l’on change plus tard le plus facilement. Les couleurs, la mise en page, le modèle, les textes et même l’emplacement des pages dans le menu se changent pratiquement à tout moment, et cela ne coûte que des heures de travail, non une reconstruction, mais deux choses sont différentes, et c’est précisément à leur sujet qu’il vaut la peine de réfléchir avant la mise en ligne, tant que le changement ne coûte encore rien.

La première, c’est la structure des adresses, et elle devient une décision précisément au moment où les pages sont indexées et où des liens externes y mènent, parce qu’à partir de cet instant changer les adresses n’est plus un choix visuel, mais une migration de site, que Google décrit comme une procédure distincte, avec ses propres exigences. Il faut utiliser des redirections permanentes côté serveur et les conserver au moins un an ; Google met aussi en garde de ne pas changer en une seule fois les adresses, le système de gestion de contenu et la mise en page, et pour un site d’entreprise ordinaire recommande de déplacer toutes les adresses en une fois, non par morceaux ; de plus, il y a au même endroit une note utile qui réduit la peur : les redirections permanentes, par elles-mêmes, n’entraînent pas de baisse du PageRank, même si le positionnement peut, un temps, varier.

La seconde, c’est le domaine lui-même, parce que le changement de domaine est la même migration, avec toutes ses exigences, seulement à plus grande échelle, et s’y ajoute tout ce qui est déjà imprimé sur les cartes de visite et le papier à en-tête. Sur le nom au titre duquel le domaine doit être enregistré, nous avons écrit dans l’article sur les dix erreurs à éviter lors de la création d’un site web, et nous ne le répétons pas ici ; ici il vaut seulement de dire que le choix du domaine est l’une des rares décisions qu’il coûte plus cher de changer plus tard que de faire juste tout de suite.

Il y a un détail de procédure qu’il est bon de connaître pour ne pas le demander sans besoin : la demande de changement d’adresse dans les outils du moteur de recherche ne se dépose que si le domaine ou le sous-domaine change ; pour le passage d’une connexion non sécurisée à une connexion sécurisée, ou pour le choix entre une adresse avec et sans le préfixe www sur le même domaine, elle n’est pas prévue, et là les redirections correctes suffisent. Pour une entreprise, cela signifie que la plus grande part des changements se règle côté serveur, non dans un formulaire.

Pratiquement, il en résulte un conseil avant la mise en ligne : si l’ancien site existe déjà et qu’il a des visiteurs venus des moteurs de recherche, la liste des adresses avec les redirections vers les nouvelles doit être préparée avant la publication, non après que quelqu’un remarque la chute des visites. Cette liste est aussi l’un de ces travaux que le commanditaire peut préparer lui-même, et qui, si personne ne la prépare, devient après la mise en ligne une semaine de travail de recherche.

Accessibilité : pour qui c’est un devoir, et pour qui ce n’est pas

Pour les organismes du secteur public, l’accessibilité est un devoir depuis plusieurs années ; pour une entreprise privée — seulement si elle fournit un service énuméré par la loi, le plus souvent le commerce électronique, et qu’elle n’est pas une microentreprise. Un site vitrine qui ne vend rien n’entre pas dans cette liste ; une entreprise dont le chiffre d’affaires moyen réalisé en France, sur les trois derniers exercices, atteint deux cent cinquante millions d’euros est toutefois déjà liée, même si le site ne vend rien. Sur le marché, on confond souvent ces deux régimes, et c’est une erreur qui coûte.

Le premier concerne le secteur public, et il est en vigueur depuis plusieurs années, donc pour les institutions ce n’est pas une nouveauté. La directive de l’Union européenne sur l’accessibilité des sites des organismes du secteur public est reprise en France par l’article 47 de la loi n° 2005-102 du 11 février 2005, précisé par le décret n° 2019-768 et mis en œuvre par le RGAA, qui demandent de respecter quatre principes — que les contenus soient perceptibles, utilisables, compréhensibles et robustes — et de publier une déclaration sur l’accessibilité distincte. Ce régime lie les organismes publics et, depuis le décret de 2019, aussi les entreprises dont le chiffre d’affaires annuel moyen réalisé en France sur les trois derniers exercices atteint deux cent cinquante millions d’euros, pour tout service de communication au public en ligne ; une entreprise privée ordinaire sous ce seuil reste hors de l’article 47, même si le marché le présente parfois comme une exigence générale.

Le second est plus récent, et c’est précisément lui qui produit la plus grande part des malentendus, parce que la date d’application a été largement annoncée, le périmètre non : l’acte européen sur l’accessibilité est repris en France par l’article L. 412-13 du Code de la consommation, applicable aux produits mis sur le marché et aux services fournis à compter du 28 juin 2025, avec le décret n° 2023-931. Cela ne signifie pas qu’à partir de cette date chaque site d’entreprise doive se conformer à un standard d’accessibilité, et c’est précisément cette affirmation trop large que le marché répète le plus souvent, parfois avec l’offre d’y remédier.

La loi porte sur une liste précise de services, non sur n’importe quel site, et y entrent les services de communications électroniques, l’accès aux services de médias audiovisuels, certains éléments des transports de voyageurs aériens, ferroviaires, par autobus et par voie de navigation, les services bancaires aux consommateurs, les livres numériques et le commerce électronique. Un site vitrine d’entreprise qui ne vend rien et n’est ni une banque, ni un opérateur de transport, ni une plateforme de livres, n’entre pas dans cette liste.

Il y a aussi une dispense pour les petites entreprises, et il faut la formuler avec précision, parce qu’on la raconte trop souvent trop large. Les entreprises employant moins de dix personnes qui fournissent des services et dont le chiffre d’affaires annuel n’excède pas deux millions d’euros ou dont le total du bilan n’excède pas deux millions d’euros sont dispensées des exigences d’accessibilité des services et de toutes les obligations qui y sont liées. La dispense porte sur les services ; les obligations liées aux produits, pour les microentreprises, sont plus légères mais non annulées, donc la phrase selon laquelle les microentreprises sont dispensées de la loi n’est pas exacte.

La conclusion pratique pour le commanditaire est brève : si vous créez un site e-commerce et que vous n’êtes pas une microentreprise, les exigences d’accessibilité doivent être inscrites dès le cahier des charges, parce que plus tard elles signifient une reprise. Si vous créez un site vitrine, une obligation juridique, selon toute vraisemblance, n’existe pas — sauf le cas, rare dans ce marché, de l’entreprise au-dessus du seuil de deux cent cinquante millions d’euros de l’article 47 — mais cela reste un argument pour que la page soit utilisable au clavier et lisible avec un lecteur d’écran, parce qu’une partie de vos clients s’en sert indépendamment de la loi.

Combien de temps tout cela prend

La question du délai est celle à laquelle le commanditaire veut une réponse en premier, et c’est aussi celle à laquelle une réponse honnête est la plus difficile à donner. Les délais publiés dans le métier viennent presque toujours des pages des développeurs eux-mêmes, où ils servent de promesse de vitesse, donc on ne peut pas s’en servir comme d’un point de donnée indépendant, et nous n’avons pas trouvé d’étude indépendante avec une méthodologie.

Il est donc plus juste de parler de ce qui fixe le délai, plutôt que de chercher un chiffre moyen qui, de toute façon, ne conviendrait à aucun projet concret : le délai est fixé par le périmètre, la vitesse des validations et la préparation du contenu, et dans les deux derniers de ces trois l’influence décisive est du côté du commanditaire. Un projet où les textes sont prêts avant le début et où les décisions sont prises par une seule personne avance nettement plus vite qu’un projet du même périmètre sans ces deux conditions, et c’est une différence que l’on mesure en semaines.

Le délai que nous publions nous-mêmes sur la page de développement WordPress est de quatre à dix semaines, et il concerne un site d’entreprise ordinaire, tandis que pour les projets plus complexes il est plus long, et pour l’e-commerce plus long encore, mais pour un projet concret le seul délai utile est celui qui suit du périmètre, non d’un indicateur moyen.

Il y a encore une autre façon de regarder cette question, et pour le commanditaire elle est d’ordinaire plus utile que n’importe quel chiffre : demandez au développeur non pas combien de temps cela prendra, mais quelles semaines dépendent de vous et lesquelles de lui. La réponse à cette question est vérifiable, et elle montre tout de suite quelle part du délai vous contrôlez vous-même.

Et encore une chose qui pèse sur le délai plus qu’il n’y paraît, c’est l’accroissement du périmètre en cours de travaux : chaque nouvelle suggestion, prise à part, est petite et fondée, mais ensemble elles déplacent la date de remise, et cela se produit sans qu’on le remarque, parce qu’aucune d’elles n’a jamais l’air d’une décision de prolonger le projet. La seule chose qui y remédie, c’est l’accord que les modifications hors du périmètre initial sont consignées à part, avec leur effet sur le délai, au lieu d’être incluses en silence.

De quoi convenir avant que le travail commence

Avant la première ligne de facture, il vaut la peine de discuter et d’écrire un calendrier des contenus avec des dates : qui écrit les textes, pour quelle date ils sont entre les mains du développeur, et ce qui se passe s’ils retardent, parce que sans ce point le retard a toujours l’air d’être la faute du développeur.

Le deuxième, c’est l’origine des images et les droits, à savoir d’où viennent les photographies, quelle licence elles ont, si la licence mentionne l’utilisation précisément sur le site, et si les personnes dans les images ont donné un consentement qu’elles peuvent plus tard retirer. Le troisième, c’est un seul décideur, avec nom et prénom, ainsi qu’un accord sur le nombre de jours ouvrés dans lesquels on attend une réponse à une demande de validation, parce que sans délai la validation n’est pas une grandeur planifiable.

Le quatrième, c’est un environnement de préproduction protégé par un mot de passe, non par une interdiction dans le fichier robots.txt, et le cinquième une liste de redirections des anciennes adresses vers les nouvelles, si l’ancien site existe déjà et qu’il a des visiteurs. Le sixième, c’est la question de l’accessibilité, dont la réponse dépend de ce que fait votre site, et qu’il est beaucoup moins cher de poser au moment de rédiger le cahier des charges qu’après la remise.

Cette liste, il vaut la peine de l’examiner en une seule conversation, non par morceaux, parce que c’est précisément ensemble qu’elle montre quelle part du projet dépend du commanditaire, et c’est d’ordinaire plus grand que le commanditaire ne l’attendait. Aucune de ces exigences n’est chère, et aucune n’exige de connaissances techniques ; elles exigent seulement que quelqu’un les pose avant le début des travaux.

Et le septième, qui n’est pas technique mais tranche plus que les six autres : l’accord sur ce qu’est le périmètre minimal avec lequel le site peut être publié. Un projet où l’on publie seulement quand tout est prêt tend à ne se publier jamais, tandis qu’un projet avec un périmètre minimal clair se publie à temps et grandit ensuite. Si vous voulez que nous ayons cette conversation avec vous, écrivez-nous.