Modèles d’architecture
5 pages
Monolithe, microservices, événementiel, local-first, défense en profondeur : les grands choix et leurs conséquences.
Architecture cyber
Rubrique 02 sur 13
Dossier éditorial prioritaire pour concevoir des architectures sécurisées, explicables et maintenables.
Rubrique · 20 pages · 7 sous-sections
Architecture, conception & résilience
Modélisation de menace
1 page
Raisonner sur qui peut attaquer quoi, et avec quelles garanties, avant d’écrire la première ligne.
Angles de conception oubliés
4 pages
Caches, extensions de navigateur, jetons mobiles et recommandations : les composants qu’on sécurise en dernier.
Résilience
2 pages
Sauvegardes, reprise d’activité, disjoncteurs et cloisons : continuer à fonctionner quand une partie tombe.
Observabilité
2 pages
Journaux, métriques, traces et captures : voir ce que fait réellement un système avant l’incident.
API & intégrations
3 pages
Passerelles d’API, GraphQL et webhooks : les portes d’entrée programmables et les contrôles qu’elles exigent.
Secrets, chiffrement & traces
3 pages
Secrets distribués avec rotation, chiffrement de bout en bout et journaux d’audit qu’on ne peut réécrire.
Par où commencer
- Modèles d’architecture
Choisir une architecture en connaissance de cause
- Modélisation de menace
Penser comme l’attaquant dès la conception
- API & intégrations
Contrôler les portes d’entrée
- Résilience
Prévoir la panne et la reprise
- Observabilité
Voir ce qui se passe vraiment
Parcours qui passent par ici
- Débuter en cybersécurité (2 étapes dans la rubrique)
Architecture cyber
Section intitulée « Architecture cyber »L’essentiel
Section intitulée « Architecture cyber »Une architecture ne s’effondre presque jamais d’un coup. Elle se dégrade décision après décision, et chacune, prise isolément, semble raisonnable : un raccourci pour tenir le sprint, une dépendance ajoutée parce que personne n’a le temps de la challenger, une bascule planifiée un vendredi parce que ça libère le lundi. Rien de tout ça ne déclenche d’alerte. C’est justement le problème. Le jour où ça casse, personne ne pointe la vraie décision fautive : elle date de huit mois, et depuis, tout le monde a oublié qu’elle existait. D’où l’intérêt d’écrire chaque désaccord technique et la décision qui l’a tranché : la mémoire collective a la fiabilité d’un procès-verbal rédigé par le suspect.
→ Lire l’explication complète de la marmotte
Le sujet, ici, ce n’est pas la liste des bonnes pratiques qu’on connaît déjà et qu’on n’applique jamais faute de temps. C’est la mécanique : pourquoi la segmentation dessinée sur un schéma ne survit jamais à la première demande d’exception, pourquoi la confiance accordée entre deux composants finit toujours plus large que prévu, et pourquoi un système qu’on n’observe pas se défend en réalité à l’aveugle : on croit juste le contraire, parce que rien ne clignote.
La résilience suit la même logique : un système qui ne sait pas dégrader proprement ne « tient » pas plus longtemps, il casse juste d’un coup plutôt qu’en plusieurs fois, et personne n’a le temps de réagir entre les deux. Défendre un système par sa surface d’attaque, l’observer avant l’incident plutôt qu’en découvrir les traces après, construire quelque chose qui tient, dégrade puis redémarre : c’est le même réflexe appliqué trois fois, pas trois compétences séparées.
Le reste (événementiel, monolithe contre microservices, la manière dont le code est organisé) n’est pas hors sujet : c’est la même question posée plus tôt dans le cycle, avant que l’architecture ne devienne l’excuse qu’on invoque pour ne plus la remettre en cause.
🐝 Ce qui arrive si on s’en passe
Section intitulée « 🐝 Ce qui arrive si on s’en passe »Une organisation qui néglige l’architecture ne s’en aperçoit pas : chaque exception accordée reste ouverte, chaque confiance entre composants s’élargit sans que personne ne la réévalue, et l’ensemble finit par autoriser des chemins que personne n’a jamais décidés. Un attaquant qui compromet un seul composant hérite alors de tous ces droits accumulés et circule d’une zone à l’autre sans rencontrer de cloison. Faute d’observation, l’intrusion ne produit aucun signal, et l’enquête qui suit ne retrouve ni le chemin emprunté ni la décision d’origine, vieille de plusieurs mois. Quand une panne survient, l’absence de mode dégradé transforme l’incident local en arrêt complet ; la reprise, jamais conçue, s’improvise alors en pleine crise, ce qui reste la méthode la plus coûteuse connue à ce jour.
🦫 Explication de la marmotte 🍫
Section intitulée « 🦫 Explication de la marmotte 🍫 »Un système informatique est fait de nombreux morceaux qui communiquent entre eux : des serveurs, des programmes, des bases de données. Son architecture, c’est la façon dont ces morceaux sont découpés, reliés et autorisés à se parler. Cette rubrique explique pourquoi cette organisation s’abîme avec le temps. Chaque décision rapide (ajouter une dépendance sans l’examiner, accorder une exception pour qu’un service en joigne un autre, programmer une bascule au mauvais moment) semble sans danger prise seule. Ces décisions s’additionnent pourtant, et personne ne garde la trace de celle qui a créé la faiblesse. La rubrique suit trois réflexes liés. D’abord, réduire la surface d’attaque, c’est-à-dire le nombre de points d’entrée qu’un attaquant peut utiliser, et garder des zones séparées malgré les demandes d’exception. Ensuite, observer le système en continu, pour voir un problème pendant qu’il se produit et pas seulement ses traces après coup. Enfin, prévoir comment le système continue de fonctionner en mode réduit quand une partie tombe, puis comment il redémarre. Un système qui ne sait pas perdre une fonction à la fois s’arrête d’un bloc, sans laisser le temps de réagir. Les choix d’organisation du code, par exemple construire une application d’un seul tenant ou en petits services séparés, relèvent de la même question, posée plus tôt.