Architecture logicielle

L'architecture logicielle, c'est l'ensemble des grandes décisions qui donnent sa forme à un logiciel. Comment il est découpé en parties, comment ces parties s'échangent des informations, où sont rangées les données et ce qui se passe quand quelque chose tombe en panne. C'est le plan de la maison, pas la couleur des murs.

Vous êtes concerné dès que vous payez un logiciel, choisissez une plateforme ou confiez à quelqu'un la création d'une boutique, d'une application ou d'un outil interne. Inutile de dessiner les schémas vous-même. Il suffit d'en comprendre assez pour poser les bonnes questions, car l'architecture décide de la vitesse à laquelle votre produit peut évoluer, de ce qu'il coûte à faire tourner et de sa tenue un jour de forte affluence.

Qu'est-ce que l'architecture logicielle ?

L'architecture logicielle désigne la structure d'un système et le raisonnement qui la justifie. Une définition pratique : l'architecture regroupe les décisions qui coûtent cher à défaire. La couleur d'un bouton n'en fait pas partie. Savoir si votre catalogue, vos commandes et vos clients vivent dans une seule base de données ou dans cinq, si.

Ces décisions portent presque toujours sur les mêmes sujets :

• Le découpage : en quels modules ou services le logiciel est divisé, et de quoi chacun est responsable.
• La communication : comment les parties se parlent, par appel direct, par requête réseau vers une API, ou par messages et événements.
• Les données : quelle partie possède quelle donnée, comment elle est stockée, sauvegardée et gardée cohérente.
• Les qualités attendues : les objectifs non fonctionnels comme la rapidité, la disponibilité, la sécurité, le coût et la facilité d'évolution.
• Le déploiement : où le logiciel s'exécute et comment les nouvelles versions arrivent aux utilisateurs.

L'architecture n'est pas la qualité du code. On peut avoir un code propre dans une structure qui ne colle pas au métier, et l'inverse. Ce n'est pas non plus le choix du langage ou du framework, même si ces choix en découlent souvent.

Vous croiserez un vocabulaire voisin. Un monolithe est un système déployé d'un seul bloc. Les microservices le découpent en petits services déployés séparément. La clean architecture est une façon d'organiser le code pour que les règles métier ne dépendent pas des outils. Un style d'architecture est une famille de solutions, votre architecture est la structure précise de votre système.

Pourquoi c'est important

L'architecture se transforme en argent par trois canaux : le coût de chaque évolution future, le coût d'exploitation et le coût des pannes.

Prenons une marque de cosmétiques qui traite 800 commandes par mois avec un panier moyen de 42 €. Elle paie un freelance 6 000 € pour développer une boutique sur mesure. Pour aller vite, le développeur stocke les quantités à deux endroits, l'un pour le site, l'autre pour un formulaire de vente aux revendeurs, synchronisés par un script toutes les heures. En démonstration, tout fonctionne.

Six mois plus tard, un produit fait le buzz. En une heure, 120 commandes arrivent sur un sérum dont il reste 60 unités. Les deux parties du système pensent avoir du stock. La marque survend 60 unités, les rembourse, perd environ 250 € de frais de paiement non restitués et répond à 60 emails mécontents. Puis elle paie 2 200 € au développeur pour revoir la gestion du stock, ce qui touche le checkout, la liste des commandes et le formulaire revendeurs. L'économie de départ représentait peut-être deux jours de travail.

C'est toujours le même mécanisme. Un raccourci de structure ne coûte rien le premier jour et se paie avec intérêts plus tard. Ces intérêts portent un nom, la dette technique. Une bonne architecture ne supprime pas cette dette. Elle vous la fait contracter en connaissance de cause, là où elle est facile à rembourser.

Comment ça marche

Le travail d'architecture est une suite d'arbitrages, pas un modèle à recopier. Une démarche saine ressemble à ceci :

• Partir du métier. Listez ce que le système doit faire et surtout ce qui ne doit jamais mal tourner. Pour une boutique, encaisser deux fois ou vendre un stock inexistant est bien pire qu'une page produit un peu lente.
• Classer les qualités attendues. On ne peut pas tout maximiser. Une créatrice qui lance une formation tient davantage à un checkout fiable le jour du lancement qu'à la capacité de gérer un million de produits.
• Tracer les frontières. Regroupez ce qui change ensemble, séparez ce qui change pour des raisons différentes. Paiement, catalogue, contenu et emails n'évoluent pas au même rythme.
• Attribuer chaque donnée. Un seul endroit fait foi pour le stock, un pour les commandes, un pour les clients. Les copies sont permises, la propriété ne se partage pas.
• Choisir le mode d'échange. Les appels directs sont simples et immédiats. Les événements sont plus souples et plus résistants, au prix de pièces supplémentaires.
• Écrire les décisions. Une courte note par décision, avec les options étudiées et la raison du choix, fait gagner des semaines quand quelqu'un de nouveau arrive.
• Y revenir. Une architecture n'est pas figée. Quand le trafic, l'équipe ou le produit changent, certaines décisions méritent d'être réexaminées.

Repères et exemples

Il n'existe pas de note universelle pour une architecture, mais quelques repères réalistes.

• Une créatrice seule ou une petite boutique (jusqu'à quelques milliers de commandes par mois) n'a presque jamais besoin d'une architecture sur mesure. Une plateforme hébergée, un SaaS, a déjà pris ces décisions et en répartit le coût entre des milliers de marchands.
• Une marque aux besoins spécifiques, avec un budget de 5 000 à 30 000 €, s'en sort généralement mieux avec une seule application bien organisée, une base de données et des modules clairs. Plus sophistiqué, à ce budget, la structure finit par manger le budget.
• Une entreprise avec plusieurs équipes produit de 20 développeurs ou plus commence à gagner à découper le système, parce que les équipes arrêtent de s'attendre.

Quelques signaux utiles. Dans un système sain, une petite modification, comme l'ajout d'un champ sur un produit, part en production en un ou deux jours. Si une petite modification prend régulièrement deux semaines et casse quelque chose sans rapport, l'architecture se bat contre le métier. Les plateformes e-commerce hébergées visent couramment 99,9 % de disponibilité ou plus, ce qui laisse encore environ 43 minutes d'interruption par mois. Un système maison sur un petit serveur fait souvent moins bien, sans que personne ne s'en aperçoive avant les soldes.

Erreurs fréquentes

• Copier les géants du web. Reprendre la structure d'une entreprise de 2 000 ingénieurs quand vous avez un freelance multiplie les coûts sans rien apporter.
• Ne rien décider. « On verra plus tard » est une décision, souvent la plus chère. La propriété des données, en particulier, se corrige mal après coup.
• Dupliquer la source de vérité. Deux endroits qui gardent le stock ou les prix finiront par se contredire. La question est quand, pas si.
• Oublier l'exploitation. Une architecture que personne dans l'équipe ne sait surveiller, mettre à jour ou restaurer depuis une sauvegarde est un risque, aussi élégant que soit le schéma.
• La traiter comme un livrable unique. La structure qui convient à 50 commandes par mois ne convient pas forcément à 5 000.

Bonnes pratiques

• Demandez le schéma. Avant de signer avec une agence, demandez un dessin d'une page avec les grandes parties, les données et les services externes. Si elle ne peut pas le produire, elle n'y a pas réfléchi.
• Nommez l'intouchable. Écrivez à votre développeur ce qui ne doit jamais échouer, par exemple « ne jamais vendre un stock absent » ou « le checkout fonctionne en 4G ».
• Préférez les technologies éprouvées. Des outils connus, c'est plus de gens capables de les maintenir, plus de documentation et moins de surprises.
• Une seule source de vérité par type de donnée. Stock, prix, commandes et clients vivent chacun à un seul endroit, lu par tous les canaux.
• Prévoyez la sortie. Demandez comment exporter vos produits, clients et commandes si vous partez. La dépendance à un prestataire est une propriété de l'architecture.
• Budgétez la maintenance. Comptez environ 15 à 20 % du coût de développement par an pour les mises à jour, les correctifs de sécurité et les petites corrections.
• Achetez avant de construire. Le sur-mesure est rentable là où vous êtes vraiment différent. Pour les briques standard comme le checkout et l'hébergement, une plateforme revient généralement moins cher et plus sûr.

Dans Roctify

Roctify est un SaaS : les décisions d'architecture liées à l'hébergement, au checkout, aux paiements et à la sécurité sont prises et entretenues pour vous. Roctify héberge votre boutique, la tient à jour et sert chaque page en HTTPS avec un certificat SSL gratuit. Vous ne choisissez ni serveurs, ni bases de données, ni chaîne de déploiement, et vous ne payez pas un développeur pour les corriger.

Le choix d'architecture le plus visible pour vous, c'est le catalogue partagé. Produits, variantes, SKU, stock, prix, clients et commandes vivent au même endroit, partagé par votre page lien en bio et votre boutique en ligne, et le stock se met à jour partout à la fois. C'est le principe de la source de vérité unique, appliqué sans que vous ayez à le construire. Si vous avez besoin d'intégrations au-delà des fonctionnalités incluses, elles se discutent dans le plan Enterprise.

FAQ

Faut-il comprendre l'architecture logicielle pour vendre en ligne ?

Pas en détail. Sur une plateforme hébergée, l'architecture fait partie de ce que vous payez. Elle devient importante quand vous commandez un logiciel sur mesure, car vous devez juger si la proposition correspond à votre taille et à votre budget.

Qui s'occupe de l'architecture dans un petit projet ?

En général le développeur principal ou le responsable technique de l'agence. Sur un projet en freelance, c'est souvent le freelance seul. Demandez-lui d'expliquer ses grands choix avec des mots simples, et méfiez-vous si chaque réponse est « tout le monde fait comme ça ».

Une bonne architecture, est-ce utiliser les dernières technologies ?

Non. Une bonne architecture est adaptée au problème, à l'équipe et au budget. Cela veut souvent dire des outils éprouvés, parfois démodés, agencés simplement. Une technologie récente se paie en apprentissage et en risque, et elle doit vous apporter quelque chose de précis en échange.