Développement web & applications

Un site vitrine publie de l'information destinée à être lue : elle ne change que lorsque quelqu'un décide de la modifier. Une application web fait avancer un travail : elle contient des comptes, des droits, des données qui changent d'état à mesure qu'on s'en sert et des règles qui décident de ce qui est permis. Le critère de distinction n'est ni le nombre de pages ni l'apparence, mais la présence d'un état qui évolue. C'est ce critère qui commande la façon de vérifier avant la mise en ligne, l'hébergement nécessaire et la charge d'entretien à prévoir ensuite.

La question se tranche en regardant ce qui, dans votre activité, est réellement particulier. Si le besoin est ordinaire — publier, vendre de façon classique, prendre des rendez-vous —, un produit configuré fait le travail et son entretien est assuré par d'autres. Le sur-mesure se justifie lorsqu'une règle de métier, un enchaînement ou une contrainte propre à l'organisation ne peut pas s'exprimer dans un produit existant, ou lorsque l'adopter obligerait à déformer ce qui fonctionne. La voie intermédiaire est fréquente et souvent la meilleure : une base existante, complétée par un développement limité au point précis où l'organisation diffère des autres.

Rien de tout cela ne va de soi, et cela se décide par écrit avant de commencer. Trois éléments distincts sont en jeu. Le nom de domaine, qui doit être enregistré au nom de l'entreprise et non de son prestataire. Le code source, dont il faut savoir s'il est cédé, concédé sous licence d'usage, ou composé de briques ouvertes soumises à leurs propres conditions. Les données enfin, qui doivent pouvoir être récupérées intégralement dans un format exploitable en dehors de l'outil. À ces trois éléments s'ajoutent les accès : hébergement, base de données, services tiers, procédure de déploiement. Détenir le code sans les accès ne rend pas autonome.

La recette est la vérification, par celui qui a commandé, que ce qui est livré fait ce qui avait été demandé. Elle se distingue des tests du développeur, lesquels vérifient que le programme fait ce que son auteur croit avoir écrit. Elle est conduite par des personnes du métier, sur un environnement distinct de la production, avec des données réalistes et des scénarios écrits à l'avance. On y cherche ce qui casse plutôt que ce qui marche : champs vides, textes trop longs, caractères inhabituels, actions simultanées, retour arrière du navigateur. Elle se conclut par une décision écrite et par le tri entre ce qui est une correction et ce qui est une évolution.

Elle recouvre trois activités qu'il vaut mieux distinguer. La correction traite les défauts constatés. L'évolution ajoute ce que l'usage a révélé. Le maintien en condition consiste à mettre à jour les composants dont le site dépend quand 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 et que les services tiers n'ont pas modifié leurs interfaces. C'est cette troisième activité qui répond à la question : un logiciel auquel on ne touche pas ne reste pas stable, parce que tout ce sur quoi il repose continue d'évoluer sans lui.

La lenteur perçue a des causes cumulatives, et il est utile de savoir laquelle domine avant d'agir. Les images non redimensionnées et servies dans un format inadapté sont souvent en cause. Vient ensuite la quantité de code chargée et exécutée avant que la page devienne utilisable, souvent gonflée par des scripts ajoutés au fil du temps sans que personne n'en retire. Puis le temps de réponse du serveur, lié à l'hébergement et aux requêtes faites à la base. Enfin le choix de calculer les pages à l'avance, à la demande, ou dans le navigateur. Ces causes se mesurent, et la mesure se fait sur un appareil et une connexion ordinaires, pas sur le poste du développeur.

L'accessibilité est la propriété d'un site d'être utilisable par des personnes dont les capacités, les outils ou les conditions d'usage diffèrent de ce qu'on imagine par défaut. Concrètement : une structure de page correcte, pour que les technologies d'assistance annoncent ce que sont les éléments ; une utilisation complète au clavier ; un intitulé associé à chaque champ ; un contraste suffisant ; aucune information portée par la seule couleur ; un élément actif toujours visible. Elle sert bien au-delà des situations de handicap, car une connexion mauvaise, un écran en plein soleil ou une main occupée créent les mêmes besoins. Elle se conçoit dès le début : reprise à la fin, elle impose de refaire les composants.

Un site correctement conçu s'adapte aux petits écrans, se met à jour sans intervention de l'utilisateur, s'ouvre depuis un simple lien et ne dépend d'aucune boutique d'applications. Cela couvre l'essentiel des besoins courants. Une application installée se justifie lorsqu'il faut fonctionner sans réseau, accéder à des fonctions de l'appareil que le navigateur n'expose pas ou expose mal, envoyer des notifications de manière fiable, ou soutenir un usage quotidien et intensif. Son coût réel n'est pas sa fabrication mais sa vie : des systèmes distincts à suivre, des publications soumises à validation, des versions anciennes qui restent installées chez les utilisateurs. La question à trancher est l'usage attendu, pas la modernité apparente.

Une interface de programmation est un ensemble d'adresses par lesquelles un programme demande quelque chose à un autre et reçoit une réponse dans un format convenu. Dans un projet web, elle sépare l'interface visible des règles et des données : l'écran demande, le serveur décide et répond. Cette séparation a trois effets pratiques. L'interface peut être refaite sans toucher aux règles. Un autre outil — application interne, application mobile, partenaire — peut être alimenté par les mêmes données. Et les services de tiers, paiement, cartographie, envoi de messages, s'intègrent par le même mécanisme, avec la dépendance que cela suppose : leurs conditions, leur disponibilité et leurs évolutions deviennent les vôtres.

Un site déjà connu des moteurs a accumulé quelque chose d'invisible : des adresses indexées et des liens qui pointent vers elles. Une reconstruction qui change les adresses sans les rediriger perd cet acquis, et le rétablir demande davantage d'efforts que de l'avoir préservé. La précaution consiste à inventorier les adresses existantes avant de commencer, à décider pour chacune l'adresse qui lui succède, et à mettre en place les redirections permanentes au moment de la bascule. Deux vérifications complètent l'opération : retirer les consignes qui empêchaient l'indexation pendant la fabrication, et contrôler que les pages importantes restent atteignables. Le contenu reste le facteur déterminant : une refonte qui l'appauvrit dégrade le résultat quelles que soient les redirections.