France Crashes 39-45 - Module mobile et API de recherche

Contexte

Le site France Crashes 39-45 recense les avions tombés sur le territoire français pendant la Seconde Guerre mondiale : fiches d'appareils, équipages, circonstances des crashs. En ligne depuis 2008 et enrichi sans interruption depuis, c'est une base documentaire de référence, consultée par des familles, des historiens et des passionnés d'aviation.

Devant une tombe d'aviateur dans un cimetière, le besoin n'est pas le même que derrière un ordinateur : il faut retrouver en quelques secondes, depuis un téléphone, à quel avion et à quel équipage appartenait le nom lu sur la stèle. La mission consistait à livrer ce module mobile, branché sur la base existante, sans toucher au site principal.

Problème & objectifs

Problème

• Le site principal tourne sur PHP 5.2 depuis 2008 et n'est pas responsive : sur un téléphone, il faut zoomer et faire défiler dans tous les sens pour lire quoi que ce soit
• Toucher à cet existant, c'était risquer de casser un site en ligne depuis près de vingt ans : le client ne voulait prendre aucun risque, et il avait raison
• Hébergement mutualisé imposé : pas de Composer, aucune dépendance externe, aucune extension PHP à installer, dépôt par FTP
• La base ne contient aucun identifiant unique d'aviateur, et ses champs texte embarquent du HTML hérité du site (liens, infobulles, images) inaffichable tel quel

Objectifs

• Permettre de retrouver un aviateur à partir du seul nom lu sur une tombe, avec le prénom ou une simple initiale
• Appliquer la règle métier du client : jamais de fiche aviateur seule, toujours l'avion et l'équipage complet
• Exposer une API sécurisée (clé d'accès, limitation de débit, requêtes préparées) alimentant le module mobile
• Rester dans la continuité visuelle du site de 2008, pour un public souvent âgé qui connaît déjà ses repères, plutôt que d'imposer une interface moderne dépaysante
• Rendre l'ensemble configurable sans toucher au code, pour basculer de la base de test à la base de production
• Rediriger les visiteurs mobiles du site principal vers le module, de façon totalement réversible

Approche

Le cahier des charges imposait un module autonome : je l'ai traité comme une brique greffée sur la base existante, retirable à tout moment.

• analyse de la base réelle avant toute ligne de code : la structure documentée et la structure livrée différaient, chaque adaptation a été soumise au client puis validée ;
• parti pris d'interface assumé avec le client : reprendre les codes visuels du site d'origine (bandeau, fond de ciel, palette) au lieu d'un habillage moderne, avec de gros libellés, des contrastes marqués et une seule action par écran ;
• conception d'une API PHP 8.2 sans aucune dépendance externe, pour rester compatible avec l'hébergement du client et son déploiement par FTP ;
• construction d'un identifiant technique d'aviateur, la base n'en fournissant aucun, à partir de la fiche avion et du rang dans l'équipage ;
• nettoyage systématique des champs texte hérités du site : suppression des images et des infobulles, conservation du texte visible ;
• interface mobile en JavaScript natif, en trois vues (recherche, résultats, fiche), sans framework ni étape de build ;
• script de détection d'appareil isolé, ajouté en une ligne sur le site principal, sans toucher ni au HTML ni au CSS existants.

Chaque écart avec le cahier des charges initial a été arbitré avec le client, puis documenté dans le dépôt livré.

Points techniques

Résultats

Le module en ligne propose :

• une recherche par nom de famille, avec prénom ou simple initiale, qui renvoie les aviateurs correspondants avec leur unité et leur lieu d'inhumation ;
• une fiche associant l'appareil (nation, date du crash, type, matricule, unité, mission, lieu de chute, circonstances) et l'intégralité de l'équipage avec grade, poste, état et lieu d'inhumation ;
• un lien direct vers la fiche détaillée du site principal, pour prolonger la consultation ;
• une redirection automatique des smartphones et tablettes depuis le site principal, avec une échappatoire pour rester sur le site complet ;
• une suite de tests couvrant les correspondances d'état, le nettoyage des champs hérités et l'encodage des identifiants, complétée par une recette sur la base réelle.

Le module tourne sur son propre sous-domaine sans qu'aucune ligne du site principal ait été modifiée : retirer une seule balise script suffirait à tout annuler.

Ce que j'ai appris

• travailler sur une base de données existante que je n'avais pas conçue, et m'adapter à sa structure réelle plutôt qu'à sa documentation ;
• livrer une API sécurisée sans aucune dépendance externe, contrainte imposée par l'hébergement mutualisé du client ;
• implémenter une limitation de débit portable, à base de fichiers verrouillés, là où les solutions habituelles supposent Redis ou une extension dédiée ;
• concevoir une intégration réversible, qui laisse le site du client intact et ne coûte rien à retirer ;
• faire passer le besoin réel avant mes réflexes de développeur : la bonne interface était ici celle que les visiteurs reconnaissent, pas la plus moderne ;
• arbitrer avec un client non technique des questions de structure de données, et documenter chaque écart validé.

Cette mission a confirmé deux choses : une contrainte technique forte n'empêche pas de livrer quelque chose de propre et sécurisé, et un site qui tourne depuis 2008 se modernise mieux par ajout que par réécriture.

Liens