Développement web et applications

Vitrine, application métier, boutique : trois besoins que le mot « site » confond

En résumé : Une vitrine publie de l'information, une application fait avancer un travail, une boutique encaisse et gère tout ce qui suit la commande. Le nombre de pages ne dit rien de la difficulté : ce qui compte est la quantité d'états que le logiciel doit tenir et de règles qu'il doit faire respecter.

Le mot « site » désigne indifféremment des objets dont les points communs se réduisent à une adresse et à un navigateur. On les distingue mal parce qu'on les compare par leur apparence, alors que ce qui les sépare n'est pas visible. Une page qui présente une activité se contente d'être affichée : elle dit la même chose à tout le monde et ne retient rien. Un formulaire de réservation, lui, doit savoir ce qui est déjà pris, refuser ce qui ne l'est plus, garder trace de ce qui a été décidé et se comporter correctement quand deux personnes cliquent au même instant. Le second cas contient un état qui change, donc des conflits possibles, des droits d'accès, un historique et des règles de cohérence. C'est là que se trouvent l'essentiel de l'effort et l'essentiel des défauts, et non dans le nombre de pages ou la richesse du graphisme.

Le site vitrine publie. Son objet est d'être trouvé, compris, et de rendre un contact possible ; il ne modifie presque rien et sa valeur tient à la clarté de ce qu'il dit. Ses difficultés sont donc d'abord éditoriales : formuler ce qui est proposé, à qui, et en quoi cela diffère d'autre chose. Trois exigences techniques les accompagnent, souvent négligées parce qu'elles ne se voient pas sur une maquette. La rapidité d'affichage sur un appareil ordinaire et une connexion moyenne, qui décide du nombre de personnes qui restent. La structure du contenu, qui permet à un moteur — et désormais aux systèmes qui rédigent des réponses à partir de pages web — d'identifier de quoi traite chaque page et d'en citer le contenu correctement. Et la capacité de l'entreprise à modifier un texte sans dépendre de quiconque : une vitrine dont personne ne peut corriger une phrase se périme vite et finit par desservir.

L'application métier ne publie pas, elle fait travailler. Elle porte des comptes et des rôles, des données qui changent d'état — un dossier passe de reçu à traité, une demande est validée puis close —, des règles qui décident de ce qui est permis à qui, et une trace de qui a fait quoi. Sa complexité ne se lit pas sur les écrans : elle tient aux exceptions du métier, c'est-à-dire aux cas que la procédure officielle ne décrit pas et que les personnes traitent aujourd'hui de tête. Une application qui traite bien le cas nominal et mal les exceptions est perçue comme inutilisable, parce que ce sont précisément les exceptions qui consomment le temps de ceux qui s'en servent. C'est aussi la catégorie où les questions d'accès, de confidentialité et de conservation se posent pour de bon, puisque les données manipulées sont celles de l'activité et parfois celles de tiers.

La boutique ajoute l'argent, et avec lui une chaîne d'obligations qui ne s'arrête pas au paiement. Le catalogue, le panier et l'encaissement forment la partie visible ; derrière viennent la disponibilité réelle des articles, les règles de livraison et de taxe qui varient selon la nature du produit et le statut de l'acheteur, la facture, l'annulation, le remboursement, le retour, le litige, et la synchronisation avec ce qui tient les stocks ou la comptabilité. Une boutique est un logiciel de gestion des commandes déguisé en catalogue. La conséquence pratique mérite d'être posée dès le cadrage : elle se juge après la vente autant qu'avant. Un parcours d'achat impeccable qui débouche sur un suivi de commande approximatif produit du travail supplémentaire pour l'entreprise et de la défiance chez l'acheteur, ce qui coûte plus que ce que la mise en ligne a rapporté.

Beaucoup de projets réels tiennent des trois à la fois : une vitrine avec un espace client, une boutique adossée à un outil interne de préparation des commandes. Rien n'interdit ce mélange, à condition de savoir quelle partie relève de quoi, car chacune impose sa propre discipline. La question utile à poser d'emblée n'est donc pas « combien de pages », mais « qu'est-ce qui change quand quelqu'un s'en sert ». Rien du tout, et l'on est dans la publication. Quelque chose est enregistré et devra être retrouvé, corrigé, contesté, et l'on est dans l'application. Cette réponse commande tout le reste : la façon de cadrer, la façon de vérifier avant la mise en ligne, l'hébergement nécessaire, la charge d'entretien à prévoir, et la question de savoir si un produit existant fait déjà l'affaire. Elle se tranche avant toute conversation sur les technologies, qui ne sont qu'un moyen d'obtenir ce qui aura été décidé là.

Front-end, back-end, hébergement, base de données : ce que recouvre chaque mot

En résumé : Le front-end s'exécute chez l'utilisateur et ne peut jamais être tenu pour sûr ; le back-end décide et enregistre ; la base de données survit au code ; l'hébergement est l'endroit où tout cela tourne, et surtout la question de savoir qui l'entretient.

Le front-end désigne ce qui s'exécute dans le navigateur de la personne qui consulte. Trois langages s'y répartissent le travail : un langage de structure, qui déclare ce que sont les éléments (un titre, une liste, un champ, un bouton) ; un langage de présentation, qui décide de l'apparence et de l'adaptation aux tailles d'écran ; et un langage de programmation, qui ajoute des comportements. Cette répartition n'est pas une convention esthétique. C'est la structure, et elle seule, qui permet à une technologie d'assistance d'annoncer qu'un élément est un bouton, à un moteur de comprendre la hiérarchie d'une page, et au navigateur de rendre l'interface utilisable au clavier sans qu'on ait rien à programmer. Un bouton fabriqué à partir d'un élément quelconque ressemble à un bouton sans en être un, et c'est une source courante de défauts d'accessibilité. Deux propriétés du front-end sont à retenir : il s'exécute sur un appareil que vous ne choisissez pas, ce qui fait de la diversité des navigateurs, des écrans et des connexions une contrainte réelle ; et il est entièrement visible et modifiable par celui qui l'affiche.

Le back-end s'exécute sur une machine que vous contrôlez. C'est lui qui vérifie l'identité de l'utilisateur, décide de ce qu'il a le droit de voir et de faire, applique les règles du métier, enregistre et relit les données. La seconde propriété du front-end énoncée plus haut a ici une conséquence qu'aucun projet sérieux n'ignore : un contrôle effectué uniquement dans le navigateur n'est pas un contrôle, puisqu'il suffit de ne pas passer par l'interface pour le contourner. Toute vérification qui engage quelque chose — un prix appliqué, un droit d'accès, une quantité disponible, l'appartenance d'un document à celui qui le demande — doit être refaite côté serveur, même lorsqu'elle est déjà faite côté navigateur pour le confort. Les deux moitiés communiquent par une interface de programmation, souvent appelée API : un ensemble d'adresses qui acceptent des demandes précises et renvoient des réponses dans un format convenu. Cette frontière a une vertu durable, celle de permettre de refaire l'interface sans toucher aux règles, ou d'alimenter plus tard un autre outil avec les mêmes données.

La base de données est l'endroit où l'information persiste. On y décrit d'abord une structure : quelles entités existent, quels attributs elles portent, comment elles se relient, et quelles contraintes doivent rester vraies quoi qu'il arrive — une commande appartient à un client existant, une même adresse ne se retrouve pas en double, une quantité ne devient pas négative. Confier ces garanties à la base plutôt qu'au seul code se paie en tranquillité, car la base les fait respecter même quand une partie du programme se trompe. On rencontre deux familles : les bases relationnelles, organisées en tables reliées entre elles, adaptées lorsque les données ont une forme régulière et des relations fortes ; et les bases documentaires, plus souples sur la forme, adaptées lorsque chaque enregistrement diffère de ses voisins. Deux points comptent davantage que ce choix. La migration d'abord : la structure évoluera, et la faire évoluer alors qu'elle contient déjà des données est un exercice qui se prépare plutôt qu'il ne s'improvise. La restauration ensuite : une sauvegarde dont on n'a jamais vérifié qu'elle se restaure n'est pas une sauvegarde. Les données survivent au code — on réécrit une application, on ne réinvente pas l'historique des commandes.

L'hébergement est l'endroit où le programme s'exécute et d'où les fichiers sont servis. Les formules se distinguent moins par leur nom commercial que par la répartition des responsabilités : qui met à jour le système d'exploitation, qui surveille le service, qui intervient lorsque la fréquentation augmente brusquement, qui restaure après un incident. Un serveur partagé confie beaucoup à l'hébergeur et laisse peu de latitude ; une machine virtuelle donne le contrôle complet et l'obligation qui va avec ; une plateforme gérée prend en charge l'exécution et le déploiement en imposant ses conventions ; un site composé de fichiers déjà calculés, complété de quelques fonctions appelées à la demande, réduit fortement la surface à entretenir lorsque le besoin s'y prête. Trois éléments accompagnent l'hébergement et provoquent, lorsqu'on les oublie, des interruptions sans qu'une ligne de code ait changé : le nom de domaine, qui est un enregistrement à renouveler ; la configuration qui associe ce nom à un serveur ; et le certificat qui autorise la connexion chiffrée. Enfin, un projet sérieux dispose d'environnements séparés — un pour développer, un pour vérifier, un pour la production — faute de quoi toute correction se tente devant les utilisateurs.

Reste ce qui relie ces couches et n'apparaît sur aucune maquette. Le code source vit dans un dépôt versionné, qui conserve l'historique des modifications, permet de revenir à un état antérieur et rend possible le travail à plusieurs sans que l'un écrase l'autre. Le déploiement est la procédure qui transforme ce code en site en ligne ; automatisée, elle devient reproductible et cesse de dépendre de la mémoire d'une personne. Les journaux consignent ce que le programme a fait et sont le seul moyen de comprendre un incident après coup ; la supervision prévient qu'un service ne répond plus avant qu'un client ne le signale. Ces éléments passent pour du confort de développeur ; ils décident en réalité de la capacité à réparer. Un site se résume finalement à trois choses qu'il faut détenir ensemble pour en être maître : le code, les données et la configuration — cette dernière incluant les identifiants d'accès aux services tiers. En posséder deux sur trois ne suffit pas.

Comment se déroule un projet, du cadrage à la maintenance

En résumé : Décrire les parcours réels avant de dessiner, dessiner avant de coder, livrer par tranches utilisables, faire vérifier par ceux qui s'en serviront, préparer la mise en ligne comme une opération à part entière, puis entretenir ce qui a été construit.

Le cadrage fonctionnel décrit ce que le logiciel doit permettre, pour qui, et à quoi l'on reconnaîtra que c'est réussi. Une liste de fonctionnalités n'y suffit pas, parce qu'elle énumère des moyens sans dire à quoi ils servent. On décrit plutôt des parcours : une personne arrive avec une intention, elle enchaîne des actions, elle obtient un résultat. Trois éléments sont systématiquement oubliés et systématiquement coûteux. Les cas anormaux : que se passe-t-il quand une information manque, quand un paiement échoue, quand une pièce jointe est illisible, quand la même opération est tentée deux fois. Les règles de gestion écrites noir sur blanc : qui a le droit de voir quoi, ce qui se passe à l'annulation, ce qui est conservé et pour quel usage. Et le hors-périmètre, énoncé explicitement, qui protège les deux parties bien mieux qu'une liste d'inclusions. Le cadrage sert enfin à trier ce qui doit exister à l'ouverture et ce qui peut venir ensuite : un périmètre trié se construit par tranches, un périmètre non trié se construit en entier ou pas du tout.

Les maquettes servent à discuter d'un dessin plutôt que d'un programme, parce qu'un dessin se jette sans regret. On distingue les schémas fonctionnels, volontairement gris et sans style, qui arbitrent ce qu'on montre, dans quel ordre et à quel endroit, des maquettes graphiques qui fixent ensuite l'apparence. Mélanger les deux fait discuter de couleurs quand il faudrait discuter d'organisation, et les remarques portent alors sur ce qui se change facilement plutôt que sur ce qui coûte cher. Deux exigences rendent cette étape utile plutôt que décorative. Travailler avec du contenu réel d'abord : les vrais intitulés, les vrais noms, les vraies photographies et les volumes effectifs, car une maquette remplie de texte factice et de trois articles bien choisis ment sur ce que sera l'écran une fois rempli. Dessiner les états inconfortables ensuite : la liste vide du premier jour, le message d'erreur, l'attente pendant un traitement, le texte qui déborde, la connexion perdue. Ces états représentent une part considérable du travail de développement et n'apparaissent presque jamais dans une présentation. Le comportement sur petit écran se décide au même moment, et il se décide en premier plutôt qu'en dernier : la contrainte d'un écran étroit force à hiérarchiser l'information, ce dont la version large profite ensuite.

Le développement avance mieux par tranches verticales que par couches successives. Une tranche verticale est une fonctionnalité complète, de l'écran jusqu'à la base de données : elle fonctionne, donc elle se montre, donc elle se discute. Construire d'abord toute la base, puis tout le back-end, puis tous les écrans repousse à la fin le moment où quelqu'un voit quelque chose, c'est-à-dire le moment où les malentendus se révèlent. Chaque itération se termine par une démonstration à des personnes du métier, et cette démonstration corrige le cadrage : l'usage fait apparaître des cas que personne n'avait su formuler à froid. Deux pratiques rendent ce rythme soutenable. La relecture du code par une autre personne, qui attrape des défauts mais surtout répartit la connaissance, de sorte que le projet ne repose pas sur une seule tête. Et les tests automatisés, réservés en priorité aux règles dont la rupture coûterait cher — les calculs, les droits d'accès, les enchaînements d'états — parce qu'ils permettent ensuite de modifier le programme sans craindre de casser en silence ce qui fonctionnait.

La recette est la vérification, par celui qui a commandé, que ce qui est livré fait ce qui avait été demandé. Elle ne se confond pas avec les tests du développeur, qui vérifient que le programme fait ce que son auteur croit avoir écrit ; on ne relit pas utilement son propre travail avec les yeux de celui qui l'a produit. Elle réclame trois conditions : un environnement distinct de la production, des données réalistes plutôt que des exemples choisis, et des scénarios écrits à l'avance — idéalement ceux du cadrage, ce qui donne à ce dernier une utilité seconde. On y cherche ce qui casse plutôt que ce qui marche. Les anomalies remontées se trient ensuite selon leur gravité, et surtout selon une distinction que le projet doit poser avant d'en avoir besoin : ce qui ne fonctionne pas relève de la correction, ce qui fonctionne autrement qu'espéré relève de l'évolution. Confondre les deux est une source de conflit en fin de projet. Une recette se termine par une décision explicite, écrite, portant sur ce qui est accepté, ce qui reste à corriger et ce qui est reporté.

La mise en ligne est une opération à part entière et non l'appui sur un interrupteur. Elle comporte des étapes qui n'ont rien à voir avec le code : la reprise des données existantes, avec la décision, pour chaque ensemble, de ce qui bascule dans le nouvel outil, de ce qui reste consultable en archive et de ce qui disparaît ; la redirection des anciennes adresses vers les nouvelles lorsqu'un site en remplace un autre, faute de quoi les liens accumulés et les pages déjà connues des moteurs cessent de mener quelque part ; le basculement du nom de domaine et la vérification du certificat ; le retrait des consignes qui empêchaient l'indexation pendant la fabrication, oubli si classique qu'il mérite une ligne dans la procédure ; la mise en service de la mesure d'audience et du recueil du consentement. On prévoit également ce que l'on fait si quelque chose ne va pas : revenir à l'état précédent doit être une opération connue et répétée, pas une improvisation sous tension. Enfin, les personnes qui répondront aux questions des utilisateurs sont prévenues avant les utilisateurs eux-mêmes.

Ce qu'on appelle maintenance recouvre trois activités qu'il vaut mieux nommer séparément, parce qu'elles n'obéissent pas à la même logique. La correction traite ce qui ne fonctionne pas. L'évolution ajoute ce que l'usage a révélé, et elle est le signe qu'un outil est vivant plutôt qu'un aveu d'échec du cadrage. Le maintien en condition est le moins visible et le plus négligé : mettre à jour les composants dont le site dépend lorsqu'une faille y est publiée, suivre les versions du langage et du système, renouveler les certificats, vérifier que les sauvegardes se restaurent réellement, contrôler que les services tiers utilisés n'ont pas modifié leurs interfaces. Un logiciel auquel on ne touche pas ne reste pas identique : son environnement bouge autour de lui, et l'immobilité produit une panne différée. Trois questions se règlent donc avant la fin du projet plutôt qu'après : qui détient les accès, où est écrite la procédure de déploiement, et à qui s'adresse-t-on lorsque quelque chose casse.

Les erreurs qui coûtent le plus cher dans un projet web

En résumé : S'engager avant d'avoir décrit, livrer sans faire vérifier, dépendre d'un prestataire faute de détenir son propre outil, traiter la performance et l'accessibilité comme une finition, et découvrir à la mise en ligne que le contenu n'existe pas.

La première erreur consiste à inverser l'ordre de l'engagement et de la description. Un accord conclu sur un périmètre résumé en quelques lignes ne fait pas disparaître l'incertitude, il la déplace : les zones laissées vagues devront bien être tranchées, et elles le seront plus tard, sous contrainte, par celui des deux qui aura le plus à perdre à s'arrêter. Le projet se termine alors soit par des fonctions rognées au dernier moment, soit par une suite de discussions sur ce qui était ou non compris. Une formule entendue partout illustre le problème : demander « la même chose que tel site » décrit une apparence, pas des règles, et deux sites d'apparence voisine peuvent différer entièrement par ce qu'ils font des informations qu'ils reçoivent. La parade n'est pas de tout figer, ce qui est impossible dans un projet vivant, mais de rendre la description du besoin antérieure à l'engagement et de nommer explicitement ce qui n'est pas dedans. Un périmètre est d'autant plus tenable qu'il énonce ses exclusions ; c'est aussi ce qui rend une demande d'ajout discutable sereinement, comme un ajout, plutôt que comme un dû.

La deuxième est de considérer la livraison comme la fin du travail. Sans recette, la première utilisation réelle a lieu en production, avec des données réelles et des personnes qui n'ont pas le loisir d'échouer. Les défauts qu'une recette attrape sont toujours les mêmes et n'apparaissent jamais dans une démonstration : les accents et les apostrophes dans les noms propres, les champs laissés vides, les textes plus longs que ce que l'écran prévoyait, les fichiers refusés sans explication, deux personnes qui modifient le même enregistrement au même moment, le bouton retour du navigateur, la session expirée au milieu d'un formulaire, la double soumission d'une commande. On les trouve en cherchant à casser, pas en cherchant à montrer. Le point décisif est que la recette se prépare pendant le cadrage et non la veille de la livraison : écrire à l'avance ce qui vaudra preuve de bon fonctionnement oblige à préciser le besoin, et le même document sert une fois pour spécifier, une fois pour vérifier.

La troisième est la dépendance involontaire envers un prestataire. Elle ne s'installe presque jamais par mauvaise intention, mais par défaut, parce que personne n'a posé la question au départ. Le nom de domaine est enregistré au nom du prestataire, le dépôt de code est chez lui, l'hébergement est ouvert sur son compte, la procédure de déploiement n'existe que dans sa mémoire, la base de données n'a jamais été exportée, les identifiants des services tiers sont les siens. Pris isolément, chacun de ces points paraît anodin ; réunis, ils font qu'une entreprise ne peut plus ni changer de partenaire, ni continuer seule, ni parfois même corriger une ligne de texte. Les questions à poser avant de commencer ne sont pas une marque de méfiance, ce sont des questions d'exploitation : qui détient le nom de domaine, où vit le code source et à quelles conditions il est utilisable, comment obtient-on une copie complète des données et sous quel format, qui peut déployer, que faut-il pour qu'une autre équipe reprenne le travail. Un signe pratique vaut inventaire : si modifier une phrase impose d'écrire à quelqu'un, la dépendance est déjà installée.

La quatrième est de traiter la performance et l'accessibilité comme une finition. Ni l'une ni l'autre n'est une option qu'on active à la fin ; toutes deux résultent de décisions prises tôt. La rapidité d'affichage dépend du poids des images et du format dans lequel elles sont servies, du nombre de fichiers à télécharger avant que la page devienne utilisable, du temps de réponse du serveur et des requêtes faites à la base, de la quantité de code exécuté dans le navigateur, et du choix de calculer les pages à l'avance, à la demande sur le serveur, ou chez l'utilisateur. Ces décisions sont structurelles : les reprendre après coup revient souvent à refaire l'ouvrage. L'accessibilité obéit à la même logique. Elle consiste à employer les éléments prévus pour ce qu'ils font, à rendre chaque interaction utilisable au clavier, à associer un intitulé à chaque champ, à garantir un contraste lisible, à ne jamais porter une information par la seule couleur, à laisser visible l'élément qui a le focus, et à ne pas piéger l'utilisateur dans une fenêtre dont il ne peut pas sortir. Reprise en fin de parcours, elle suppose de reconstruire les composants ; intégrée dès la conception, elle ne change presque rien à la charge. Deux arguments s'entendent rarement ensemble et méritent de l'être : ce travail sert bien au-delà des situations de handicap, puisqu'une connexion instable, un écran en plein soleil ou une main occupée créent les mêmes besoins ; et selon l'activité et le statut de l'organisation, des obligations d'accessibilité peuvent s'appliquer, ce qui vaut d'être vérifié au cadrage plutôt qu'à la réception.

La cinquième est moins technique et bloque pourtant beaucoup de projets : le contenu n'existe pas. Textes, photographies, descriptions de produits, mentions obligatoires, traductions, tout cela se produit, se relit et se décide, et rien ne se fabrique tout seul pendant que le développement avance. Un projet dont le contenu n'a pas de propriétaire attend, et il attend au moment le plus coûteux, lorsque tout le reste est prêt et que l'attention s'est dispersée ailleurs. Le même vide se retrouve du côté de la décision : quand plusieurs personnes émettent des avis contradictoires sans qu'aucune ne tranche, les allers-retours se multiplient, la responsabilité du retard devient indémêlable et la qualité du résultat baisse, car un écran conçu pour satisfaire tout le monde ne sert précisément personne. Deux désignations faites au départ suffisent à écarter les deux problèmes : quelqu'un qui produit et valide le contenu, quelqu'un qui arbitre. Ce sont des rôles, pas des titres, et les nommer coûte une phrase.

Quand un développement sur mesure n'est pas la bonne réponse

En résumé : Quand un produit existant configuré fait déjà l'affaire, quand le besoin n'est pas stabilisé, quand personne ne pourra entretenir le résultat, quand le problème n'est pas logiciel, et quand une refonte n'a d'autre motif que la lassitude.

Le premier cas est celui du besoin standard. Publier des pages, tenir un fil d'actualités, vendre des articles de façon ordinaire, prendre des rendez-vous, recueillir des inscriptions : ces problèmes sont résolus depuis longtemps par des produits largement diffusés, qu'une communauté ou un éditeur entretient en permanence. Choisir le sur-mesure dans ces conditions revient à reprendre à son compte un travail que d'autres font déjà : corriger les failles publiées, suivre les évolutions des navigateurs, s'adapter quand un service de paiement modifie son interface, absorber les changements de règles de facturation. Ce travail ne s'arrête jamais et reste invisible tant qu'il est fait. Le sur-mesure se justifie lorsque la façon de travailler est elle-même particulière — un enchaînement, un mode de calcul, une contrainte de métier qu'aucun produit ne sait exprimer — ou lorsque adopter un produit obligerait à déformer une activité qui fonctionne bien. Entre les deux se trouve la réponse la plus souvent juste et la moins spectaculaire : partir d'une base existante et ne développer spécifiquement que le point précis où l'organisation diffère. Un développement sur mesure est un avantage quand il porte sur ce qui vous distingue, et un handicap quand il porte sur ce qui vous ressemble.

Le deuxième cas est celui du besoin qui n'est pas encore stabilisé. Écrire un programme, c'est figer des décisions : chaque règle codée devient une hypothèse coulée dans la structure, et changer d'hypothèse coûte d'autant plus que le reste du code s'appuie dessus. Quand une organisation est en train d'inventer sa façon de faire — un service nouveau, un processus dont la forme change encore à chaque essai —, coder trop tôt fixe un état provisoire et transforme l'apprentissage en travaux de reprise. Une procédure manuelle, un tableur partagé ou un outil configuré assument très bien ce rôle transitoire : ils permettent d'essayer, de se tromper et de corriger sans rien casser, et ils produisent en outre la description du besoin que le développement réclamera plus tard. Le développement devient pertinent lorsque la façon de faire est connue et répétée, et que ce qui coûte n'est plus de la définir mais de l'exécuter.

Le troisième cas tient à ce qui vient après la livraison. Un logiciel sur mesure crée une obligation durable : quelqu'un devra installer les mises à jour de sécurité des composants employés, suivre les évolutions du langage et de l'hébergement, répondre aux utilisateurs, arbitrer les demandes d'évolution et financer tout cela. Une organisation qui n'a ni cette compétence en interne ni l'intention de la confier durablement se retrouvera avec un outil qui fonctionne au début et se dégrade ensuite, plus vite qu'un produit du commerce et non moins vite, car rien ne se met à jour de soi-même et aucun éditeur ne s'en charge à sa place. La question à poser avant de commencer n'est donc pas seulement « qui construit », mais « qui s'en occupe ensuite, et avec quels moyens ». Lorsque la réponse honnête est « personne », un produit configuré, moins ajusté au besoin mais entretenu par d'autres, est objectivement le meilleur choix ; l'annoncer avant de s'engager évite un outil abandonné au bout de peu d'usage.

Le quatrième cas concerne les situations où le logiciel n'est pas en cause. Un site n'apporte pas d'audience par lui-même : il transforme une visite en compréhension, puis en contact, mais encore faut-il que quelqu'un vienne. Quand les visites sont rares, la cause se trouve en amont — visibilité, notoriété, canaux employés, clarté de l'offre — et refaire l'outil ne la corrige pas. Le cas symétrique existe aussi : quand des demandes arrivent et restent sans réponse ou sans suivi, le problème est d'organisation interne, et un formulaire mieux dessiné ne fera qu'accélérer l'arrivée de demandes qui resteront en souffrance. Distinguer ces situations suppose de regarder ce qui se passe avant et après le site plutôt que le site lui-même : d'où viennent les visiteurs, ce qu'ils cherchaient, ce que deviennent les messages reçus, qui les traite et en combien de passages. Cet examen se conduit sans écrire une ligne de code et évite parfois un projet entier.

Le cinquième cas est celui de la refonte sans motif identifié. Un site en état de marche, que ses utilisateurs connaissent et que les moteurs ont appris à situer, représente une valeur accumulée qu'une reconstruction remet en jeu : les adresses changent, les habitudes se perdent, les pages déjà référencées doivent être retrouvées, et des défauts corrigés patiemment reviennent parfois par la fenêtre. Cette valeur ne se voit pas, ce qui explique qu'on la sacrifie facilement au nom d'une apparence jugée datée. Quand la gêne est identifiable — une navigation qui égare, un formulaire abandonné en cours de route, une lenteur constatée, un contenu devenu faux —, la réparer se juge mieux et se vérifie plus vite qu'une reconstruction complète. La refonte se justifie lorsque les défauts sont structurels : une organisation de l'information qui ne correspond plus à l'activité, une base technique qui ne reçoit plus de correctifs de sécurité, une impossibilité d'ajouter ce dont l'entreprise a désormais besoin. Une refonte décidée par lassitude, elle, dépense l'acquis contre une impression de nouveauté qui s'émousse, tandis qu'une réparation ciblée se constate.