Concevoir l'architecture d'une application selon des contraintes spécifiques
Savoir-faire élémentaires
- déduire une architecture à partir des contraintes du projet
- anticiper l'absence de maintenance dans les choix techniques
- réduire la surface de sécurité (application locale)
- maîtriser le risque des dépendances externes
Descriptif général
La Trace 1 est le schéma d'architecture que j'ai réalisé pour le projet. Il présente les deux briques du système : le site WooCommerce hébergé chez o2switch, qui expose une API REST, et le tableau de bord de gestion, une application de bureau installée localement chez le gérant, qui consomme cette API. Les zones encadrées signalent, pour chaque brique, le choix retenu et la contrainte qui l'a motivé.
Cette trace est au cœur du sujet. Avant d'écrire la moindre ligne, il fallait décider comment articuler la boutique en ligne et son outil de gestion, dans un contexte soumis à des contraintes inhabituelles.
Les savoir-faire mis en œuvre
déduire une architecture à partir des contraintes du projet
Le stage posait des contraintes inhabituelles, qu'il fallait cerner avant tout choix technique. J'étais seul sur le projet et personne ne reprendrait le code après mon départ : tout devait tenir sans développeur pour le maintenir. Dans le même esprit, rien ne garantissait le suivi des mises à jour de sécurité dans la durée. Enfin, l'outil de gestion serait utilisé au quotidien par le gérant, qui n'est pas technicien. De ces contraintes j'ai déduit la structure, au lieu de partir d'une stack par habitude : un site bâti sur WooCommerce qui expose son API REST, et un tableau de bord local, volontairement simple, qui consomme cette API. C'est ce que montre la Trace 1, et chacun des choix détaillés ensuite en découle.
anticiper l'absence de maintenance dans les choix techniques
Face à cette absence de maintenance, je me suis appuyé sur le cœur de WordPress et WooCommerce et sur leur API REST native. J'aurais pu écrire mes propres endpoints sur le serveur, et c'était tentant : cela m'aurait permis de gérer des transactions et des retours arrière côté serveur, donc des opérations plus sûres. Mais ce code maison serait resté à maintenir, sans personne pour le faire. J'ai pesé le pour et le contre, et préféré du natif que je n'ai pas à entretenir, quitte à perdre un peu en finesse. Forcément, l'absence de transactions et de retours arrière, j'ai dû la gérer côté client. Ce n'est pas idéal, mais c'était la seule solution viable compte tenu de la contrainte de maintenance. Sur la Trace 1, le repère « API stables » renvoie à ce choix.
réduire la surface de sécurité (application locale)
Le tableau de bord est une application installée sur le poste du gérant, pas un service en ligne. Il réutilise l'API du site au lieu d'ajouter un nouveau point d'entrée à sécuriser. Il n'y a donc rien de plus à protéger en ligne (repère « pas d'authentification en ligne »), et les identifiants restent dans le trousseau du système (repère « OS Keychain »). C'est autant de surface en moins à surveiller, ce qui compte quand les mises à jour de sécurité ne sont pas garanties dans le temps.
maîtriser le risque des dépendances externes
Avoir zéro dépendance, c'est impossible. Le tableau de bord s'appuie sur des librairies Rust et JavaScript, et le site sur des extensions WordPress : ces briques techniques sont incontournables. J'ai donc essayé d'en avoir le moins possible et de ne garder que le fiable. Quand WordPress ou WooCommerce sait déjà faire quelque chose, je m'en sers plutôt que d'installer un plugin. Le risque de sécurité reste de toute façon limité, parce que l'application tourne en local et n'est pas exposée en ligne. Quant aux services externes de l'architecture, ce sont des outils très répandus aux adresses stables (paiement CAWL, transporteurs Mondial Relay et Chronopost, consoles Google), donc peu susceptibles de changer du jour au lendemain. C'est ce que pointe le repère « URLs stables » de la Trace 1. Au final, des dépendances il y en a, mais elles restent réduites, plutôt stables, et choisies en conscience.