Un site qui se tient visuellement se génère désormais en une heure, et le résultat est souvent meilleur, graphiquement, que ce qu’une agence livrait il y a cinq ans. Je le constate comme tout le monde en faisant défiler Reddit le soir. La question n’est plus de savoir si l’outil sait dessiner. Il sait.

Elle est de savoir ce qu’un site doit faire en plus d’être beau, et là l’écart se creuse d’un coup.

La sandwicherie

Le cas qui m’a décidé à écrire ça : une sandwicherie, quelque part, dont le site tout neuf ouvre sur une animation de quinze secondes. Fond noir, logo qui se dessine trait par trait, titre qui monte en fondu. C’est joliment fait. Je ne suis même pas ironique, l’animation est réussie.

Sauf que le visiteur de ce site, c’est quelqu’un debout dans la rue à midi vingt, en 4G médiocre entre deux immeubles, qui veut savoir si c’est ouvert et où c’est. Pendant quinze secondes, il ne peut rien faire. Il n’attend pas, il revient en arrière, et il va chez le concurrent dont le site est moche, mais dont l’adresse est écrite en haut. Le site a coûté une heure à produire et il fait perdre des clients tous les midis, sans que personne ne fasse le lien, parce que rien dans les statistiques ne dit « ces gens sont partis à cause de l’animation ». Ils apparaissent comme des visites d’une seconde, et une visite d’une seconde ressemble à un robot.

L’outil ne pouvait pas savoir. Il ne connaît ni le métier, ni l’heure à laquelle on consulte ce site, ni l’état du réseau à ce moment-là. Il a produit ce qui fait de belles captures d’écran, parce que c’est là-dessus qu’il a appris, et les belles captures d’écran sont précisément ce que personne ne regarde quand il a faim.

La même mécanique produit le reste de la famille : la section d’ouverture plein écran où rien n’est écrit, les trois cartes « Rapide, Fiable, Sur mesure » que personne ne peut contredire et qui ne disent donc rien, les compteurs qui s’animent vers des chiffres ronds, les témoignages sans nom d’entreprise, le formulaire de contact à huit champs. Et surtout ce qu’on ne voit jamais sur une capture : l’état vide quand il n’y a encore aucun produit, l’écran de chargement, le message d’erreur, le parcours au clavier et la page avec du vrai contenu dedans : des noms de quarante caractères, une description de trois lignes, une photo au mauvais format.

Le paquet qui part chez le visiteur

Un site vitrine statique ne risque pas grand-chose. Dès qu’il y a un formulaire, un espace membre ou un paiement, les mêmes trous reviennent, et le premier est toujours le même : une clé d’API dans le code envoyé au navigateur. Tout ce qui n’est pas explicitement marqué comme public part chez le visiteur, y compris la clé du service d’envoi de courriels, qui sert alors à écrire au nom du client.

Viennent ensuite les routes qui agissent sur la ressource de quelqu’un d’autre. Ce n’est pas l’absence d’authentification, que tout le monde attrape : c’est l’identifiant qui vient de l’URL et qu’on ne confronte jamais à la session. J’en ai laissé passer une, sur un projet à moi, qui accordait une récompense sur un identifiant de joueur fourni par l’appelant. Elle a vécu des semaines.

Le reste tient en deux lignes. Une validation qui n’existe que côté navigateur se contourne avec l’onglet réseau ouvert. Et un secret poussé une fois dans un dépôt est compromis même après suppression : il se change, il ne s’efface pas.

Rien de tout ça n’apparaît au premier essai. Ça apparaît le jour où quelqu’un cherche.

Après la mise en ligne, plus personne

L’écart le plus coûteux, et le plus invisible, parce qu’il ne se manifeste qu’en cas de problème.

Mettre en ligne est devenu facile et les outils le font très bien. Ce qui ne se fait presque jamais, c’est le reste : une sauvegarde qu’on a effectivement restaurée au moins une fois, une procédure de retour arrière écrite quelque part, une supervision qui prévienne avant le client. Sur la sauvegarde, j’ai une anecdote que je ressors souvent, parce qu’elle m’a coûté une soirée blanche : ma propre procédure affichait [OK] Restauration terminée après deux cent vingt-trois erreurs, pendant des mois, parce qu’il manquait deux options sur deux commandes. Une sauvegarde qu’on n’a jamais relue n’est pas une sauvegarde, c’est une hypothèse.

Quant au retour arrière : que fait-on quand la mise à jour de mardi casse la prise de commande ? Sans réponse écrite, la réponse est « on cherche », en production, avec le client au téléphone.

Six mois, c’est le délai

C’est le point qui décide de tout et dont on ne parle jamais, parce qu’il ne se voit pas avant six mois. Une poignée de décisions, prises en dix minutes au début, ne se défont plus ensuite sans refaire le projet.

La première : comment les données d’un client sont-elles séparées de celles d’un autre ? Une base commune avec une colonne qui dit à qui appartient chaque ligne, ou une base par client. Le jour où il y a un deuxième client, le choix est déjà fait, et le rattraper plus tard sur une application en service est un chantier entier. La deuxième : qu’est-ce qui est acheté et qu’est-ce qui est livré ? Si le produit se vend par options, la frontière doit exister dans la structure des données, pas seulement dans l’affichage. Cacher une fonction derrière un droit alors que ses tables sont présentes chez tout le monde n’est pas la même promesse commerciale, et ça se découvre au premier audit. La troisième tient en une phrase : un module qui dépend du socle se retire, un socle qui dépend d’un module ne se retire plus. La quatrième, c’est l’identité : changer de source d’identité après coup impose de reprendre chaque ligne nominative une par une.

Aucune de ces questions n’a de bonne réponse universelle. Elles dépendent de ce que l’entreprise vend, de combien de clients elle espère, de ce qu’elle est prête à maintenir. Un outil de génération produit un ensemble qui marche pour le cas qu’on lui a décrit ; il ne se demande pas ce qui arrive au deuxième client, ni au dixième module, ni le jour où le premier utilisateur réclame l’effacement de ses données. On ne peut pas vraiment le lui reprocher : la question n’a simplement pas été posée, et le silence sur une question de ce type reste un choix, pris par défaut, par personne.

Sur un site qu’on vient de vous livrer

Trois vérifications tiennent en dix minutes et ne demandent aucune compétence technique. Ouvrez-le sur un téléphone en 4G, pas en wifi, et comptez les secondes avant de pouvoir faire quelque chose ; au-delà de trois, c’est un problème. Réduisez la fenêtre au minimum sur ordinateur : si une barre de défilement horizontale apparaît, la mise en page déborde. Parcourez enfin la page à la touche de tabulation, et si vous ne voyez jamais où vous en êtes, personne ne se servira de ce site au clavier.

Les deux questions qui restent se posent à la personne qui a livré, pas au site. Où est la sauvegarde, et quand a-t-elle été restaurée pour la dernière fois ? La deuxième moitié de la question est celle qui compte. Et : que se passe-t-il si la mise à jour de demain casse quelque chose ? S’il n’y a pas de réponse en une phrase, il n’y a pas de procédure.

Je m’en sers tous les jours

Il faut être honnête sur l’endroit d’où je parle. Ces outils, je les utilise, et ce site en porte la trace : sa mise en page de départ venait d’un gabarit acheté, et j’ai mis un an à en retirer les dernières images de démonstration. Je ne prétends pas écrire chaque ligne à la main, ce serait faux et ce serait idiot.

Tout site n’a pas non plus besoin de ce niveau d’exigence. Une page de présentation pour une association de quartier, sans formulaire et sans données personnelles, peut très bien être générée en une heure et vivre ainsi dix ans. La différence ne tient pas à l’outil, elle tient à ce qu’on met derrière : dès qu’il y a de l’argent, des comptes ou des données de tiers, les quatre sujets ci-dessus finissent par se présenter. Ils se présentent tard, et ils se présentent chez quelqu’un qui ne les a pas choisis.