# Be Software Architecture Wise

> Un cours en ligne complet d’architecture logicielle, à suivre à votre rythme, proposé par Be Wise (bewiseapps.com) : treize chapitres et 104 sections, du fonctionnement des logiciels à l’architecture des systèmes intégrant l’IA. Chaque chapitre a une introduction vidéo narrée et chaque section une courte leçon vidéo narrée, avec des sous-titres et une transcription. Des tests de chapitre facultatifs, un examen final et une étude de cas d’architecture mènent à un Certificat de fin de formation Be Wise (non accrédité). Rédigé en français ; les vidéos sont narrées en anglais, avec des sous-titres en français. Informations pédagogiques, et non conseils professionnels.

## À propos du cours

- **Qu’est-ce que Be Software Architecture Wise ?** Un cours en ligne complet d’architecture logicielle, en 13 chapitres et 104 sections, avec 117 leçons vidéo narrées, du fonctionnement des logiciels à l’architecture des systèmes intégrant l’IA, avec des tests de chapitre facultatifs, une évaluation finale et une étude de cas, et un Certificat de fin de formation Be Wise vérifiable.
- **À qui s’adresse le cours ?** Les débutants sans formation technique, les développeurs qui évoluent vers des postes de senior, de lead ou d’architecte, les architectes expérimentés qui souhaitent une remise à niveau structurée, les responsables d’ingénierie et de produit, les ingénieurs en IA et les étudiants.
- **De quoi ai-je besoin avant de commencer ?** Aucune connaissance préalable : simplement un téléphone, une tablette ou un ordinateur avec un navigateur web récent, une connexion internet pour les tests et ArchitectBot, et une aisance suffisante pour lire le français (les vidéos sont narrées en anglais, avec des sous-titres en français).
- **Que couvre le cours ?** Treize chapitres : le fonctionnement des logiciels ; ce qu’est l’architecture ; les attributs de qualité ; les principes de conception ; la documentation de l’architecture ; les styles monolithiques et la conception pilotée par le domaine ; les systèmes distribués ; l’architecture des données ; la sécurité, la confidentialité et la conformité ; les performances, la résilience et l’exploitabilité ; l’infrastructure cloud native ; l’évaluation et la gouvernance ; et les systèmes intégrant l’IA.
- **Comment le cours est-il organisé, et combien de temps demande-t-il ?** Chaque chapitre comprend une introduction vidéo narrée, une vue d’ensemble et huit sections, chacune avec une leçon vidéo narrée, une explication simple, les points clés, le développement complet avec des diagrammes et des exemples commentés, des questions d’autoévaluation et des sources. Environ 40 heures de lecture, et environ 60 heures au total avec les tests et l’étude de cas, entièrement à votre rythme. Les 117 leçons vidéo durent environ 10 heures au total.
- **Comment fonctionnent les tests de chapitre ?** Chaque test de chapitre comporte 20 questions à choix multiples tirées d’une banque de 64 et 2 réponses rédigées, corrigées par une IA selon des critères publiés. Les QCM comptent pour 70 % et les réponses rédigées pour 30 %. La note de réussite est de 80 % au total, avec au moins 2 sur 5 à chaque réponse rédigée. Nouvelles tentatives illimitées après 10 minutes, avec des questions différentes.
- **Qu’est-ce que l’évaluation finale ?** Après la réussite des 13 tests de chapitre : un examen final de 60 questions (note de réussite : 70 %) et une étude de cas d’architecture rédigée de 1500 à 4000 mots, notée sur 50 selon une grille d’évaluation publiée en cinq parties (note de réussite : 25).
- **Comment le résultat final est-il calculé ?** Note globale = 40 % de la moyenne des meilleures notes aux tests de chapitre + 30 % de l’examen final + 30 % de l’étude de cas. Mention très bien : 90 ou plus au total et au moins 80 % à l’étude de cas. Mention bien : 80 ou plus. Admis : toutes les parties réussies.
- **Que montre le certificat, et comment peut-on le vérifier ?** Un Certificat de fin de formation Be Wise indiquant votre nom, la date, votre résultat (Admis, Mention bien ou Mention très bien) et un numéro unique que chacun peut vérifier en ligne.
- **Le certificat est-il une qualification accréditée ?** Non. Il atteste que vous avez suivi ce cours jusqu’au bout et réussi ses évaluations. Il n’est pas accrédité, ne donne droit à aucun crédit universitaire et n’est délivré ni approuvé par aucune université, aucun organisme professionnel ni aucun programme de certification.
- **Que deviennent mes données ?** Aucun compte n’est nécessaire. La progression de lecture reste dans votre navigateur ; les notes des tests sont conservées sous un code de reprise aléatoire, sans aucune donnée personnelle ; votre nom n’est enregistré que si vous demandez un certificat, afin qu’il puisse être vérifié.
- **Qu’est-ce qu’ArchitectBot ?** L’assistant d’étude IA du cours. Il répond d’abord à partir du cours et cherche sur le web les informations plus récentes. Il peut se tromper et ne répondra pas aux questions des tests à votre place.
- **Comment le contenu est-il maintenu exact et à jour ?** Chaque chapitre est vérifié par rapport aux sources qu’il cite avant sa publication, les sources sont indiquées dans chaque section, les chapitres sont mis à jour à mesure que les pratiques évoluent, et les erreurs peuvent être signalées.
- **Quels appareils puis-je utiliser, et le cours est-il accessible ?** Téléphones, tablettes et ordinateurs, dans tout navigateur à jour ; installable comme une application ; chaque chapitre existe aussi sous forme de pages web et de PDF ; chaque vidéo est narrée en anglais et dispose de sous-titres en français et en anglais, d’une option audio seule et d’une transcription ; les diagrammes ont des descriptions textuelles.
- **Ce que le cours n’est pas** Il s’agit d’informations pédagogiques, et non de conseils professionnels ; ce n’est ni une qualification accréditée ni une préparation à un examen ; il n’est affilié à aucune université ni à aucun organisme de certification ; ce n’est pas un cours de programmation ; et il ne comporte pas d’enseignement en direct, même si chaque chapitre et chaque section disposent d’une leçon vidéo narrée.
- **Combien cela coûte-t-il ?** Actuellement, l’ensemble du cours est gratuit : chaque chapitre, les tests de chapitre, ArchitectBot, l’évaluation finale et le certificat. Si cela change, le prix et ce qu’il comprend exactement seront indiqués sur cette page avant que vous ne commenciez quoi que ce soit de payant.
- Plus d’informations : https://bewiseapps.com/fr/software-architecture-wise/about-the-course

## Chapitres et sections

### [Chapitre 0 : Pour commencer : comment fonctionne un logiciel](https://bewiseapps.com/fr/software-architecture-wise/foundations/)
Débutant. Les bases de tout ce qui suit : ce qu’est un programme, comment les données et le code sont organisés, comment les ordinateurs communiquent sur les réseaux, où les données sont stockées, ce que sont les API, les serveurs et le cloud, et comment les équipes construisent les logiciels. Aucune connaissance préalable n’est requise.

- [0.1 Programmes, code et exécution par l’ordinateur](https://bewiseapps.com/fr/software-architecture-wise/foundations/what-software-is): Ce que sont le matériel et le logiciel, comment le code source devient des instructions qu’un processeur peut exécuter, ce que fait le système d’exploitation et ce qui se passe réellement, étape par étape, quand un petit programme Python s’exécute.
- [0.2 Données, structures de données et algorithmes, et pourquoi la vitesse en dépend](https://bewiseapps.com/fr/software-architecture-wise/foundations/data-and-algorithms): Comment les ordinateurs représentent les nombres et le texte, les structures de données courantes (listes, dictionnaires, files, arbres, graphes), ce qu’est un algorithme et comment la notation grand O explique pourquoi certains systèmes ralentissent quand le volume de données augmente.
- [0.3 Fonctions, modules, objets, interfaces, bibliothèques et frameworks](https://bewiseapps.com/fr/software-architecture-wise/foundations/organising-code): Comment les programmeurs découpent le code en fonctions, modules, objets et interfaces ; la différence entre une bibliothèque et un framework ; les avantages et les risques des dépendances ; et un premier aperçu du couplage et de la cohésion.
- [0.4 Réseaux, internet et web : IP, DNS, HTTP et le modèle client-serveur](https://bewiseapps.com/fr/software-architecture-wise/foundations/how-computers-talk): Comment les données traversent internet en paquets, à quoi servent les adresses IP, les ports, TCP, UDP et le DNS, comment fonctionnent les requêtes HTTP et HTTPS, pourquoi la latence a un plancher fixé par la physique et ce qui se passe quand vous tapez une adresse web.
- [0.5 Fichiers et bases de données : stockage relationnel et non relationnel, requêtes et transactions](https://bewiseapps.com/fr/software-architecture-wise/foundations/storing-data): Pourquoi les systèmes ont besoin de bases de données plutôt que de simples fichiers, comment fonctionnent les tables relationnelles, les clés, SQL, les index et les transactions ACID, les principales familles NoSQL et pourquoi les sauvegardes doivent être testées.
- [0.6 API, JSON et coopération entre systèmes distincts](https://bewiseapps.com/fr/software-architecture-wise/foundations/apis-and-integration): Ce qu’est une API et pourquoi c’est un contrat, comment les API REST utilisent les URL, les verbes HTTP, les codes d’état et JSON, et comment les clés, les webhooks, les files, les versions et les limites de débit façonnent l’intégration.
- [0.7 Serveurs, systèmes d’exploitation, machines virtuelles, conteneurs et services cloud](https://bewiseapps.com/fr/software-architecture-wise/foundations/servers-and-the-cloud): Ce que sont les serveurs et les centres de données, comment les machines virtuelles et les conteneurs partagent le matériel, ce que l’IaaS, le PaaS, le SaaS et le serverless confient au fournisseur, et comment s’articulent régions, zones, CDN et mise à l’échelle.
- [0.8 Exigences, gestion de versions, tests, livraison et parcours d’une requête](https://bewiseapps.com/fr/software-architecture-wise/foundations/how-software-gets-built): Comment les équipes transforment des besoins en récits utilisateur, collaborent avec Git et les pull requests, testent à plusieurs niveaux, livrent grâce au CI/CD et aux environnements, et comment un simple appui dans une app de livraison de repas traverse chaque partie d’un système.

### [Chapitre 1 : Qu’est-ce que l’architecture logicielle ?](https://bewiseapps.com/fr/software-architecture-wise/what-is-architecture/)
Débutant à intermédiaire. Les définitions qui comptent (ISO/IEC/IEEE 42010 et le SEI), ce qui distingue l’architecture de la conception, pourquoi elle détermine les coûts et les risques, ce que font réellement les architectes, les parties prenantes, les compromis, la dette technique et la place de l’architecture dans les méthodes de livraison modernes.

- [1.1 Ce qu’est l’architecture logicielle : les définitions de référence et leurs points communs](https://bewiseapps.com/fr/software-architecture-wise/what-is-architecture/defining-architecture): La norme internationale, le SEI et des praticiens de premier plan définissent l’architecture logicielle de manières différentes. Découvrez les principales définitions, ce qu’elles ont en commun et les trois types de structures que possède tout système.
- [1.2 Architecture, conception et code : importance, portée et niveaux](https://bewiseapps.com/fr/software-architecture-wise/what-is-architecture/architecture-vs-design): L’architecture et la conception forment un même continuum de décisions. Découvrez ce qui rend une décision architecturalement significative, ce qui distingue les décisions stratégiques des décisions tactiques, et comment s’articulent l’architecture d’entreprise, l’architecture de solution et l’architecture logicielle.
- [1.3 Pourquoi l’architecture compte : coût du changement, qualité, risques et échecs réels](https://bewiseapps.com/fr/software-architecture-wise/what-is-architecture/why-architecture-matters): L’architecture détermine les qualités d’un système, le coût et la rapidité de chaque changement futur, ses risques et la façon dont les équipes peuvent travailler. Des cas réels, chez Knight Capital, HealthCare.gov et Prime Video, montrent pourquoi.
- [1.4 Ce que fait un architecte : responsabilités, compétences et types d’architectes](https://bewiseapps.com/fr/software-architecture-wise/what-is-architecture/the-architect-role): Ce que font réellement les architectes au quotidien, les huit attentes décrites par Richards et Ford, les types d’architectes, l’étendue face à la profondeur, et la question de savoir si les architectes doivent encore écrire du code.
- [1.5 Les parties prenantes, leurs préoccupations et comment l’architecture y répond](https://bewiseapps.com/fr/software-architecture-wise/what-is-architecture/stakeholders-and-concerns): Qui a un intérêt dans un système, ce que l’ISO/IEC/IEEE 42010 entend par préoccupation, comment cartographier et impliquer les parties prenantes, et comment des préoccupations contradictoires deviennent des exigences, des décisions et des vues explicites.
- [1.6 Décisions architecturales et compromis : réversibilité et moment opportun](https://bewiseapps.com/fr/software-architecture-wise/what-is-architecture/decisions-and-trade-offs): Pourquoi chaque choix architectural est un compromis, comment structurer une décision bien formulée, les portes à sens unique et à double sens, le dernier moment responsable, la conception pour la réversibilité, les pièges cognitifs et la matrice de décision pondérée.
- [1.7 Dette technique, érosion et dérive de l’architecture](https://bewiseapps.com/fr/software-architecture-wise/what-is-architecture/technical-debt): Ce que voulait vraiment dire la métaphore de la dette de Ward Cunningham, le principal et les intérêts, le quadrant de la dette de Fowler, pourquoi la dette architecturale coûte le plus cher, l’érosion et la dérive, et comment détecter, gérer et expliquer la dette en termes métier.
- [1.8 L’architecture tout au long du cycle de vie : en amont, émergente et continue](https://bewiseapps.com/fr/software-architecture-wise/what-is-architecture/architecture-in-the-lifecycle): La conception complète en amont (big design up front) face à la conception émergente, ce que dit réellement le Manifeste agile, le modèle piloté par les risques de Fairbanks, l’architecture intentionnelle et la piste architecturale, l’architecture continue, les squelettes ambulants, les spikes et l’architecture dans le DevOps.

### [Chapitre 2 : Attributs de qualité et exigences architecturalement significatives](https://bewiseapps.com/fr/software-architecture-wise/quality-attributes/)
Intermédiaire. Comment transformer des souhaits vagues comme « rapide » et « sécurisé » en exigences précises et testables : ISO/IEC 25010, scénarios d’attributs de qualité, performances, disponibilité, modifiabilité, sécurité et utilisabilité, et comment les éliciter, les hiérarchiser et arbitrer entre eux.

- [2.1 Exigences fonctionnelles, attributs de qualité et contraintes](https://bewiseapps.com/fr/software-architecture-wise/quality-attributes/functional-vs-quality): Ce qu’un système doit faire, avec quel niveau de qualité, et quels choix sont déjà arrêtés. Apprenez à repérer les exigences architecturalement significatives qui déterminent réellement une conception.
- [2.2 Les modèles de qualité : l’ISO/IEC 25010 et comment l’utiliser](https://bewiseapps.com/fr/software-architecture-wise/quality-attributes/the-quality-models): Le modèle de qualité des produits de l’ISO/IEC 25010:2023 et ses neuf caractéristiques, ce qui a changé depuis 2011, d’autres listes comme FURPS+, et comment utiliser un modèle comme liste de contrôle sans se noyer dans la paperasse.
- [2.3 Rédiger des scénarios d’attributs de qualité testables](https://bewiseapps.com/fr/software-architecture-wise/quality-attributes/quality-attribute-scenarios): Le scénario en six parties qui transforme « rapide », « sécurisé » et « facile à modifier » en exigences testables, avec des exemples pour six qualités, les erreurs courantes et le chemin qui mène du scénario à la fonction d’aptitude.
- [2.4 Performances et scalabilité : latence, débit, percentiles et charge](https://bewiseapps.com/fr/software-architecture-wise/quality-attributes/performance-and-scalability): La latence et le débit, les percentiles et la latence de queue, la loi de Little, les files d’attente et le seuil critique du taux d’utilisation, la loi d’Amdahl et la loi universelle de scalabilité, avec des calculs commentés et un panorama des tactiques de performance.
- [2.5 Disponibilité et fiabilité : « neuf », MTBF, MTTR et tolérance aux pannes](https://bewiseapps.com/fr/software-architecture-wise/quality-attributes/availability-and-reliability): Ce que signifient réellement la disponibilité, la fiabilité et la tolérance aux pannes, comment calculer les « neuf », le MTBF et le MTTR, comment se combinent les composants en série et en parallèle, et les tactiques, le RTO et le RPO qui permettent de les atteindre.
- [2.6 Modifiabilité, testabilité et déployabilité : concevoir pour le changement](https://bewiseapps.com/fr/software-architecture-wise/quality-attributes/modifiability-testability-deployability): Comment spécifier le changement et concevoir pour lui : ce qui change, qui le change et quand, les tactiques qui limitent les effets en cascade, la testabilité par la contrôlabilité et l’observabilité, la déployabilité et les métriques de livraison DORA.
- [2.7 Sécurité, utilisabilité, interopérabilité, coût et durabilité en tant que qualités](https://bewiseapps.com/fr/software-architecture-wise/quality-attributes/security-usability-and-more): La sécurité comme qualité mesurable, les sous-caractéristiques et les tactiques de sécurité de l’ISO/IEC 25010, l’utilisabilité et l’accessibilité selon les WCAG 2.2, l’interopérabilité, le coût par transaction, l’intensité carbone du logiciel, la sûreté, l’observabilité et les qualités réglementaires.
- [2.8 Éliciter, hiérarchiser et arbitrer les attributs de qualité](https://bewiseapps.com/fr/software-architecture-wise/quality-attributes/eliciting-and-prioritising): D’où viennent les exigences de qualité, comment le Quality Attribute Workshop du SEI et l’arbre d’utilité de l’ATAM permettent de les faire émerger et de les classer, comment gérer les conflits entre qualités, et comment les fonctions d’aptitude veillent à ce qu’elles restent satisfaites.

### [Chapitre 3 : Principes et fondamentaux de conception](https://bewiseapps.com/fr/software-architecture-wise/design-principles/)
Intermédiaire. Les principes qui sous-tendent toute bonne structure : modularité, couplage et cohésion, masquage de l’information, règles de dépendance, SOLID à l’échelle des composants, connascence, loi de Conway, simplicité et mesure de la structure.

- [3.1 Modularité : diviser un système en parties](https://bewiseapps.com/fr/software-architecture-wise/design-principles/modularity): Ce qu’est un module à chaque échelle, pourquoi on divise les systèmes en modules, la règle de Parnas qui consiste à décomposer selon les changements probables, modules logiques et modules de déploiement, granularité, et comment faire respecter les frontières dans le code.
- [3.2 Couplage et cohésion](https://bewiseapps.com/fr/software-architecture-wise/design-principles/coupling-and-cohesion): Les deux plus anciennes mesures d’une bonne structure : les niveaux classiques de couplage et de cohésion, le couplage afférent et efférent, les formes supplémentaires de couplage dans les systèmes distribués et les tactiques pour le relâcher, avec un exemple commenté de refactorisation.
- [3.3 Masquage de l’information, abstraction et interfaces](https://bewiseapps.com/fr/software-architecture-wise/design-principles/information-hiding-and-abstraction): Pourquoi les modules doivent cacher des décisions, en quoi le masquage de l’information diffère de l’encapsulation, les interfaces comme contrats et la conception par contrat, les abstractions qui fuient, les modules profonds, la loi de Hyrum et comment garder stables les API entre composants.
- [3.4 Gérer les dépendances : sens, cycles et stabilité](https://bewiseapps.com/fr/software-architecture-wise/design-principles/dependencies-and-layering): Dans quel sens les dépendances doivent pointer et pourquoi : les principes des dépendances acycliques, des dépendances stables et des abstractions stables de Robert C. Martin, les métriques d’instabilité, de degré d’abstraction et de distance, la suppression des cycles, l’organisation en couches et les vérifications automatisées des dépendances.
- [3.5 Les principes SOLID appliqués aux composants](https://bewiseapps.com/fr/software-architecture-wise/design-principles/solid-at-scale): Les cinq principes SOLID expliqués avec précision, chacun illustré en Python puis à l’échelle des composants et des services, ainsi que les principes de cohésion REP, CCP et CRP, leur triangle de tensions et la critique honnête de SOLID.
- [3.6 La connascence : une mesure plus fine du couplage](https://bewiseapps.com/fr/software-architecture-wise/design-principles/connascence): La connascence de Meilir Page-Jones nomme les accords cachés entre les parties d’un système, les classe par force et les évalue selon leur localité et leur degré, des paramètres positionnels jusqu’à la synchronisation entre services.
- [3.7 La loi de Conway et la forme des organisations](https://bewiseapps.com/fr/software-architecture-wise/design-principles/conways-law): L’observation faite en 1968 par Melvin Conway selon laquelle les systèmes reproduisent la structure de communication des organisations qui les conçoivent, les données issues de la recherche, l’arithmétique des canaux de communication, la manœuvre de Conway inversée et la charge cognitive des équipes.
- [3.8 Simplicité, réversibilité et mesure de la structure](https://bewiseapps.com/fr/software-architecture-wise/design-principles/simplicity-and-measurement): La complexité essentielle et la complexité accidentelle, KISS, YAGNI, DRY comme principe portant sur la connaissance plutôt que sur le texte, la réversibilité comme option, et comment mesurer la structure avec la complexité cyclomatique, le LCOM, le couplage de changement et les fonctions d’aptitude sans tomber dans le piège de la loi de Goodhart.

### [Chapitre 4 : Documenter et communiquer l’architecture](https://bewiseapps.com/fr/software-architecture-wise/documenting-architecture/)
Intermédiaire. Les vues et les points de vue, le modèle C4, la part d’UML qui compte encore, les enregistrements de décision d’architecture (ADR), arc42, les diagrammes en tant que code et comment présenter l’architecture à des publics techniques et non techniques.

- [4.1 Pourquoi documenter, et dans quelle mesure](https://bewiseapps.com/fr/software-architecture-wise/documenting-architecture/why-document): Qui lit la documentation d’architecture et ce dont chaque lecteur a besoin, ce que dit réellement le Manifeste agile sur les documents, comment décider de ce qui mérite d’être écrit, et les règles qui gardent la documentation utile.
- [4.2 Vues et points de vue : ISO/IEC/IEEE 42010, 4+1, Rozanski et Woods](https://bewiseapps.com/fr/software-architecture-wise/documenting-architecture/views-and-viewpoints): Pourquoi un seul diagramme ne suffit jamais : le modèle de l’ISO/IEC/IEEE 42010 (parties prenantes, préoccupations, points de vue et vues), le modèle 4+1 de Kruchten, les points de vue et les perspectives de Rozanski et Woods, et comment choisir les vues dont un système a besoin.
- [4.3 Le modèle C4 : contexte, conteneurs, composants et code](https://bewiseapps.com/fr/software-architecture-wise/documenting-architecture/the-c4-model): Le modèle C4 de Simon Brown en pratique : les quatre niveaux de zoom, ce qu’est vraiment un conteneur, les règles de notation qui rendent les diagrammes explicites, et une plateforme de livraison de repas représentée aux niveaux contexte, conteneurs et composants.
- [4.4 Les diagrammes UML que les architectes utilisent encore](https://bewiseapps.com/fr/software-architecture-wise/documenting-architecture/uml-essentials): La place d’UML aujourd’hui, les modes croquis, plan détaillé et langage de programmation décrits par Fowler, et l’essentiel de la notation des six diagrammes que les architectes utilisent encore, chacun dessiné pour la plateforme de livraison de repas.
- [4.5 Enregistrements de décision d’architecture (ADR)](https://bewiseapps.com/fr/software-architecture-wise/documenting-architecture/architecture-decision-records): Comment consigner les décisions significatives pour que leurs raisons perdurent : le format de Nygard, MADR et les Y-statements, les statuts et le remplacement, où conserver les enregistrements, ce qui en mérite un, la revue et les anti-patrons.
- [4.6 arc42 et autres modèles de documentation](https://bewiseapps.com/fr/software-architecture-wise/documenting-architecture/arc42-and-templates): Les douze sections d’arc42, ce que contient chacune et combien écrire pour les petits et les grands systèmes, un exemple d’arc42 allégé tenant sur une page, les modèles du SEI et de l’IEEE 1016, et la conformité à l’ISO/IEC/IEEE 42010.
- [4.7 Diagrammes en tant que code et documentation à jour](https://bewiseapps.com/fr/software-architecture-wise/documenting-architecture/diagrams-as-code): Écrire des diagrammes sous forme de texte avec PlantUML, Mermaid, Structurizr DSL et D2, outils de dessin ou outils de modélisation, construire la documentation dans le pipeline, et les habitudes qui la gardent fidèle à la réalité.
- [4.8 Communiquer l’architecture à différents publics](https://bewiseapps.com/fr/software-architecture-wise/documenting-architecture/communicating-architecture): Adapter l’architecture aux dirigeants, aux chefs de produit, aux développeurs, à l’exploitation, à la sécurité et aux auditeurs : expliquer les compromis, les résumés d’une page, suivre une requête, les documents de conception et les RFC, les revues, la conception des diagrammes et la recherche du consensus.

### [Chapitre 5 : Styles architecturaux I : monolithes et conceptions modulaires](https://bewiseapps.com/fr/software-architecture-wise/monolithic-styles/)
Intermédiaire. Les styles pour les systèmes déployés comme une seule unité : architecture en couches, monolithe modulaire, tubes et filtres, micronoyau, architecture hexagonale et Clean Architecture, conception pilotée par le domaine, et quand un monolithe est la bonne réponse.

- [5.1 Styles architecturaux, patrons et tactiques](https://bewiseapps.com/fr/software-architecture-wise/monolithic-styles/what-is-a-style): Le vocabulaire des deux chapitres suivants : styles, patrons, tactiques et architectures de référence, partitionnement technique et partitionnement par domaine, déploiement monolithique et déploiement distribué, et le quantum d’architecture.
- [5.2 Architecture en couches](https://bewiseapps.com/fr/software-architecture-wise/monolithic-styles/layered-architecture): Le style le plus familier : couches présentation, métier, persistance et base de données. Couches fermées et ouvertes, couches d’isolation, l’anti-patron du gouffre d’architecture, pourquoi chaque fonctionnalité touche toutes les couches, et comment faire respecter les règles.
- [5.3 Le monolithe modulaire](https://bewiseapps.com/fr/software-architecture-wise/monolithic-styles/modular-monolith): Une seule application déployable, divisée par domaine métier en modules dotés d’API explicites et de leurs propres données. Comment faire respecter les frontières, comment les modules communiquent, ce que Shopify en a appris et comment ce style préserve la possibilité d’extraire des services plus tard.
- [5.4 Tubes et filtres, et architectures en pipeline](https://bewiseapps.com/fr/software-architecture-wise/monolithic-styles/pipes-and-filters): Des données qui circulent à travers une chaîne d’étapes indépendantes : producteurs, transformateurs, testeurs et consommateurs reliés par des tubes. Des tubes Unix à l’ETL, aux compilateurs et au traitement de flux, avec le débit, la contre-pression et la gestion des erreurs.
- [5.5 Architectures micronoyau et à plug-ins](https://bewiseapps.com/fr/software-architecture-wise/monolithic-styles/microkernel): Comment un petit système central et des plug-ins indépendants apportent l’extensibilité : registres, contrats, isolation et versionnage, exemples réels tirés des IDE et des navigateurs, et un contrat de plug-in commenté pour des règles fiscales propres à chaque pays.
- [5.6 Architecture hexagonale, en oignon et Clean Architecture](https://bewiseapps.com/fr/software-architecture-wise/monolithic-styles/hexagonal-and-clean): Ports et adaptateurs, architecture en oignon et Clean Architecture : garder la logique métier au centre avec des dépendances orientées vers l’intérieur, ports pilotes et ports pilotés, un exemple en Python avec un véritable adaptateur et une doublure de test, et les coûts.
- [5.7 Conception stratégique pilotée par le domaine : contextes délimités et cartes de contextes](https://bewiseapps.com/fr/software-architecture-wise/monolithic-styles/domain-driven-design): Trouver les frontières dans le domaine métier : langage omniprésent, sous-domaines cœur, de soutien et génériques, contextes délimités, relations de la carte de contextes, event storming, agrégats, et une carte de contextes de la plateforme de livraison de repas.
- [5.8 Quand un monolithe est la bonne réponse](https://bewiseapps.com/fr/software-architecture-wise/monolithic-styles/choosing-a-monolith): MonolithFirst, le surcoût des microservices et le monolithe majestueux ; quand une seule unité de déploiement est le bon choix, jusqu’où un monolithe peut passer à l’échelle, les signes qu’il est temps de le découper, et un guide de décision pour les styles du chapitre 5.

### [Chapitre 6 : Styles architecturaux II : systèmes distribués](https://bewiseapps.com/fr/software-architecture-wise/distributed-systems/)
Intermédiaire à avancé. Pourquoi et quand distribuer, les illusions de l’informatique distribuée, les architectures à base de services et de microservices, les systèmes pilotés par les événements, la communication synchrone et asynchrone, CAP et PACELC, les sagas, et les conceptions serverless et basées sur l’espace.

- [6.1 Pourquoi distribuer, et les illusions de l’informatique distribuée](https://bewiseapps.com/fr/software-architecture-wise/distributed-systems/why-distribute): Les vraies raisons de répartir un système sur plusieurs machines, les huit illusions qui rendent la distribution plus difficile qu’il n’y paraît, la défaillance partielle, les coûts et l’arithmétique des chaînes d’appels synchrones.
- [6.2 Architecture à base de services et architecture orientée services](https://bewiseapps.com/fr/software-architecture-wise/distributed-systems/service-based-and-soa): Des services de domaine à gros grain partageant une base de données, l’ère du bus de services d’entreprise de la SOA et les raisons de son déclin, ce qui distingue les microservices, et quand l’architecture à base de services constitue un juste milieu pragmatique.
- [6.3 Microservices : principes, avantages et coûts](https://bewiseapps.com/fr/software-architecture-wise/distributed-systems/microservices): Ce que sont les microservices selon Lewis et Fowler, les contextes délimités, la déployabilité indépendante, la base de données par service, les passerelles et les maillages de services, comment décider de la granularité, les anti-patrons classiques et le prix organisationnel.
- [6.4 Architecture pilotée par les événements : courtiers, médiateurs et flux d’événements](https://bewiseapps.com/fr/software-architecture-wise/distributed-systems/event-driven): Événements, commandes et messages ; topologies à courtier et à médiateur ; les quatre patrons d’événements de Fowler ; le fonctionnement des partitions, des offsets et des groupes de consommateurs de Kafka ; garanties de livraison, consommateurs idempotents, schémas et files de lettres mortes.
- [6.5 Communication synchrone et asynchrone : REST, gRPC, GraphQL et messagerie](https://bewiseapps.com/fr/software-architecture-wise/distributed-systems/communication-and-apis): Comment les services dialoguent : le couplage créé par la communication synchrone et asynchrone, la sémantique de REST et de HTTP, gRPC, GraphQL et la messagerie, et les pratiques de conception d’API qui permettent aux interfaces d’évoluer sans casser les consommateurs.
- [6.6 Modèles de cohérence, CAP et PACELC](https://bewiseapps.com/fr/software-architecture-wise/distributed-systems/consistency-cap-pacelc): Ce que signifie la cohérence pour des données répliquées : les modèles, de la linéarisabilité à la cohérence à terme, ce que le théorème CAP dit réellement et ce qu’il ne dit pas, le compromis quotidien sur la latence mis en évidence par PACELC, l’arithmétique des quorums et le choix de la cohérence selon le cas d’usage.
- [6.7 Transactions distribuées, sagas et patron outbox](https://bewiseapps.com/fr/software-architecture-wise/distributed-systems/sagas-and-distributed-transactions): Comment garder les données cohérentes quand une action métier s’étend sur plusieurs services : la validation en deux phases et pourquoi on l’évite, les sagas avec compensations, chorégraphie et orchestration, les contre-mesures d’isolation, l’outbox transactionnelle et les récepteurs idempotents.
- [6.8 Architectures serverless et basées sur l’espace](https://bewiseapps.com/fr/software-architecture-wise/distributed-systems/serverless-and-space-based): Deux réponses opposées à la question de la capacité : les fonctions serverless et les backends managés, qui descendent à zéro et sont facturés à l’usage, et l’architecture basée sur l’espace, qui absorbe des pics extrêmes depuis une mémoire répliquée en tenant la base de données à l’écart du chemin critique.

### [Chapitre 7 : Architecture des données](https://bewiseapps.com/fr/software-architecture-wise/data-architecture/)
Intermédiaire à avancé. La propriété des données, le choix d’une base de données, les transactions et l’isolation, la réplication et le partitionnement, CQRS et l’event sourcing, la mise en cache, l’évolution des schémas, ainsi que l’analytique, le streaming et le data mesh.

- [7.1 Propriété des données et base de données par service](https://bewiseapps.com/fr/software-architecture-wise/data-architecture/data-ownership): Qui peut modifier chaque donnée, pourquoi une base de données partagée couple les services, comment résoudre une propriété conjointe, et comment lire des données dont vous n’êtes pas propriétaire, en tirer des rapports et établir des contrats à leur sujet.
- [7.2 Choisir une base de données : relationnelle, documents, clé-valeur, colonnes, graphe et séries temporelles](https://bewiseapps.com/fr/software-architecture-wise/data-architecture/choosing-a-database): Ce que chaque famille de bases de données fait bien et mal, du relationnel au vectoriel et au SQL distribué, et comment choisir selon la forme des données, les schémas d’accès, la cohérence, l’échelle, l’exploitation et les compétences de l’équipe.
- [7.3 Transactions, ACID et niveaux d’isolation](https://bewiseapps.com/fr/software-architecture-wise/data-architecture/transactions-and-isolation): Ce que garantit réellement ACID, les anomalies que permettent les niveaux d’isolation, comment fonctionnent le MVCC et l’isolation par instantané, pourquoi les noms des niveaux sont trompeurs, et quand utiliser le verrouillage, les vérifications de version ou les transactions sérialisables.
- [7.4 Réplication, partitionnement et sharding](https://bewiseapps.com/fr/software-architecture-wise/data-architecture/replication-and-partitioning): Comment les bases de données copient les données pour la disponibilité et le passage à l’échelle des lectures, ce que le retard de réplication et le failover font à l’exactitude, et comment le partitionnement par plage ou par hachage, le hachage cohérent et les index secondaires façonnent une conception partitionnée (sharding).
- [7.5 CQRS et event sourcing](https://bewiseapps.com/fr/software-architecture-wise/data-architecture/cqrs-and-event-sourcing): Séparer le modèle qui modifie les données des modèles qui les lisent, stocker l’état comme une séquence d’événements en ajout seul, et les coûts réels : cohérence à terme, versionnage des événements et données à caractère personnel.
- [7.6 Stratégies de mise en cache et leurs pièges](https://bewiseapps.com/fr/software-architecture-wise/data-architecture/caching): Pourquoi les caches accélèrent les systèmes et ce qu’ils coûtent : cache-aside, read-through, write-through, write-behind et refresh-ahead, TTL et invalidation, ruées sur le cache, niveaux de cache, en-têtes HTTP et éviction.
- [7.7 Évolution des schémas, migrations et compatibilité](https://bewiseapps.com/fr/software-architecture-wise/data-architecture/schema-evolution): Modifier les schémas de bases de données, d’API et d’événements pendant que le système continue de fonctionner : rétrocompatibilité, compatibilité future et compatibilité complète, expansion-contraction, outils de migration, backfills de grande ampleur et registres de schémas pour Avro et Protocol Buffers.
- [7.8 Analytique, streaming, entrepôts de données, data lakes et data mesh](https://bewiseapps.com/fr/software-architecture-wise/data-architecture/analytics-and-streaming): Comment s’architecturent les données analytiques : OLTP et OLAP, entrepôts de données et schémas en étoile, ETL et ELT, lacs de données et lakehouses, traitement de flux avec temps de l’événement et filigranes (watermarks), Lambda et Kappa, et data mesh.

### [Chapitre 8 : Sécurité, confidentialité et conformité dès la conception](https://bewiseapps.com/fr/software-architecture-wise/security-by-design/)
Intermédiaire à avancé. Principes de sécurité, modélisation des menaces avec STRIDE, identité et accès (OAuth 2.0 et OpenID Connect), chiffrement et secrets, zero trust, sécurité de la chaîne d’approvisionnement logicielle, protection de la vie privée dès la conception au titre du RGPD, et sécurité en exploitation.

- [8.1 Principes de sécurité pour les architectes](https://bewiseapps.com/fr/software-architecture-wise/security-by-design/security-principles): La triade CIA, les principes de conception de Saltzer et Schroeder, la défense en profondeur, la sécurité par défaut, la surface d’attaque et les frontières de confiance, l’OWASP Top 10 et un cycle de développement sécurisé, avec qui est responsable de quoi.
- [8.2 Modélisation des menaces : STRIDE, arbres d’attaque et diagrammes de flux de données](https://bewiseapps.com/fr/software-architecture-wise/security-by-design/threat-modelling): Les quatre questions de Shostack, les diagrammes de flux de données avec frontières de confiance, STRIDE et les arbres d’attaque, l’évaluation du risque sans fausse précision, et un modèle de menaces commenté pour l’étape de paiement d’une plateforme de livraison de repas.
- [8.3 Identité et accès : authentification, autorisation, OAuth 2.0 et OpenID Connect](https://bewiseapps.com/fr/software-architecture-wise/security-by-design/identity-and-access): Authentification et autorisation, les règles actuelles du NIST sur les mots de passe, la MFA et les passkeys, les sessions et les JWT, OAuth 2.0 avec PKCE, OpenID Connect, RBAC, ABAC, le contrôle d’accès basé sur les relations et l’identité de charge de travail.
- [8.4 Chiffrement, gestion des clés et secrets](https://bewiseapps.com/fr/software-architecture-wise/security-by-design/protecting-data): Le chiffrement en transit et au repos et ce que chaque couche protège réellement, la cryptographie symétrique et asymétrique, le hachage des mots de passe, le KMS et le chiffrement d’enveloppe, les secrets, la tokenisation pour PCI DSS et la classification des données.
- [8.5 Communication sécurisée et zero trust](https://bewiseapps.com/fr/software-architecture-wise/security-by-design/zero-trust): Pourquoi le réseau interne de confiance a échoué, ce que NIST SP 800-207 et BeyondCorp entendent par zero trust, et comment le mTLS, l’identité de charge de travail, les service meshes, les certificats et les passerelles le mettent en pratique.
- [8.6 Sécurité de la chaîne d’approvisionnement logicielle](https://bewiseapps.com/fr/software-architecture-wise/security-by-design/supply-chain-security): Pourquoi les dépendances et les pipelines de build sont une surface d’attaque, ce qu’enseignent event-stream, SolarWinds, Log4Shell et xz utils, et comment les SBOM, SLSA, Sigstore, l’épinglage des versions et le règlement européen sur la cyberrésilience (Cyber Resilience Act) y répondent.
- [8.7 Protection de la vie privée dès la conception et RGPD](https://bewiseapps.com/fr/software-architecture-wise/security-by-design/privacy-by-design): Comment le RGPD et le RGPD britannique (UK GDPR) façonnent l’architecture : les principes de l’article 5, la protection des données dès la conception et par défaut, les droits que les systèmes doivent prendre en charge, les AIPD, les transferts, la pseudonymisation, la conservation et l’effacement dans chaque copie.
- [8.8 Sécurité en exploitation : journalisation, détection et réponse](https://bewiseapps.com/fr/software-architecture-wise/security-by-design/security-in-operation): Exploiter un système de manière sécurisée : ce qu’il faut journaliser et ne jamais journaliser, les pistes d’audit, la détection par SIEM, la gestion des vulnérabilités avec CVSS, EPSS et KEV, la réponse aux incidents selon le NIST, des sauvegardes à l’épreuve des rançongiciels et les délais de notification des violations.

### [Chapitre 9 : Performances, scalabilité, résilience et exploitabilité](https://bewiseapps.com/fr/software-architecture-wise/resilience-and-operability/)
Intermédiaire à avancé. Stratégies de passage à l’échelle, équilibrage de charge et absence d’état, files d’attente et back pressure, délais d’expiration, nouvelles tentatives, disjoncteurs et cloisonnement, SLI, SLO et budgets d’erreur, observabilité, planification de la capacité et ingénierie du chaos.

- [9.1 Stratégies de passage à l’échelle : verticale, horizontale et cube de scalabilité](https://bewiseapps.com/fr/software-architecture-wise/resilience-and-operability/scaling-strategies): La scalabilité verticale et horizontale et leurs limites, le cube de scalabilité d’Abbott et Fisher, l’absence d’état, l’autoscaling réactif, planifié et prédictif, le choix d’un signal de mise à l’échelle, comment éviter le flapping, et le dimensionnement d’un parc de serveurs pour un pic.
- [9.2 Équilibrage de charge, absence d’état et sessions](https://bewiseapps.com/fr/software-architecture-wise/resilience-and-operability/load-balancing-and-statelessness): Les équilibreurs de charge de couche 4 et de couche 7, les principaux algorithmes, dont la puissance de deux choix aléatoires, les contrôles de vivacité et de disponibilité, le drainage des connexions, les inconvénients des sessions persistantes, l’état de session externalisé et l’équilibrage de charge global.
- [9.3 Asynchronisme, files d’attente et back pressure](https://bewiseapps.com/fr/software-architecture-wise/resilience-and-operability/queues-and-back-pressure): Comment les files d’attente transforment les pics en arriérés, les consommateurs concurrents, le dimensionnement des files avec la loi de Little, le back pressure, le délestage de charge et la priorisation, le token bucket et les autres limiteurs de débit, HTTP 429 avec Retry-After, et les files de lettres mortes.
- [9.4 Délais d’expiration, nouvelles tentatives, disjoncteurs, cloisonnement et dégradation gracieuse](https://bewiseapps.com/fr/software-architecture-wise/resilience-and-operability/resilience-patterns): Les patrons de stabilité qui empêchent une seule dépendance lente de faire tomber un système : délais d’expiration et échéances, nouvelles tentatives avec backoff, jitter et budgets, disjoncteurs, cloisonnement, solutions de repli, idempotence et requêtes de couverture.
- [9.5 SLI, SLO, SLA et budgets d’erreur](https://bewiseapps.com/fr/software-architecture-wise/resilience-and-operability/slos-and-error-budgets): Comment mesurer la fiabilité du point de vue de l’utilisateur avec des SLI, fixer des cibles de SLO, les transformer en budgets d’erreur et en politiques, déclencher des alertes sur le taux de consommation et garder les SLA prudemment plus souples que les objectifs internes.
- [9.6 Observabilité : journaux, métriques et traces](https://bewiseapps.com/fr/software-architecture-wise/resilience-and-operability/observability): Comment voir à l’intérieur d’un système distribué en fonctionnement : journaux structurés, types de métriques et histogrammes, RED, USE et les signaux d’or, traçage distribué avec W3C Trace Context et OpenTelemetry, cardinalité et alertes fondées sur les symptômes.
- [9.7 Planification de la capacité et tests de performances](https://bewiseapps.com/fr/software-architecture-wise/resilience-and-operability/capacity-and-performance-testing): Comment planifier la capacité avant l’arrivée de la demande et vérifier qu’elle est bien là : prévisions, marge de capacité et délais d’approvisionnement, tests de charge, de stress, d’endurance, de pic et de point de rupture, charges ouvertes et fermées, omission coordonnée et budgets de performance.
- [9.8 Ingénierie du chaos, incidents et apprentissage sans reproche](https://bewiseapps.com/fr/software-architecture-wise/resilience-and-operability/chaos-and-incidents): Comment trouver les faiblesses avant les utilisateurs et tirer les leçons des défaillances qui surviennent malgré tout : expériences de chaos et game days, coordination des incidents, niveaux de gravité et pages de statut, revues sans reproche, les limites du MTTR et des actions qui changent le système.

### [Chapitre 10 : Architecture cloud native et d’infrastructure](https://bewiseapps.com/fr/software-architecture-wise/cloud-native/)
Intermédiaire à avancé. Modèles de services cloud, conteneurs et Kubernetes, l’application douze facteurs, l’infrastructure en tant que code, la CI/CD et les stratégies de déploiement, le multirégion et la périphérie (edge), l’ingénierie de plateforme, le FinOps et la dépendance au fournisseur vue comme un compromis.

- [10.1 Modèles de services et de déploiement cloud](https://bewiseapps.com/fr/software-architecture-wise/cloud-native/cloud-models): IaaS, CaaS, PaaS, FaaS et SaaS ; cloud public, privé, hybride et multicloud ; responsabilité partagée, zones et services managés ; ce que signifie cloud native, et quand louer ne revient pas moins cher.
- [10.2 Conteneurs et orchestration avec Kubernetes](https://bewiseapps.com/fr/software-architecture-wise/cloud-native/containers-and-orchestration): Images, couches, registres et normes OCI ; pourquoi l’orchestration est nécessaire ; le plan de contrôle de Kubernetes, les nœuds, les objets de base et les boucles de réconciliation ; requêtes, limites, sondes, et quand Kubernetes est surdimensionné.
- [10.3 L’application douze facteurs et les principes cloud native](https://bewiseapps.com/fr/software-architecture-wise/cloud-native/twelve-factor): Les douze facteurs, avec ce que chacun signifie, pourquoi il compte et où il a vieilli ; les principes qui vont au-delà (jetabilité, immuabilité, observabilité, sécurité) ; et l’audit commenté d’un service existant avec des corrections priorisées.
- [10.4 Infrastructure en tant que code et infrastructure immuable](https://bewiseapps.com/fr/software-architecture-wise/cloud-native/infrastructure-as-code): Code d’infrastructure déclaratif et impératif ; Terraform, OpenTofu, CloudFormation, Bicep et Pulumi ; état, verrouillage, dérive, modules et environnements ; infrastructure immuable ; GitOps ; politique en tant que code ; et comment tester le tout.
- [10.5 Pipelines CI/CD et stratégies de déploiement](https://bewiseapps.com/fr/software-architecture-wise/cloud-native/ci-cd-and-deployment): Comment un changement va du commit à la production : étapes du pipeline, build once, deploy many, développement basé sur le tronc, déploiements progressifs, bleu-vert, canari et fantômes, feature flags, migrations et retour arrière.
- [10.6 Multirégion, reprise après sinistre et edge computing](https://bewiseapps.com/fr/software-architecture-wise/cloud-native/multi-region-and-edge): Quand et comment fonctionner sur plusieurs régions : latence, reprise après sinistre et résidence des données, les quatre stratégies de reprise avec RTO, RPO et coût, les données interrégions, le basculement, les cellules pour limiter le rayon d’impact, les CDN et les fonctions en périphérie.
- [10.7 Ingénierie de plateforme et plateformes internes de développement](https://bewiseapps.com/fr/software-architecture-wise/cloud-native/platform-engineering): Pourquoi les organisations construisent des plateformes internes de développement, les golden paths et Backstage, gérer la plateforme comme un produit avec libre-service et garde-fous, réduire la charge cognitive, mesurer le succès avec DORA et SPACE, et éviter les pièges courants.
- [10.8 FinOps, architecture des coûts et dépendance au fournisseur](https://bewiseapps.com/fr/software-architecture-wise/cloud-native/finops-and-lock-in): Traiter le coût comme une qualité architecturale : les phases du FinOps, l’économie unitaire comme le coût par commande, les facteurs de coût courants, les engagements et le spot, l’étiquetage, le showback et le chargeback, et la dépendance au fournisseur comme compromis délibéré assorti d’une stratégie de sortie.

### [Chapitre 11 : Évaluation, prise de décision et gouvernance](https://bewiseapps.com/fr/software-architecture-wise/evaluation-and-governance/)
Avancé. Comment les architectures sont jugées et gouvernées : l’ATAM et les revues légères, les fonctions d’aptitude et l’architecture évolutive, la gouvernance dans les organisations agiles, Team Topologies, la modernisation des systèmes hérités, le leadership, l’éthique et l’analyse de rentabilité.

- [11.1 Évaluation de l’architecture et ATAM](https://bewiseapps.com/fr/software-architecture-wise/evaluation-and-governance/architecture-evaluation): Pourquoi et quand évaluer une architecture, comment fonctionne pas à pas l’ATAM du SEI, ce que sont les risques, les points de sensibilité et les points de compromis, et comment la CBAM ajoute les coûts et les bénéfices.
- [11.2 Revues légères et risk-storming](https://bewiseapps.com/fr/software-architecture-wise/evaluation-and-governance/lightweight-reviews): Pourquoi les comités de revue échouent souvent, et les alternatives légères qui fonctionnent : risk-storming, pre-mortems, katas d’architecture, TARA, revues de RFC et listes de contrôle, avec un format de revue de 90 minutes.
- [11.3 Fonctions d’aptitude et architecture évolutive](https://bewiseapps.com/fr/software-architecture-wise/evaluation-and-governance/fitness-functions): Comment protéger les caractéristiques architecturales par des vérifications automatisées : ce que sont les fonctions d’aptitude, leurs catégories, des exemples pour la structure, les performances, la sécurité, la résilience et les données, et l’architecture évolutive.
- [11.4 Gouvernance de l’architecture dans les organisations agiles](https://bewiseapps.com/fr/software-architecture-wise/evaluation-and-governance/governance-in-agile): À quoi sert la gouvernance de l’architecture et comment la pratiquer sans points de validation qui ralentissent : principes, normes, garde-fous, processus de consultation, forums consultatifs, radars technologiques, politique en tant que code et architecture d’entreprise.
- [11.5 Team Topologies et conception sociotechnique](https://bewiseapps.com/fr/software-architecture-wise/evaluation-and-governance/team-topologies): Comment concevoir ensemble les équipes et le logiciel : les quatre types d’équipes, les trois modes d’interaction, la charge cognitive, les API d’équipe et les plans de fracture, avec une réorganisation commentée des équipes de la plateforme de livraison de repas.
- [11.6 Moderniser les systèmes hérités : strangler fig et migration incrémentale](https://bewiseapps.com/fr/software-architecture-wise/evaluation-and-governance/legacy-modernisation): Pourquoi les grandes réécritures échouent et comment moderniser sans risque à la place : les sept R, le strangler fig, branch by abstraction, les exécutions en parallèle, la capture des données modifiées, les couches anticorruption et une migration des données soigneuse.
- [11.7 Leadership, influence et prise de décision](https://bewiseapps.com/fr/software-architecture-wise/evaluation-and-governance/leadership-and-influence): Comment les architectes dirigent sans autorité formelle : bâtir la confiance, faciliter des décisions par consentement ou par consensus, gérer les conflits et les jeux politiques, parler aux dirigeants, emprunter l’ascenseur de l’architecte et faire grandir d’autres architectes.
- [11.8 Éthique, durabilité et analyse de rentabilité](https://bewiseapps.com/fr/software-architecture-wise/evaluation-and-governance/ethics-and-business-cases): Comment défendre le travail d’architecture en termes d’argent, de temps et de risque, avec des calculs commentés de la valeur actuelle nette et du délai de récupération ; et comment l’éthique professionnelle, les préjudices prévisibles et les pratiques du logiciel vert façonnent une conception responsable.

### [Chapitre 12 : Architecture des systèmes intégrant l’IA](https://bewiseapps.com/fr/software-architecture-wise/ai-enabled-systems/)
Avancé. L’apprentissage automatique et les grands modèles de langage du point de vue de l’architecte : où placer les modèles, la génération augmentée par récupération, les agents et l’utilisation d’outils, l’évaluation, les garde-fous, le coût et la latence, le LLMOps et l’IA responsable au titre du règlement européen sur l’IA (AI Act).

- [12.1 Apprentissage automatique et grands modèles de langage pour les architectes](https://bewiseapps.com/fr/software-architecture-wise/ai-enabled-systems/ml-and-llm-basics): Ce que font réellement l’apprentissage automatique et les grands modèles de langage, de l’entraînement et l’évaluation aux tokens, aux fenêtres de contexte, à l’échantillonnage et aux embeddings, et ce qu’implique un composant probabiliste pour le système qui l’entoure.
- [12.2 La place des modèles dans une architecture](https://bewiseapps.com/fr/software-architecture-wise/ai-enabled-systems/where-models-fit): Modèles hébergés, auto-hébergés ou embarqués sur l’appareil ; inférence en ligne et par lots ; AI gateways, routage, cascades et échelles de repli ; humains dans la boucle ; choix d’un modèle ; et une architecture de référence pour un assistant de support.
- [12.3 Génération augmentée par récupération et recherche vectorielle](https://bewiseapps.com/fr/software-architecture-wise/ai-enabled-systems/retrieval-augmented-generation): Comment ancrer les réponses du modèle dans vos propres données : ingestion et chunking, embeddings et index vectoriels, récupération hybride et re-ranking, citations, contrôle d’accès, fraîcheur, évaluation et modes de défaillance.
- [12.4 Agents, utilisation d’outils et orchestration](https://bewiseapps.com/fr/software-architecture-wise/ai-enabled-systems/agents-and-tool-use): Comment les modèles appellent des outils, comment fonctionne la boucle de l’agent, quand un workflow l’emporte sur un agent autonome, ce que normalise le Model Context Protocol, et comment rendre les agents fiables avec des limites, l’idempotence, des points de reprise et une approbation.
- [12.5 Évaluer et tester les systèmes intégrant l’IA](https://bewiseapps.com/fr/software-architecture-wise/ai-enabled-systems/evaluating-ai-systems): Comment tester des composants dont les sorties varient : golden sets, méthodes de notation, le LLM comme juge et ses biais, évaluation hors ligne et en ligne, évals de régression dans la CI, supervision en production, red teaming et confiance dans les chiffres.
- [12.6 Garde-fous, sûreté et injection de prompt](https://bewiseapps.com/fr/software-architecture-wise/ai-enabled-systems/guardrails-and-safety): Pourquoi un modèle de langage est un composant non fiable : injection de prompt directe et indirecte, jailbreaks, l’OWASP Top 10 for LLM Applications, le trio fatal, et des défenses en couches qui tiennent même lorsque le modèle est manipulé.
- [12.7 Coût, latence et LLMOps](https://bewiseapps.com/fr/software-architecture-wise/ai-enabled-systems/cost-latency-and-llmops): L’économie et l’exploitation des appels de modèles : tokens d’entrée et de sortie, délai jusqu’au premier token et streaming, mise en cache des prompts et cache sémantique, traitement par lots, cascades, limites de débit et échelles de repli, versionnage, traçage et suivi des coûts.
- [12.8 Gouvernance des données, IA responsable et règlement européen sur l’IA](https://bewiseapps.com/fr/software-architecture-wise/ai-enabled-systems/responsible-ai): Traduire en architecture les principes de l’IA responsable : provenance des données et données à caractère personnel dans les prompts et les journaux, biais et équité, transparence et model cards, contrôle humain, le règlement européen sur l’IA tel que modifié en 2026, le NIST AI RMF et ISO/IEC 42001.

## Autres pages

- [Glossaire](https://bewiseapps.com/fr/software-architecture-wise/glossary)
- [Comment fonctionnent le cours, les tests et le certificat](https://bewiseapps.com/fr/software-architecture-wise/how-it-works)
- [Un parcours pour débutants](https://bewiseapps.com/fr/software-architecture-wise/beginners-path): un parcours suggéré à travers le cours en six étapes pour les personnes qui débutent dans le logiciel, avec une méthode pour les sections plus difficiles
- [Un itinéraire pour apprenants expérimentés](https://bewiseapps.com/fr/software-architecture-wise/experienced-route): les chapitres dans le même ordre, de 0 à 12, pour les personnes qui travaillent déjà dans le logiciel, avec des indications sur ce qu’elles peuvent survoler ; il faut tout de même réussir chaque test de chapitre pour obtenir le certificat
- [Vérifier un certificat](https://bewiseapps.com/fr/software-architecture-wise/verify)