U1 · Du besoin aux briques : savoir lire une architecture · Lecture · 14 min
Une architecture fonctionnelle n'est pas un schéma technique. C'est une carte des briques et de ce qui circule entre elles, lisible par un dirigeant de PME. Si Pascal ne peut pas la suivre du doigt en une minute, elle a manqué son but.
Et une précision de périmètre : dans ce module tu conçois l'architecture, tu ne la construis pas. Airtable sera le module 2, Make le module 3, Softr et Webflow le module 5. Ce que tu produis ici est le plan que ces modules exécuteront.
Chez Vermont, la répartition pressentie : une base de données pour le stockage, une interface interne et une interface client, un moteur d'automatisation, et trois canaux d'entrée en intégration. Quels outils précisément — c'est la fiche 7.3.
Où vit la donnée maîtresse ? Chaque information doit avoir un seul endroit où elle fait foi. Si le statut d'un devis existe dans la base et dans un tableur et dans la tête de Sophie, les trois divergeront — c'est exactement le problème du chapitre 2, reproduit avec des outils modernes.
Qui écrit dedans ? Une donnée écrite depuis deux endroits différents finit par se contredire. Idéalement, une source d'écriture par donnée ; sinon, une règle explicite disant qui gagne.
Que se passe-t-il si une brique tombe ? Si le moteur d'automatisation s'arrête un matin, l'entreprise s'arrête-t-elle ? Chez Vermont la réponse doit être non : les gens doivent pouvoir continuer à la main.
C'est le principe le plus important de cette fiche, et le seul qu'il faut retenir si tu n'en retiens qu'un. Une information, un endroit où elle fait foi. Partout ailleurs, elle est affichée, jamais dupliquée.
C'est le même principe que la vue liée de la fiche 2.7 — une fenêtre sur la donnée, pas une copie — appliqué cette fois entre outils différents.