Be Wise Apps

Read in English · Leer en español · Auf Deutsch lesen

Glossaire de l’architecture logicielle

De courtes définitions des 914 termes utilisés dans les chapitres publiés, chacune reliée au chapitre qui l’explique.

A

Abstraction

Vue simplifiée de quelque chose, qui conserve ce qui compte pour un objectif donné et omet le reste, comme un « fichier » qui masque les disques, les secteurs et la mise en cache. Chapitre 3

Abstraction qui fuit (leaky abstraction)

Abstraction dont les détails cachés affectent encore ses utilisateurs, par exemple un appel distant qui ressemble à un appel local jusqu’à ce que le réseau soit lent ou tombe en panne. Nommée par Joel Spolsky en 2002. Chapitre 3

Accessibilité

Mesure dans laquelle les personnes en situation de handicap, y compris celles qui utilisent des technologies d’assistance comme les lecteurs d’écran, peuvent utiliser un produit. Chapitre 2

Accord de niveau de service (SLA)

Contrat passé avec les clients qui fixe un niveau de service et les conséquences, comme des crédits de service, s’il n’est pas atteint. Chapitre 2

ACID

Atomicité, cohérence, isolation, durabilité : les garanties qu’offre une transaction de base de données pour que les données restent correctes malgré les pannes et les utilisateurs simultanés. Chapitre 0

Actif-actif (multisite)

Organisation dans laquelle deux régions ou plus servent du trafic réel en même temps, de sorte que la perte d’une région ne nécessite aucun failover, seulement une redistribution du trafic. Chapitre 10

Adaptateur

Code qui fait la traduction entre un port et une technologie précise, comme un contrôleur HTTP, un repository SQL ou le SDK d’un prestataire de paiement. Un même port peut avoir plusieurs adaptateurs. Chapitre 5

Adaptateur pilote (primaire)

Adaptateur qui reçoit des requêtes venant de l’extérieur, comme un contrôleur web, un banc de test ou une tâche planifiée, et qui appelle l’application par l’intermédiaire d’un port pilote. Chapitre 5

Adaptateur piloté (secondaire)

Adaptateur qui implémente une interface que l’application appelle lorsqu’elle a besoin de quelque chose de l’extérieur, comme stocker des données, débiter une carte ou envoyer un message. Chapitre 5

Adresse IP

Adresse numérique qui identifie un appareil sur un réseau afin que des paquets puissent lui être remis, comme 192.0.2.10 (IPv4) ou 2001:db8::1 (IPv6). Chapitre 0

Agent

Système dans lequel un modèle choisit des actions de façon répétée, comme des appels d’outils, observe les résultats et décide de la suite jusqu’à ce qu’un objectif soit atteint ou qu’une limite soit rencontrée. Chapitre 12

Agile

Famille d’approches du développement logiciel, définies dans le Manifeste agile de 2001, qui livrent du logiciel fonctionnel par cycles courts et adaptent les plans en fonction des retours. Chapitre 0

Agrégat

Ensemble d’objets du domaine modifiés comme une seule unité par l’intermédiaire d’une unique entité racine, qui fait respecter les règles devant toujours être vraies pour l’ensemble. Chapitre 5

AI gateway (passerelle d’IA)

Composant placé entre les applications et les fournisseurs de modèles, qui centralise les identifiants, le routage, les solutions de repli, les quotas, la journalisation et les contrôles de politique pour les appels aux modèles. Chapitre 12

Alerte multifenêtre et multi-taux de consommation

Alerte de SLO qui ne se déclenche que lorsque le taux de consommation dépasse un seuil à la fois sur une fenêtre longue et sur une fenêtre courte, ce qui combine une détection rapide, une réinitialisation rapide et peu de fausses alertes. Chapitre 9

Algorithme

Méthode précise, étape par étape, pour résoudre un problème, comme trier une liste ou trouver l’itinéraire le plus court, et qui se termine toujours. Chapitre 0

Analyse canari automatisée

Comparaison statistique des métriques d’un canari avec celles d’une référence exécutant l’ancienne version, utilisée par le pipeline pour promouvoir ou annuler la version sans jugement humain. Chapitre 10

Analyse de la composition logicielle (SCA)

Outils et pratiques qui identifient les composants open source d’un logiciel et les confrontent à des bases de données de vulnérabilités et de licences connues. Chapitre 8

Analyse de rentabilité (business case)

Argumentaire structuré en faveur d’un investissement, qui expose le problème, les options (y compris ne rien faire), leurs coûts, leurs bénéfices et leurs risques, ainsi qu’une recommandation que les décideurs peuvent comparer à d’autres utilisations de l’argent. Chapitre 11

Analyse d’impact relative à la protection des données (AIPD)

Analyse exigée par l’article 35 du RGPD avant tout traitement susceptible d’engendrer un risque élevé pour les personnes, qui décrit le traitement, sa nécessité, les risques et les mesures envisagées pour y faire face. Chapitre 8

Anomalie (phénomène)

Résultat erroné causé par l’interférence de transactions concurrentes, comme une lecture sale, une mise à jour perdue ou un write skew ; les niveaux d’isolation sont définis par les anomalies qu’ils empêchent. Chapitre 7

Anonymisation

Traitement des données de sorte qu’elles ne se rapportent plus à une personne identifiable par aucun moyen raisonnablement susceptible d’être utilisé ; les données réellement anonymes sortent du champ du RGPD. Chapitre 8

Anti-patron (anti-pattern)

Solution couramment utilisée qui semble raisonnable mais qui cause invariablement plus de problèmes qu’elle n’en résout. Chapitre 5

Anycast

Annonce de la même adresse IP depuis de nombreux emplacements, afin que le routage d’internet achemine les paquets de chaque utilisateur vers l’emplacement le plus proche qui l’annonce. Chapitre 9

API (interface de programmation d’application)

Ensemble défini d’opérations, d’entrées et de sorties par lequel un logiciel en utilise un autre, sans avoir besoin de savoir comment il fonctionne à l’intérieur. Chapitre 0

API de l’équipe (team API)

Tout ce qu’une équipe offre aux autres équipes et attend d’elles : ses interfaces de code, sa documentation, ses règles de versionnage, ses façons de travailler, ses canaux de communication et la manière de lui demander du travail. Chapitre 11

API du module

La petite partie, délibérément publique, d’un module que les autres modules peuvent utiliser ; tout le reste est interne et peut changer librement. Chapitre 5

API gateway (passerelle d’API)

Point d’entrée unique placé devant les services, qui gère des préoccupations transversales comme TLS, l’authentification, la limitation de débit et le routage. Chapitre 6

API web

API proposée sur un réseau, généralement au moyen de HTTP, afin que des programmes s’exécutant sur des machines différentes, écrits dans des langages différents, puissent fonctionner ensemble. Chapitre 0

Appel d’outils (tool calling)

Capacité d’un modèle à renvoyer une demande structurée d’appel à une fonction que l’application a décrite ; c’est l’application, et non le modèle, qui l’exécute. Chapitre 12

Appel synchrone

Requête pour laquelle l’appelant attend la réponse avant de continuer, comme dans un appel d’API HTTP ordinaire. Chapitre 0

Application douze facteurs (twelve-factor app)

Méthodologie de douze pratiques pour construire des applications web déployables et capables de passer à l’échelle, rédigée par Adam Wiggins chez Heroku en 2011 et publiée en open source en 2024. Chapitre 10

Application sans état (stateless)

Application qui ne conserve aucune donnée propre à un utilisateur dans sa mémoire entre deux requêtes, de sorte que n’importe quelle copie peut traiter n’importe quelle requête et que l’on peut ajouter ou retirer des copies librement. Chapitre 5

Apprentissage automatique (machine learning)

Construire une fonction à partir d’exemples plutôt que de règles écrites à la main : un modèle est ajusté aux données, puis utilisé pour faire des prédictions sur de nouvelles entrées. Chapitre 12

Apprentissage non supervisé

Apprentissage automatique sans étiquettes, dans lequel le modèle trouve lui-même une structure, comme des groupes de clients similaires ou des transactions inhabituelles. Chapitre 12

Apprentissage par renforcement

Apprentissage automatique dans lequel un agent effectue des actions et apprend à partir d’un signal de récompense plutôt qu’à partir de réponses correctes. Chapitre 12

Apprentissage par renforcement à partir de retours humains (RLHF)

Étape d’entraînement dans laquelle des personnes comparent les réponses d’un modèle, un modèle de récompense apprend leurs préférences, et le modèle est optimisé pour obtenir un bon score selon ce dernier. Chapitre 12

Apprentissage supervisé

Apprentissage automatique à partir d’exemples étiquetés, où chaque entrée d’entraînement est accompagnée de la bonne réponse, comme des paiements marqués frauduleux ou authentiques. Chapitre 12

Approche architecturale

Décision de conception importante ou combinaison de décisions, comme un style, un patron ou une tactique, que l’architecture utilise pour atteindre une qualité : par exemple un courtier d’événements avec une outbox, ou une région en warm standby. Chapitre 11

Arbre d’attaque

Arbre dont la racine est l’objectif d’un attaquant et dont les enfants sont les moyens alternatifs (OU) ou combinés (ET) de l’atteindre, popularisé par Bruce Schneier en 1999. Chapitre 8

Arbre d’utilité

Arbre, issu de l’ATAM, qui décompose l’utilité globale en attributs de qualité, puis en scénarios concrets, chacun évalué selon son importance métier et sa difficulté technique. Chapitre 2

arc42

Modèle gratuit en douze sections pour documenter et communiquer une architecture logicielle, créé par Gernot Starke et Peter Hruschka. Chapitre 4

Architecturalement significatif

Qualifie une décision ou une exigence coûteuse à modifier par la suite, qui affecte de nombreuses parties d’un système ou qui détermine un attribut de qualité clé. Chapitre 1

Architecture à base de services (service-based)

Style distribué comprenant quelques services de domaine à gros grain, déployés séparément (généralement de 4 à 12), qui partagent souvent une même base de données ; nommé par Mark Richards et Neal Ford. Chapitre 6

Architecture basée sur l’espace (space-based)

Style architectural qui sert les requêtes à partir de nombreuses unités de traitement identiques conservant les données dans des grilles en mémoire répliquées, et qui met à jour la base de données de façon asynchrone afin qu’elle soit hors du chemin des requêtes. Chapitre 6

Architecture cellulaire (cell-based architecture)

Exploitation de nombreuses copies complètes et indépendantes (cellules) d’un système, chacune servant un sous-ensemble fixe de clients, derrière un routeur léger, de sorte qu’une défaillance n’affecte qu’une seule cellule. Chapitre 10

Architecture de référence

Architecture modèle pour un domaine ou une plateforme, qui répartit les fonctions habituelles sur un ensemble standard de parties, et que les projets adaptent au lieu de tout concevoir de zéro. Chapitre 5

Architecture de solution

Architecture d’une solution à un problème métier donné, qui couvre souvent plusieurs applications, fournisseurs et équipes, par exemple un nouveau processus de déclaration de sinistres en ligne pour un assureur. Chapitre 1

Architecture de transition

Logiciel temporaire, comme des couches de routage, des adaptateurs et des tâches de synchronisation, construit uniquement pour permettre aux anciens et aux nouveaux systèmes de coexister pendant une migration, et retiré une fois celle-ci terminée. Chapitre 11

Architecture distribuée

Architecture composée de plusieurs unités déployées séparément qui coopèrent en s’envoyant des messages par un réseau. Chapitre 5

Architecture d’entreprise

Architecture à l’échelle de toute une organisation : comment ses capacités métier, ses informations, ses applications et sa technologie s’articulent et évoluent dans le temps. Chapitre 1

Architecture en couches

Style qui dispose les composants en couches horizontales, chacune avec un seul rôle technique, où chaque couche n’utilise que les couches situées en dessous. Chapitre 5

Architecture évolutive

Architecture qui permet un changement guidé et incrémental selon plusieurs dimensions, le guidage étant assuré par des fonctions d’aptitude (Ford, Parsons, Kua et Sadalage). Chapitre 11

Architecture logicielle

Les structures fondamentales d’un système logiciel et les décisions importantes qui les ont façonnées : ses parties principales, leurs relations, leurs propriétés importantes et les principes qui guident sa construction et son évolution. Chapitre 1

Architecture micronoyau (microkernel)

Style architectural, aussi appelé architecture à plug-ins, dans lequel un petit système central fournit le flux de travail général et des plug-ins indépendants ajoutent ou modifient des comportements au moyen de contrats publiés. Chapitre 5

Architecture monolithique

Architecture dans laquelle toute l’application est construite et déployée comme une seule unité, quelle que soit sa structure interne. Chapitre 5

Architecture orientée services (SOA)

Approche, dominante dans les grandes entreprises à partir du début des années 2000, qui expose les capacités métier sous forme de services partagés dotés de contrats explicites, généralement reliés par un bus de services d’entreprise. Chapitre 6

Architecture pilotée par les événements

Style dans lequel les composants communiquent en publiant des événements sur ce qui s’est produit et en réagissant aux événements publiés par d’autres, généralement par l’intermédiaire d’un courtier. Chapitre 6

Architecture sociotechnique

Concevoir ensemble la structure du logiciel et celle des équipes, car chacune façonne l’autre. L’idée remonte aux recherches sur les systèmes sociotechniques menées au Tavistock Institute, à commencer par l’étude d’Eric Trist et Ken Bamforth sur les mines de charbon en 1951. Chapitre 11

Ascenseur de l’architecte (architect elevator)

Image de Gregor Hohpe qui présente l’architecte comme quelqu’un qui circule entre le penthouse d’une organisation (stratégie et dirigeants) et sa salle des machines (code et infrastructure), pour relier les deux. Chapitre 11

AsyncAPI

Spécification lisible par machine pour décrire des API pilotées par les messages : les canaux, les opérations qui y envoient ou y reçoivent des messages et les schémas de messages. Chapitre 6

ATAM (Architecture Tradeoff Analysis Method)

Méthode d’évaluation fondée sur des scénarios du SEI (Kazman, Klein et Clements, 2000). En neuf étapes réparties sur deux réunions, elle relie les facteurs métier et les scénarios priorisés aux approches architecturales et produit des risques, des non-risques, des points de sensibilité, des points de compromis et des thèmes de risque. Chapitre 11

Attaque de la chaîne d’approvisionnement logicielle

Attaque qui compromet quelque chose qu’une organisation consomme, comme une dépendance, un outil de build, une mise à jour ou un registre, afin d’atteindre cette organisation et d’autres en aval. Chapitre 8

Attribut de qualité

Propriété mesurable d’un système qui indique dans quelle mesure il remplit bien sa fonction, comme les performances, la disponibilité, la sécurité ou la modifiabilité. Le chapitre 2 les traite en détail. Chapitre 1

Authentification

Vérification qu’un utilisateur ou un système est bien celui ou ce qu’il prétend être, par exemple au moyen d’un mot de passe, d’une passkey ou d’un certificat. Chapitre 8

Authentification multifacteur (MFA)

Authentification qui exige deux types de facteurs différents ou plus : quelque chose que vous savez, quelque chose que vous possédez et quelque chose que vous êtes. Chapitre 8

Autonomie excessive (excessive agency)

Fait de donner à un système d’IA plus d’outils, d’autorisations ou d’autonomie que sa tâche n’en exige, de sorte qu’un modèle manipulé ou qui se trompe peut causer de réels dégâts. Chapitre 12

Autorisation

Décision indiquant si un utilisateur ou un système authentifié a le droit d’effectuer une action particulière sur une ressource particulière. Chapitre 8

Autorité de certification (CA)

Organisation ou système qui émet des certificats numériques en les signant, garantissant qu’une clé publique appartient à un serveur, une personne ou une charge de travail nommés. Chapitre 8

Autoscaling (mise à l’échelle automatique)

Modification automatique du nombre d’instances en fonction de la charge, de façon réactive à partir d’une métrique, selon un calendrier, ou de façon prédictive à partir d’une prévision. Chapitre 9

B

Back pressure (contre-pression)

Moyen pour un consommateur lent d’amener un producteur rapide à ralentir, au lieu de laisser les tampons et les files grossir sans limite. Chapitre 5

Backend en tant que service (BaaS)

Services tiers entièrement managés, comme l’authentification, les bases de données, le stockage et la messagerie, qui remplacent des composants côté serveur qu’une organisation devrait sinon construire et exploiter elle-même. Chapitre 6

Backend for frontend (BFF)

API côté serveur conçue pour un type de client, comme l’app mobile, afin que chaque client reçoive des opérations et des données adaptées à ses propres besoins. Chapitre 3

Backend for frontend (BFF)

Backend léger conçu pour un type de client, comme l’app mobile, qui appelle les services et met en forme leurs données pour ce client. Chapitre 6

Backfill (remplissage rétroactif)

Remplissage d’une nouvelle colonne ou table avec des valeurs pour les lignes existantes, généralement par petits lots afin de ne pas perturber le système en production. Chapitre 7

Backoff exponentiel

Allongement de l’attente entre les nouvelles tentatives successives, généralement en doublant le délai à chaque fois jusqu’à un plafond, afin qu’un service en difficulté ait le temps de se rétablir. Chapitre 9

Bande passante

Quantité de données qu’une connexion peut transporter par seconde, par exemple 100 mégabits par seconde. Une bande passante élevée ne réduit pas la latence. Chapitre 0

Base de données

Collection organisée de données, stockée de façon à pouvoir être interrogée, mise à jour et maintenue cohérente, généralement gérée par un système de gestion de base de données. Chapitre 0

Base de données clé-valeur

Base de données qui stocke des valeurs sous des clés uniques et ne les retrouve que par leur clé, comme un dictionnaire très grand et très rapide. Chapitre 0

Base de données de séries temporelles

Base de données optimisée pour des mesures horodatées qui arrivent dans l’ordre, avec compression, sous-échantillonnage et suppression peu coûteuse des données anciennes. Chapitre 7

Base de données d’intégration

Base de données partagée par plusieurs applications, qui s’intègrent par son intermédiaire en lisant et en écrivant dans les mêmes tables. Martin Fowler (2004) la déconseille parce qu’elle couple profondément les applications. Chapitre 7

Base de données managée

Service de base de données exploité par un fournisseur de cloud, qui prend en charge l’installation, les correctifs, les sauvegardes et le failover, tandis que le client gère le schéma, les requêtes et les accès. Chapitre 0

Base de données orientée documents

Base de données NoSQL qui stocke chaque enregistrement sous forme de document autonome, généralement de type JSON, pouvant contenir des données imbriquées sans devoir partager un schéma fixe. Chapitre 0

Base de données orientée graphe

Base de données qui stocke les éléments sous forme de nœuds et leurs relations sous forme d’arêtes, de sorte que le parcours de chaînes de connexions est rapide. Chapitre 0

Base de données par service

Règle selon laquelle chaque service possède ses données et aucun autre service ne les lit ni ne les écrit directement ; les autres utilisent l’API du propriétaire ou ses événements. Chapitre 6

Base de données relationnelle

Base de données qui stocke les données dans des tables de lignes et de colonnes et relie les tables par des clés. On l’interroge en SQL. Chapitre 0

Base de données vectorielle

Système de stockage pour les embeddings (des listes de nombres représentant le sens) qui trouve les éléments les plus similaires à une requête, généralement au moyen d’index de recherche approximative des plus proches voisins. Chapitre 7

Base orientée colonnes larges (wide-column store)

Base de données NoSQL qui regroupe les données en lignes identifiées par une clé, chacune comportant de nombreuses colonnes, réparties sur de nombreuses machines. Conçue pour de très grands volumes d’écriture. Chapitre 0

Biais algorithmique

Résultats systématiquement moins bons produits par un système automatisé pour certains groupes de personnes, causés par les données, la conception ou le contexte d’utilisation. Chapitre 12

Biais cognitif

Erreur systématique de raisonnement, comme l’ancrage ou le biais des coûts irrécupérables, qui conduit à juger les options de manière injuste. Chapitre 1

Biais d’automatisation

Tendance des personnes à accepter les recommandations d’un système automatisé sans examen suffisant, même lorsqu’elles sont erronées. Chapitre 12

Bibliothèque

Code réutilisable écrit par quelqu’un d’autre, que votre code appelle quand il en a besoin, par exemple une bibliothèque pour les dates ou pour l’envoi d’e-mails. Chapitre 0

Big design up front (BDUF, conception complète en amont)

Approche dans laquelle l’architecture et la conception sont achevées en détail avant le début de l’implémentation. Chapitre 1

Bit

Chiffre binaire, 0 ou 1 : la plus petite unité d’information qu’un ordinateur stocke. Chapitre 0

Bloc de construction (building block)

Dans arc42, toute partie de la structure statique d’un système, comme un sous-système, un service, un composant ou un module, représentée dans la vue des blocs de construction. Chapitre 4

BM25

Fonction de classement classique par mots-clés qui note les documents selon la fréquence à laquelle ils contiennent les termes de la requête, en donnant plus de poids aux termes rares et en normalisant selon la longueur du document. Chapitre 12

Boucle de réconciliation

Le cycle sans fin d’un contrôleur qui observe l’état réel, le compare à l’état souhaité et agit pour supprimer l’écart. Chapitre 10

Branch by abstraction (branchement par abstraction)

Technique pour les modifications de grande ampleur au sein d’une même base de code : placer une abstraction devant la partie à remplacer, y rediriger les appelants, construire la nouvelle implémentation derrière elle, basculer puis supprimer l’ancienne, en gardant le système livrable du début à la fin. Chapitre 11

Branche

Ligne de développement distincte dans la gestion de versions, utilisée pour travailler sur une modification sans affecter la ligne principale jusqu’à ce qu’elle soit prête à être fusionnée. Chapitre 0

Budget de latence

La part d’un objectif de temps de réponse de bout en bout attribuée à chaque étape ou à chaque service sur le chemin d’une requête, afin que chaque équipe connaisse la limite qu’elle doit respecter. Chapitre 11

Budget de nouvelles tentatives (retry budget)

Limite des nouvelles tentatives exprimée en proportion du trafic normal (par exemple 10 %), afin qu’elles aident face aux défaillances occasionnelles sans pouvoir multiplier la charge pendant une panne. Chapitre 9

Budget de performance

Limite convenue sur une mesure de performances, comme le poids d’une page ou la latence p99 par appel de service, qu’un changement ne doit pas dépasser, idéalement vérifiée automatiquement. Chapitre 9

Budget d’erreur (error budget)

Niveau de non-fiabilité qu’un SLO autorise : un moins l’objectif, appliqué à la fenêtre. Un SLO de 99,9 % sur 1 000 000 requêtes autorise 1000 requêtes en échec. Chapitre 9

Bug

Erreur dans un logiciel qui le fait se comporter autrement que prévu, d’un plantage à une réponse silencieusement fausse. Chapitre 0

Bug bounty (programme de prime aux bogues)

Programme qui rémunère des chercheurs externes pour le signalement de vulnérabilités de sécurité avérées selon un processus convenu. Chapitre 8

Build once, deploy many (construire une fois, déployer partout)

Règle selon laquelle une modification est construite une seule fois en un artefact immuable, et ce même artefact est promu dans chaque environnement, seule la configuration changeant. Chapitre 10

Build reproductible (reproducible build)

Build qui produit une sortie identique bit pour bit à partir du même code source et des mêmes entrées, afin que chacun puisse reconstruire un artefact publié et vérifier qu’il n’a pas été altéré. Chapitre 8

Build, release, run (assembler, publier, exécuter)

Séparation stricte entre la transformation du code en artefact (build), sa combinaison avec la configuration d’un environnement (release) et son exécution (run). Chapitre 10

Bus de services d’entreprise (ESB)

Middleware au centre de la SOA classique qui achemine, transforme et sert d’intermédiaire pour les messages entre services, et qui exécute souvent aussi des processus métier. Chapitre 6

Bytecode

Instructions compactes destinées à une machine virtuelle plutôt qu’à un vrai CPU. Java et Python compilent le code source en bytecode, que leurs environnements d’exécution exécutent ensuite sur toute machine prise en charge. Chapitre 0

C

Cache

Copie de données conservée à un endroit plus rapide d’accès, afin que les requêtes répétées évitent un travail lent. Elle échange de la mémoire supplémentaire, et le risque de données périmées, contre de la vitesse. Chapitre 0

Cache sémantique

Renvoyer une réponse stockée lorsqu’une nouvelle requête a un sens proche d’une requête antérieure, ce que l’on juge en comparant des embeddings, sans appeler le modèle. Chapitre 12

Cache stampede (ruée sur le cache)

Afflux de requêtes qui échouent toutes dans le cache au même moment, généralement quand un élément populaire expire, et frappent toutes en même temps la source plus lente ; étroitement lié au problème du troupeau tonitruant (thundering herd). Chapitre 7

Cache write-behind

Patron de mise en cache dans lequel les écritures sont confirmées dès qu’elles atteignent le cache et sont écrites plus tard, en arrière-plan, dans le système de stockage sous-jacent ; on parle aussi de write-back. Chapitre 7

Cache write-through

Patron de mise en cache dans lequel chaque écriture va dans le cache et dans le système de stockage sous-jacent avant d’être confirmée, de sorte que le cache n’est jamais plus ancien que le système de stockage. Chapitre 7

Cache-aside

Patron de mise en cache dans lequel l’application consulte le cache, charge depuis la base de données en cas d’échec et place elle-même le résultat dans le cache ; aussi appelé chargement paresseux (lazy loading). Chapitre 7

Cadre de description d’architecture

Dans ISO/IEC/IEEE 42010:2022, ensemble établi de conventions pour produire des descriptions d’architecture, comme des points de vue, des modèles et des règles. Chapitre 4

Cadre SPACE

Cadre de 2021 pour la productivité des développeurs, qui couvre la satisfaction et le bien-être, la performance, l’activité, la communication et la collaboration, ainsi que l’efficacité et le flux. Chapitre 10

Calendrier de conservation

Liste documentée indiquant combien de temps chaque catégorie de données est conservée, pourquoi, et ce qu’il en advient à la fin de cette période. Chapitre 8

Canary release (déploiement canari)

Envoi d’abord d’une petite part du trafic réel vers une nouvelle version, comparaison de son comportement avec celui de l’ancienne version, et élargissement de cette part uniquement si elle est saine. Chapitre 10

Canaux de communication

Liens individuels possibles entre les membres d’un groupe. Un groupe de n personnes en compte n(n-1)/2, de sorte que leur nombre croît à peu près comme le carré de la taille du groupe. Chapitre 3

Capacité spot

Capacité cloud excédentaire vendue avec une forte remise, que le fournisseur peut reprendre à bref délai ; ne convient qu’aux travaux qui tolèrent une interruption. Chapitre 10

Capture des données modifiées (CDC)

Lecture du journal de modifications ou de réplication propre à une base de données pour diffuser en flux chaque insertion, mise à jour et suppression validée vers d’autres systèmes. Debezium est une plateforme CDC open source très utilisée. Chapitre 6

Caractéristique d’architecture

Terme de Richards et Ford pour un attribut de qualité que l’architecture doit prendre en charge, comme la scalabilité, la déployabilité ou la tolérance aux pannes. Chapitre 5

Carbone incorporé (embodied carbon)

Gaz à effet de serre émis lors de la fabrication, du transport et de l’élimination du matériel, par opposition aux émissions liées à l’électricité qu’il consomme pendant son fonctionnement. Chapitre 11

Cardinalité

Nombre de valeurs distinctes qu’un champ peut prendre ; pour les métriques, nombre de combinaisons distinctes d’étiquettes, chacune devenant une série temporelle distincte à stocker. Chapitre 9

Carte de contextes (context map)

Représentation des contextes délimités d’un système et des relations entre eux, comme client-fournisseur ou couche anticorruption, qui couvre à la fois les relations d’intégration et les relations entre équipes. Chapitre 5

Cascade de modèles

Conception qui envoie d’abord une requête à un modèle moins coûteux et ne passe à un modèle plus performant que lorsqu’une vérification indique que la première réponse n’est pas assez bonne. Chapitre 12

CBAM (Cost Benefit Analysis Method)

Méthode du SEI qui prolonge l’ATAM en estimant le bénéfice de chaque stratégie architecturale à partir de l’utilité qu’elle ajoute aux scénarios priorisés, puis en le divisant par son coût pour comparer le rapport valeur-coût. Chapitre 11

Centre de données

Bâtiment conçu pour héberger de nombreux serveurs avec une alimentation électrique fiable, un refroidissement, une sécurité physique et des connexions réseau. Chapitre 0

Changement cassant (breaking change)

Modification d’une API qui fait cesser de fonctionner du code client existant et correct, comme le fait de renommer ou de supprimer un champ. Chapitre 0

Changement rétrocompatible

Modification d’une interface ou d’un schéma que les consommateurs existants peuvent supporter sans être modifiés, comme l’ajout d’un champ facultatif. Supprimer ou renommer un champ est un changement cassant. Chapitre 6

Charge cognitive

Quantité d’effort mental qu’une personne ou une équipe doit fournir pour comprendre un système et travailler dans son cadre ; Team Topologies s’en sert pour dimensionner les responsabilités des équipes. Chapitre 10

Charge cognitive de l’équipe

La quantité totale de connaissances et d’effort mental dont une équipe a besoin pour construire, exploiter et modifier les parties d’un système qui lui appartiennent. Lorsqu’elle dépasse la capacité de l’équipe, la qualité et la vitesse baissent. Chapitre 3

Chargeback (refacturation interne)

Imputation au budget de chaque équipe ou produit des coûts qui lui sont attribués, afin que les dépenses apparaissent dans ses propres comptes. Chapitre 10

Chiffrement d’enveloppe (envelope encryption)

Chiffrement des données avec une clé de données, puis chiffrement (encapsulation) de cette clé de données avec une clé de chiffrement de clés détenue dans un KMS, de sorte que les données volumineuses ne transitent jamais par le KMS et que les clés peuvent être renouvelées à peu de frais. Chapitre 8

Chiffrement symétrique

Chiffrement dans lequel la même clé secrète sert à chiffrer et à déchiffrer, comme AES ; rapide, il est donc utilisé pour les gros volumes de données. Chapitre 8

Chorégraphie

Coordination d’un processus en plusieurs étapes par des participants qui réagissent aux événements des uns et des autres, sans qu’aucun composant unique ne dirige l’ensemble. Chapitre 6

Chunking (découpage en fragments)

Découpage des documents en passages suffisamment petits pour être indexés, retrouvés et placés dans un prompt, idéalement en suivant la structure propre des documents. Chapitre 12

Classe et objet

Une classe est un modèle qui regroupe des données et les fonctions (méthodes) qui opèrent sur elles ; un objet est une instance créée à partir de ce modèle, comme le compte d’un client donné. Chapitre 0

Clé d’API

Longue chaîne secrète qui identifie l’application appelante auprès d’une API. Quiconque détient la clé peut agir en tant que cette application ; elle doit donc rester secrète. Chapitre 0

Clé d’idempotence

Valeur unique qu’un client envoie avec une requête non idempotente, comme POST, afin que le serveur puisse reconnaître une nouvelle tentative de la même opération et renvoyer le résultat d’origine au lieu d’effectuer le travail deux fois. Chapitre 6

Clé étrangère

Colonne d’une table qui contient la clé primaire d’une ligne d’une autre table, ce qui relie les deux. La base de données peut refuser les valeurs qui ne renvoient à rien. Chapitre 0

Clé primaire

Colonne, ou ensemble de colonnes, dont la valeur identifie de manière unique chaque ligne d’une table, comme customer_id. Chapitre 0

Cloisonnement (bulkhead)

Partitionnement de ressources comme les pools de threads, les pools de connexions ou les instances, afin qu’une défaillance ou une surcharge dans une partie ne puisse pas consommer les ressources des autres. Chapitre 9

Cloud computing (informatique en nuage)

Location de ressources informatiques (serveurs, stockage, bases de données et autres services) par internet, à la demande, en payant ce que l’on utilise. Chapitre 0

Cloud hybride

Combinaison de cloud privé et de cloud public (ou de systèmes sur site) reliés de sorte que les données et les applications puissent fonctionner de l’un à l’autre. Chapitre 10

Cloud native

Approche consistant à construire et exploiter des logiciels sous forme de systèmes faiblement couplés, automatisés, observables et résilients, déployés de manière programmatique et reproductible, dans des clouds publics, privés ou hybrides. Elle décrit comment un système est construit, et non où il s’exécute. Chapitre 10

Cloud privé

Infrastructure cloud dédiée à une seule organisation, offrant un provisionnement en libre-service piloté par API ; elle peut être sur site ou hébergée par un tiers. Chapitre 10

Code d’état HTTP

Nombre à trois chiffres présent dans chaque réponse HTTP, qui indique comment s’est déroulée la requête : 2xx succès, 3xx redirection, 4xx problème dans la requête, 5xx problème du côté du serveur. Chapitre 0

Code d’éthique de l’ACM (ACM Code of Ethics)

Code d’éthique et de conduite professionnelle de l’Association for Computing Machinery, mis à jour en 2018, dont les principes comprennent la contribution à la société, le fait d’éviter de nuire, l’honnêteté, l’équité, le respect de la vie privée et la confidentialité. Chapitre 11

Code machine

Instructions codées sous forme de nombres qu’une famille donnée de CPU peut exécuter directement. Le code machine d’une famille (par exemple x86-64) ne s’exécute pas sur une autre (par exemple Arm). Chapitre 0

Code mort

Code qui n’est plus censé s’exécuter mais qui est toujours présent dans le système déployé, où il peut être déclenché par erreur. Chapitre 1

Code source

Le texte lisible par l’humain d’un programme, écrit dans un langage de programmation comme Python ou Java, qui est ensuite compilé ou interprété pour qu’un ordinateur puisse l’exécuter. Chapitre 0

Cohérence à terme (eventual consistency)

Garantie que des copies de données qui ne sont plus mises à jour convergeront vers la même valeur au bout d’un certain temps, les lecteurs pouvant voir des valeurs périmées dans l’intervalle. Chapitre 6

Cohérence causale

Modèle de cohérence dans lequel les opérations liées causalement (l’une a pu influencer l’autre) sont vues dans le même ordre par tous ; les opérations concurrentes sans lien peuvent être vues dans des ordres différents. Chapitre 6

Cohérence séquentielle

Modèle de cohérence dans lequel tous les clients voient les opérations dans un ordre unique convenu qui préserve l’ordre propre à chaque client, mais cet ordre n’a pas à correspondre au temps réel. Chapitre 6

Cohésion

Degré auquel le contenu d’une partie d’un système forme un tout. Une forte cohésion signifie qu’un module accomplit une seule tâche claire. Chapitre 0

Collision de données

Dans un cache en mémoire répliqué, situation où deux unités mettent à jour le même élément avant que la réplication ait propagé la première mise à jour, de sorte qu’une mise à jour écrase l’autre. Chapitre 6

Comité de revue d’architecture

Groupe permanent d’architectes expérimentés qui examine et approuve les conceptions importantes, généralement à des étapes fixées d’un projet. Il peut apporter un jugement indépendant mais devient souvent un point de passage lent. Chapitre 11

Commande

Message demandant à un gestionnaire précis de faire quelque chose, comme AuthorisePayment. Contrairement à un événement, elle peut être refusée. Chapitre 6

Commit

Instantané enregistré de modifications dans la gestion de versions, avec un auteur, un horodatage et un message expliquant la modification. Chapitre 0

Communication asynchrone

Interaction dans laquelle l’émetteur confie un message à un intermédiaire, comme un courtier de messages (message broker), et poursuit son travail sans attendre ; le destinataire le traite quand il est prêt. Chapitre 6

Communication synchrone

Interaction dans laquelle l’appelant envoie une requête et attend la réponse avant de continuer, comme lors d’un appel téléphonique. Les deux parties doivent être disponibles au même moment. Chapitre 6

Compatibilité future (forward compatibility)

Une modification de schéma est compatible vers l’avant lorsque le code utilisant l’ancien schéma peut encore lire les données écrites avec le nouveau, généralement en ignorant les champs qu’il ne connaît pas. Chapitre 7

Compilateur

Programme qui traduit le code source sous une autre forme, comme du code machine ou du bytecode, avant l’exécution du programme. Chapitre 0

Complexité accidentelle

Complexité introduite par la manière dont une solution est construite (outils, structure, contournements) plutôt que par le problème lui-même. Elle peut en principe être éliminée. Chapitre 3

Complexité cyclomatique

Mesure proposée par Thomas McCabe en 1976 du nombre de chemins indépendants à travers un morceau de code, calculée à partir de son graphe de flot de contrôle ; pour du code simple, elle est égale au nombre de décisions plus un. Chapitre 3

Complexité essentielle

Complexité propre au problème lui-même, comme les règles réelles de la fiscalité ou de l’assurance, qui ne peut être éliminée sans changer ce que fait le système. Chapitre 3

Composant

Unité qui existe lorsque le système s’exécute, comme un service, un processus ou une base de données, et qui interagit avec d’autres composants par l’intermédiaire de connecteurs. Chapitre 1

Composant (C4)

Dans le modèle C4, groupe de fonctionnalités liées derrière une interface claire, s’exécutant à l’intérieur d’un conteneur et déployé avec lui. Chapitre 4

Composant de vue

Dans l’ISO/IEC/IEEE 42010:2022, une partie d’une vue, comme un diagramme, un tableau ou un modèle, régie par un type de modèle. L’édition de 2011 l’appelait modèle d’architecture. Chapitre 4

Compromis

Choix dans lequel obtenir un avantage implique d’accepter un coût ou de renoncer à un autre avantage, par exemple une livraison plus rapide au prix d’un coût d’exploitation plus élevé. Chapitre 1

Compteur (counter)

Métrique dont la valeur ne fait qu’augmenter (ou revient à zéro au redémarrage), comme le nombre total de requêtes servies ; on examine généralement son taux d’augmentation. Chapitre 9

Concept transversal

Règle ou solution qui s’applique à de nombreuses parties d’un système, comme la sécurité, la gestion des erreurs, la journalisation ou la persistance. Chapitre 4

Conception détaillée

Décisions portant sur l’intérieur d’une partie d’un système (ses classes, fonctions, algorithmes et structures de données locales), qui peuvent être modifiées sans affecter le reste. Chapitre 1

Conception émergente

Approche dans laquelle la conception se développe de manière incrémentale, façonnée par les besoins de chaque nouvelle fonctionnalité et par une refactorisation continue. Chapitre 1

Conception par contrat

Méthode de Bertrand Meyer consistant à spécifier chaque opération par des préconditions que l’appelant doit remplir, des postconditions que l’opération garantit et des invariants toujours vrais. Chapitre 3

Conception pilotée par le domaine (DDD)

Approche introduite par Eric Evans en 2003 qui construit le logiciel autour d’un modèle du domaine métier, élaboré avec les experts du domaine, et qui divise les grands domaines en modèles explicitement délimités. Chapitre 5

Connascence

Deux éléments sont connascents si la modification de l’un exigerait la modification de l’autre pour que le système reste correct. Manière plus fine de décrire le couplage, introduite par Meilir Page-Jones. Chapitre 3

Connascence dynamique

Connascence qui n’apparaît qu’à l’exécution du programme, comme la dépendance à l’ordre ou au moment d’exécution, à des valeurs liées ou au partage d’une même instance d’objet par deux parties. Chapitre 3

Connascence statique

Connascence visible dans le code source sans l’exécuter, comme l’accord sur un nom, un type, la signification d’une valeur, l’ordre des paramètres ou un algorithme. Chapitre 3

Connecteur

Mécanisme d’exécution par lequel les composants interagissent : un appel HTTP, une file de messages, une base de données partagée, un flux d’événements ou un appel de fonction. Chapitre 1

Consensus

Règle de décision dans laquelle le groupe poursuit la discussion jusqu’à ce que tout le monde approuve activement la proposition, ou du moins la soutienne ; inclusive mais lente, et sujette à l’impasse dans les grands groupes. Chapitre 11

Consensus approximatif (rough consensus)

Décision obtenue lorsque chaque objection a été examinée et a reçu une réponse, sans nécessairement avoir été prise en compte ; décrite dans la RFC 7282 de l’IETF. Chapitre 4

Consommateur idempotent

Destinataire de messages qui enregistre quels messages il a traités, dans la même transaction que leurs effets, de sorte que les doublons ne changent rien. Chapitre 6

Consommateurs concurrents (competing consumers)

Patron dans lequel plusieurs workers lisent la même file et chaque message n’est traité que par l’un d’eux, de sorte que le débit augmente en ajoutant des workers. Chapitre 9

Conteneur

Application empaquetée avec ses bibliothèques et ses paramètres, exécutée comme un processus isolé qui partage le noyau du système d’exploitation de l’hôte. Plus légère et plus rapide à démarrer qu’une machine virtuelle. Chapitre 0

Conteneur (C4)

Dans le modèle C4, unité exécutable ou déployable séparément qui exécute du code ou stocke des données, comme une application web, une app mobile, un service ou une base de données. Ce n’est pas un conteneur Docker. Chapitre 4

Conteneurs en tant que service (CaaS)

Service cloud qui exécute des images de conteneur pour vous, soit sous forme de Kubernetes managé, soit sous forme de plateforme de conteneurs serverless où vous ne voyez jamais les machines. Chapitre 10

Contexte délimité (bounded context)

Frontière explicite à l’intérieur de laquelle un modèle de domaine et son langage omniprésent s’appliquent de façon cohérente ; en dehors, les mêmes mots peuvent signifier autre chose. Chapitre 5

Contrainte

Décision de conception déjà prise pour vous, ne laissant aucune ou très peu de liberté, comme un langage de programmation imposé, une réglementation, une échéance fixe ou un budget. Chapitre 2

Contrat de données

Accord explicite et versionné entre le propriétaire de données et ses consommateurs, couvrant le schéma, la signification, la qualité, la fraîcheur, la propriété et la manière dont les modifications sont annoncées. Chapitre 7

Contrat de plug-in

L’interface publiée entre un système central et ses plug-ins : les opérations, les types de données, le comportement en cas d’erreur et la version sur lesquels les deux parties s’accordent. Chapitre 5

Contrat d’API

Promesse documentée que fait une API : quelles requêtes elle accepte, ce que chacune renvoie, quelles erreurs peuvent survenir et ce qui ne changera pas sans préavis. Chapitre 0

Contrat piloté par le consommateur (consumer-driven contract)

Contrat constitué à partir de ce que chaque consommateur utilise réellement de l’API d’un fournisseur ; le fournisseur exécute les attentes de tous ses consommateurs dans son propre build pour savoir quelles modifications casseraient qui. Chapitre 6

Contre-mesure de saga

Technique de conception qui réduit les anomalies dues au manque d’isolation des sagas, comme un verrou sémantique (un état PENDING), des mises à jour commutatives ou la relecture d’une valeur avant de la mettre à jour. Chapitre 6

Contrôle de concurrence multiversion (MVCC)

Technique dans laquelle les écritures créent de nouvelles versions des lignes au lieu de les écraser, de sorte que les lecteurs voient un instantané cohérent sans bloquer les écrivains. Chapitre 7

Contrôle de concurrence optimiste

Détecter les conflits au lieu de les empêcher : une écriture ne réussit que si un numéro de version ou un horodatage n’a pas changé depuis la lecture des données ; sinon, l’écrivain fait une nouvelle tentative. Chapitre 7

Contrôle de santé (health check)

Test périodique, comme une requête HTTP vers un endpoint d’état, qu’un équilibreur de charge ou un orchestrateur utilise pour décider si une instance doit recevoir du trafic ou être redémarrée. Chapitre 9

Contrôle d’accès basé sur les attributs (ABAC)

Décision d’accès prise en évaluant une politique portant sur des attributs de l’utilisateur, de la ressource, de l’action et du contexte, comme le pays, la classification des données ou l’heure de la journée. Chapitre 8

Contrôle d’accès basé sur les relations (ReBAC)

Décider des accès à partir des relations entre utilisateurs et objets (propriétaire de, membre de, travaille chez), stockées sous forme de graphe ; Zanzibar de Google (2019) en est l’exemple le plus connu. Chapitre 8

Contrôle d’accès basé sur les rôles (RBAC)

Attribuer des permissions à des rôles et des rôles à des utilisateurs, de sorte que les accès se gèrent en affectant les personnes à des rôles comme agent du support ou gérant de restaurant. Chapitre 8

Contrôle humain

Dispositifs qui permettent à des personnes de surveiller, d’approuver, d’annuler ou d’arrêter les décisions d’un système d’IA. Chapitre 12

Contrôles hypermédias (HATEOAS)

Liens dans une réponse d’API qui indiquent au client quelles actions il peut effectuer ensuite, de sorte que le client suit des liens plutôt que de construire lui-même les URL. Niveau 3 du modèle de maturité de Richardson. Chapitre 6

Cooldown (période de stabilisation)

Période qui suit une action de mise à l’échelle, pendant laquelle l’autoscaler attend avant d’agir à nouveau, afin de pouvoir mesurer l’effet de la dernière modification. Chapitre 9

Coordinateur d’incident (incident commander)

Personne qui coordonne la réponse à un incident : elle fixe les priorités, attribue les rôles et prend les décisions, plutôt que de réparer elle-même. Chapitre 9

Correspondance

Relation consignée entre des éléments d’une description d’architecture, par exemple entre un conteneur dans une vue et le serveur sur lequel il s’exécute dans une autre. Chapitre 4

Couche

Groupe de composants ayant la même responsabilité technique, qui offre des services à la couche du dessus et utilise la couche du dessous. Chapitre 5

Couche anticorruption

Couche de traduction, issue de la conception pilotée par le domaine, qui convertit entre le modèle d’un autre système et le vôtre, afin que les concepts et les bizarreries de l’autre modèle ne s’infiltrent pas dans votre code. Chapitre 11

Couche anticorruption

Couche de traduction qu’un contexte en aval construit pour que le modèle d’un autre contexte ou système ne puisse pas s’infiltrer dans le sien. Chapitre 5

Couche fermée

Couche que chaque requête doit traverser : la couche supérieure ne peut pas la sauter pour appeler directement une couche inférieure. Chapitre 5

Couche ouverte

Couche que la couche du dessus est autorisée à contourner, généralement une couche de services partagés dont seules certaines requêtes ont besoin. Chapitre 5

Couches d’isolation

Propriété selon laquelle un changement à l’intérieur d’une couche ne se propage pas aux autres couches tant que son interface reste la même ; elle suppose que les couches soient fermées. Chapitre 5

Couplage

Degré auquel une partie d’un système dépend des détails d’une autre. Un couplage faible signifie qu’une modification dans une partie impose rarement des modifications ailleurs. Chapitre 0

Couplage afférent (Ca)

Nombre d’éléments extérieurs à un composant qui dépendent de lui : ses dépendances entrantes. Un Ca élevé signifie que beaucoup d’autres éléments sont affectés s’il change. Chapitre 3

Couplage de changement

Deux fichiers ou composants ou plus qui ont tendance à changer dans les mêmes commits, révélant une dépendance qui peut ne pas être visible dans le code. Chapitre 1

Couplage de déploiement

Situation dans laquelle deux parties doivent être publiées ensemble, ou dans un ordre fixe, parce qu’une modification de l’une casse l’autre. Chapitre 3

Couplage efférent (Ce)

Nombre d’éléments extérieurs à un composant dont il dépend : ses dépendances sortantes. Un Ce élevé signifie qu’il est exposé aux modifications de nombreux autres. Chapitre 3

Couplage sémantique

Dépendance à une signification ou à des règles métier partagées qui n’apparaît dans aucune interface, par exemple deux services qui doivent s’accorder sur ce que signifie « client actif ». Chapitre 3

Couplage temporel

Dans les systèmes distribués, la dépendance au fait qu’une autre partie soit disponible et réactive au même moment, comme avec un appel synchrone. Ailleurs, le terme peut désigner un ordre d’appels imposé ou (dans l’analyse de la gestion de versions) des fichiers qui changent ensemble, ce que ce chapitre appelle couplage de changement. Chapitre 3

Coût de migration (switching cost)

L’effort, l’argent et le risque totaux nécessaires pour passer d’une technologie ou d’un fournisseur à un autre. Chapitre 10

Coût du changement

Effort, argent, temps et risque nécessaires pour modifier une décision une fois que du travail a été construit dessus. Chapitre 1

Coût du retard (cost of delay)

Valeur perdue pour chaque unité de temps pendant laquelle un travail n’est pas livré ; Don Reinertsen l’a popularisé comme moyen de prioriser le travail selon des critères économiques. Chapitre 11

Coût unitaire

Le coût d’exploitation d’un système divisé par une unité de travail utile, comme le coût par commande ou par utilisateur actif, afin de pouvoir suivre l’efficacité à mesure que l’activité croît. Chapitre 2

CPU (processeur)

Unité centrale de traitement : la puce qui exécute les instructions d’un programme, une étape simple à la fois, des milliards de fois par seconde. Les CPU modernes comportent plusieurs cœurs qui travaillent en parallèle. Chapitre 0

CQRS

Command query responsibility segregation (séparation des responsabilités de commande et de requête) : utilisation de modèles distincts, et souvent de stockages distincts, pour mettre à jour les données et pour les lire. Chapitre 6

Crédit de service

Remboursement ou remise dû à un client au titre d’un SLA lorsque le fournisseur n’atteint pas un niveau de service promis. Chapitre 9

Crypto-shredding (effacement cryptographique)

Fait de rendre des données illisibles en détruisant la clé de chiffrement qui les protège, utilisé pour effacer des données à caractère personnel de journaux et de sauvegardes qui ne peuvent pas être modifiés. Chapitre 7

Cryptographie asymétrique (à clé publique)

Cryptographie fondée sur une paire de clés : une clé publique que tout le monde peut détenir et une clé privée gardée secrète ; utilisée pour l’échange de clés, les signatures numériques et les certificats. Chapitre 8

Cube de scalabilité (scale cube)

Le modèle d’Abbott et Fisher décrivant trois façons de passer à l’échelle : l’axe X (copies identiques derrière un équilibreur de charge), l’axe Y (découpage par fonction) et l’axe Z (découpage par données, par exemple par client). Chapitre 5

Culture sans reproche (blameless)

Approche dans laquelle les personnes impliquées dans un incident peuvent décrire ce qu’elles ont fait et pourquoi sans crainte de sanction, afin que l’organisation apprenne comment le système fonctionne réellement. Chapitre 9

CVE

Common Vulnerabilities and Exposures : programme qui attribue à chaque vulnérabilité publiquement connue un identifiant unique, comme CVE-2021-44228. Chapitre 8

CVSS

Common Vulnerability Scoring System, maintenu par FIRST, qui évalue la gravité d’une vulnérabilité connue de 0 à 10 ; la version 4.0 a été publiée en 2023. Chapitre 8

Cycle de dépendances

Boucle dans laquelle des modules dépendent les uns des autres directement ou indirectement, de sorte qu’aucun ne peut être compris, testé ou publié seul. Chapitre 1

D

Dark launching (lancement masqué)

Appel d’un nouveau comportement côté backend en production avec du trafic réel, tout en masquant ses résultats aux utilisateurs, afin de tester les performances et l’exactitude avant une mise en production visible. Chapitre 11

Dark pattern (interface truquée)

Interface utilisateur conçue pour tromper les personnes ou faire pression sur elles afin qu’elles fassent des choix qu’elles ne feraient pas autrement, comme des coûts cachés ou des abonnements difficiles à résilier ; Harry Brignull a créé le terme en 2010 et parle aujourd’hui de deceptive patterns (patrons trompeurs). Chapitre 11

Data lake (lac de données)

Stockage vaste et bon marché, généralement du stockage objet, qui conserve sous leur forme d’origine des données brutes provenant de nombreuses sources pour une analyse ultérieure. Chapitre 7

Data mesh

Approche de Zhamak Dehghani pour les données analytiques, dans laquelle les équipes de domaine possèdent et publient leurs données sous forme de produits sur une plateforme en libre-service, sous une gouvernance fédérée. Chapitre 7

Débit (throughput)

La quantité de travail qu’un système accomplit par unité de temps, par exemple 1200 requêtes par seconde ou 40 000 commandes par heure. Chapitre 2

Décomposition

Découpage d’un système en parties (modules) et attribution des responsabilités de chaque partie. Le critère de découpage compte davantage que le nombre de parties. Chapitre 3

Découverte de services

Mécanisme, comme un registre ou le DNS, par lequel les clients trouvent les adresses réseau actuelles des instances de service en bonne santé. Chapitre 6

Défaillance (failure)

Événement au cours duquel le service rendu par un système s’écarte de ce qu’il devrait être, d’une manière que ses utilisateurs peuvent observer. Chapitre 2

Défaillance en cascade

Défaillance qui se propage : un composant lent ou défaillant fait attendre ses appelants, qui épuisent leurs propres ressources et défaillent à leur tour, et ainsi de suite en remontant la chaîne. Chapitre 6

Défaillance partielle

Situation dans laquelle certaines parties d’un système distribué fonctionnent tandis que d’autres sont en défaillance, lentes ou injoignables, souvent sans que les parties qui fonctionnent puissent savoir lesquelles. Chapitre 6

Défense en profondeur

Superposition de plusieurs contrôles indépendants de sorte qu’un attaquant qui en déjoue un se heurte encore aux autres, par exemple une vérification au niveau de la passerelle, une vérification au niveau du service et le chiffrement des données elles-mêmes. Chapitre 8

Dégradation gracieuse

Maintien des fonctions les plus importantes lorsqu’une partie d’un système tombe en panne, au lieu d’une panne totale, par exemple une boutique qui continue de prendre des commandes pendant que les recommandations sont hors service. Chapitre 2

Degré (de connascence)

Nombre d’éléments qui partagent une connascence donnée. Une valeur convenue entre deux fonctions est bien plus facile à modifier qu’une valeur convenue entre quarante services. Chapitre 3

Degré d’abstraction (A)

Métrique de Martin : nombre de classes abstraites et d’interfaces d’un composant divisé par son nombre total de classes, de 0 (entièrement concret) à 1 (entièrement abstrait). Chapitre 3

Délai de récupération (payback period)

Le temps nécessaire pour que les bénéfices cumulés remboursent le coût d’un investissement ; le délai de récupération actualisé fait de même avec des flux de trésorerie actualisés. Chapitre 11

Délai d’expiration (timeout)

Le temps maximal qu’un appelant attend une opération avant d’abandonner et de la considérer comme échouée ; chaque appel distant en a besoin. Chapitre 9

Délai jusqu’au premier token (TTFT)

Le délai entre l’envoi d’une requête à un modèle et la réception du premier token de sa réponse. Chapitre 12

Délestage de charge (load shedding)

Rejeter délibérément certaines requêtes, à moindre coût et tôt, lorsqu’un système est surchargé, afin que les requêtes qu’il accepte aboutissent encore dans les temps. Chapitre 9

Démarrage à froid (cold start)

Délai supplémentaire lorsqu’une plateforme serverless doit créer et initialiser une nouvelle instance de fonction avant de traiter une requête, de quelques dizaines de millisecondes à plusieurs secondes. Chapitre 6

Dépendance

Tout logiciel dont votre code a besoin pour fonctionner, comme une bibliothèque, un framework ou un autre service. S’il change ou tombe en panne, votre code peut tomber en panne lui aussi. Chapitre 0

Dépendance au fournisseur (lock-in)

Le coût et la difficulté de quitter un fournisseur, un produit, une plateforme ou une technologie une fois qu’un système en dépend. Chapitre 10

Dépendance transitive

Paquet que votre logiciel utilise indirectement parce que l’une de vos dépendances, ou l’une des leurs, en dépend. Chapitre 8

Déploiement bleu-vert (blue-green)

Exploitation de deux environnements de production complets et bascule de tout le trafic de l’ancien (bleu) vers le nouveau (vert) en une seule fois, en gardant l’ancien prêt pour un retour instantané. Chapitre 10

Déploiement continu

Mise en production automatique de chaque modification qui passe le pipeline, sans étape d’approbation manuelle. Chapitre 0

Déploiement progressif (rolling deployment)

Remplacer les instances d’un service quelques-unes à la fois, de sorte que l’ancienne et la nouvelle version tournent côte à côte jusqu’à ce que toutes les instances exécutent la nouvelle version. Chapitre 10

Déployabilité

Rapidité, sûreté et prévisibilité avec lesquelles une modification peut être mise en production, puis retirée si nécessaire. Chapitre 2

Déployabilité indépendante

Capacité à modifier un service et à le mettre en production sans modifier, tester ou mettre en production un autre service en même temps. Chapitre 6

Deployment (Kubernetes)

Objet Kubernetes qui déclare combien de pods identiques d’une application sans état doivent s’exécuter et qui déploie progressivement les nouvelles versions au moyen de ReplicaSets. Chapitre 10

Dépôt d’artefacts

Stockage pour des produits construits et versionnés, comme des images de conteneur et des paquets, à partir duquel chaque environnement déploie le même fichier. Chapitre 10

Député confus (confused deputy)

Programme qui détient une autorité et que l’on amène par la ruse à l’utiliser pour le compte de quelqu’un qui n’a pas cette autorité (Norm Hardy, 1988). Chapitre 12

Dérive (drift)

Évolution progressive des entrées d’un système d’IA, de ses sources de connaissances, du monde ou du modèle lui-même, qui rend ses résultats moins exacts au fil du temps sans aucune modification du code. Chapitre 12

Dérive de configuration

Écarts qui s’accumulent entre la configuration prévue dans le code et l’infrastructure réelle, généralement à cause de modifications manuelles ou de mises à jour partielles. Chapitre 10

Dérive de l’architecture

Modifications faites sans connaissance de l’architecture prévue qui, sans enfreindre de règles explicites, éloignent le système de celle-ci et brouillent ses concepts. Chapitre 1

Dernier moment responsable

Le point à partir duquel retarder davantage une décision supprimerait une option importante ; décider à ce moment-là permet de disposer du maximum d’informations sans causer de tort. Chapitre 1

Description de la conception logicielle (SDD)

Document décrivant en détail une conception logicielle, dont le contenu est spécifié par la norme IEEE Std 1016-2009 ; courant dans les projets régis par un contrat. Chapitre 4

Description d’architecture

Produit de travail (documents, diagrammes, modèles, enregistrements de décisions) qui exprime une architecture. L’architecture existe qu’elle soit décrite ou non ; la description est la manière dont les personnes la partagent. Chapitre 1

Dette architecturale

Dette technique dans la structure d’un système, comme de mauvaises frontières, une base de données partagée ou des dépendances cycliques, coûteuse à rembourser parce qu’elle touche de nombreuses parties. Chapitre 1

Dette technique

Le surcoût futur des changements causé par des raccourcis ou par une conception qui n’est plus adaptée, payé sous forme d’un travail plus lent et plus risqué jusqu’à ce qu’il soit remboursé en améliorant la conception. Chapitre 1

Développement basé sur le tronc (trunk-based development)

Façon de travailler dans laquelle les développeurs intègrent de petits changements dans une branche principale partagée au moins une fois par jour, au lieu de conserver des branches de fonctionnalité de longue durée. Chapitre 10

DevOps

Culture et ensemble de pratiques dans lesquels le développement et l’exploitation travaillent comme une seule équipe, en partageant la responsabilité de la construction, de la mise en production et de l’exploitation du logiciel, avec l’appui de l’automatisation et de la mesure. Chapitre 0

Diagramme de conteneurs

Diagramme C4 montrant les applications, les services et les stockages de données à l’intérieur d’un système, avec leurs technologies et la manière dont ils communiquent. Chapitre 4

Diagramme de contexte système

Diagramme C4 qui montre un système sous la forme d’une seule boîte, les personnes qui l’utilisent et les autres systèmes avec lesquels il interagit. Chapitre 4

Diagramme de déploiement

Diagramme (en C4 ou en UML) montrant comment le logiciel est mis en correspondance avec l’infrastructure dans un environnement, y compris les nœuds, les réplicas et les chemins réseau. Chapitre 4

Diagramme de flux de données (DFD)

Diagramme des entités externes, des processus, des stockages de données et des flux de données entre eux, avec des frontières de confiance tracées en travers des flux ; le modèle habituel pour la modélisation des menaces. Chapitre 8

Diagramme de séquence

Diagramme UML qui montre les messages échangés entre des participants au fil du temps pour un scénario, le temps s’écoulant du haut vers le bas de la page. Chapitre 4

Diagramme dynamique

Diagramme C4 complémentaire montrant comment les éléments collaborent à l’exécution dans un scénario donné, généralement sous forme d’interactions numérotées. Chapitre 4

Diagramme d’activité

Diagramme UML qui représente un flux de travail sous forme d’actions, de décisions, de bifurcations et de jonctions parallèles, souvent divisé en couloirs (swimlanes) indiquant qui fait quoi. Chapitre 4

Diagramme d’états-transitions

Diagramme UML qui montre les états dans lesquels un objet peut se trouver et les transitions entre eux, chacune déclenchée par un événement. Chapitre 4

Diagrammes en tant que code (diagrams as code)

Écriture de diagrammes sous forme de texte dans un petit langage, comme PlantUML, Mermaid, D2 ou Structurizr DSL, qu’un outil met en page et dessine. Chapitre 4

Dictionnaire (map)

Structure de données qui stocke des valeurs sous des clés uniques, de sorte qu’une valeur puisse être trouvée directement par sa clé, généralement en un temps à peu près constant. Aussi appelée map ou table de hachage. Chapitre 0

Disagree and commit (exprimer son désaccord, puis s’engager)

Norme selon laquelle chacun exprime ouvertement son désaccord avant une décision, puis s’engage pleinement à la mettre en œuvre une fois qu’elle est prise. Chapitre 11

Disjoncteur (circuit breaker)

Enveloppe autour des appels à une dépendance qui, après un nombre suffisant de défaillances, cesse de l’appeler pendant un temps et échoue rapidement, puis laisse passer des appels d’essai pour tester le rétablissement (Michael Nygard, 2007). Chapitre 9

Disponibilité

Proportion du temps, ou des requêtes, pendant laquelle un système est prêt à fournir son service lorsqu’on le sollicite, généralement exprimée en pourcentage, par exemple 99,9 %. Chapitre 2

DNS

Domain Name System : le service d’annuaire d’internet, qui transforme des noms comme www.example.com en adresses IP. Chapitre 0

Docker

Ensemble d’outils très répandu, publié en 2013, pour construire des images de conteneur et exécuter des conteneurs. Son format d’image est devenu un standard ouvert. Chapitre 0

Document de conception (RFC)

Proposition écrite pour une modification importante, couvrant le problème, les objectifs, la conception et les alternatives, diffusée pour commentaires avant que la modification ne soit construite. Chapitre 4

Documentation en tant que code (docs as code)

Production de la documentation avec les mêmes outils et le même flux de travail que le logiciel : fichiers en texte brut dans la gestion de versions, revue de code, vérifications automatisées et publication. Chapitre 4

Documentation juste suffisante

Documentation dimensionnée selon ce dont ses lecteurs ont réellement besoin, de sorte qu’en écrire et en maintenir davantage coûterait plus que cela ne rapporte. Chapitre 4

Documentation vivante

Documentation qui évolue avec le système qu’elle décrit, souvent parce qu’elle est générée à partir du système lui-même ou vérifiée par rapport à lui. Chapitre 4

Domaine cœur (core domain)

Sous-domaine qui donne à l’entreprise son avantage concurrentiel et qui mérite donc les meilleures personnes, la modélisation la plus riche et du code détenu par l’entreprise. Chapitre 5

Données à caractère personnel

Au sens du RGPD, toute information se rapportant à une personne physique identifiée ou identifiable (une personne vivante), comme un nom, un numéro d’identification, des données de localisation ou un identifiant en ligne. Chapitre 8

Double écriture (dual write)

Mise à jour de deux systèmes, comme une base de données et un courtier de messages, par des opérations séparées ; une panne entre les deux les laisse incohérents. Chapitre 6

Doublure de test (test double)

Substitut d’un collaborateur réel utilisé dans un test, comme un stub aux réponses préparées à l’avance, un fake doté d’une implémentation simple qui fonctionne, ou un mock qui vérifie les appels qu’il reçoit. Chapitre 2

Drainage des connexions (connection draining)

Arrêt de l’envoi de nouvelles requêtes à une instance en cours de retrait, tout en laissant se terminer les requêtes déjà en cours, afin que la réduction du nombre d’instances et les déploiements ne perdent aucun travail. Chapitre 9

Droits de décision

Énoncé explicite de qui peut prendre quelles décisions, qui doit être consulté et qui doit être informé ; les fixer avant un débat évite la plupart des conflits sur le processus. Chapitre 11

DRY

Don’t repeat yourself (ne vous répétez pas) : principe tiré de The Pragmatic Programmer selon lequel chaque élément de connaissance doit avoir une représentation unique et faisant autorité dans un système. Il porte sur la connaissance, et non sur du texte d’apparence identique. Chapitre 3

Durée de vie (TTL)

La durée pendant laquelle un élément mis en cache peut être utilisé avant d’être considéré comme périmé et de devoir être rafraîchi ou revalidé. Chapitre 7

E

Échantillonnage des traces

Ne conserver qu’une partie des traces pour maîtriser les coûts : l’échantillonnage en tête (head-based) décide au début d’une requête, l’échantillonnage en queue (tail-based) décide après sa fin, ce qui lui permet de garder les requêtes lentes et en échec. Chapitre 9

Échelle de repli (fallback ladder)

Liste ordonnée de solutions de rechange (autres régions, fournisseurs, modèles, puis une réponse sans IA) essayées tour à tour lorsque le modèle privilégié échoue ou est indisponible. Chapitre 12

Économie unitaire (unit economics)

Exprimer le coût (et le chiffre d’affaires) par unité de valeur métier, comme le coût par commande ou par client actif, afin de pouvoir juger l’efficacité indépendamment de la croissance. Chapitre 10

Élasticité

Capacité à ajouter et à retirer des ressources automatiquement à mesure que la charge monte et descend, afin que la capacité suive la demande et que vous ne payiez que ce que vous utilisez. Chapitre 2

Élément

Partie d’un système sur laquelle un architecte raisonne comme sur une unité, comme un module, un service, une base de données, une file ou un serveur. Chapitre 1

Élicitation

Fait d’extraire activement les exigences des parties prenantes, des documents, des réglementations et des systèmes existants, plutôt que d’attendre qu’elles soient énoncées. Chapitre 2

Embedding (plongement vectoriel)

Vecteur de nombres qui représente le sens d’un texte, d’une image ou d’un élément, disposé de sorte que des sens proches soient proches les uns des autres. Chapitre 12

Encapsulation

Fait de garder privés les données internes et les détails d’un objet ou d’un module, afin que le reste du code ne puisse l’utiliser qu’au moyen des opérations qu’il choisit d’offrir. Chapitre 0

Enregistrement de décision d’architecture (ADR)

Court document qui consigne une décision importante : son contexte, les options envisagées, la décision, son statut et ses conséquences. Chapitre 1

Entité

Objet du domaine défini par une identité qui persiste dans le temps tandis que ses attributs changent, comme une commande ou un client. Chapitre 5

Entité d’intérêt

Dans ISO/IEC/IEEE 42010:2022, ce dont on décrit l’architecture : un système logiciel, un système de systèmes, une ligne de produits ou une entreprise. Chapitre 4

Entrepôt de données (data warehouse)

Base de données conçue pour l’analyse, qui intègre des données nettoyées provenant de nombreux systèmes opérationnels et en conserve l’historique. Chapitre 7

Environnement

Copie distincte et complète du système et de ses paramètres, utilisée dans un but précis, comme le développement, les tests, le staging ou la production. Chapitre 0

EPSS

Exploit Prediction Scoring System de FIRST, qui estime la probabilité qu’une vulnérabilité soit exploitée dans les 30 prochains jours. Chapitre 8

Équilibrage de charge global

Répartition des utilisateurs entre centres de données ou régions, généralement par des réponses DNS qui varient selon l’emplacement et l’état de santé, ou par routage anycast. Chapitre 9

Équilibreur de charge (load balancer)

Composant qui reçoit les requêtes entrantes et les répartit entre plusieurs serveurs, en ignorant ceux qui ne sont pas en bonne santé. Chapitre 0

Équilibreur de charge de couche 4

Équilibreur de charge qui opère au niveau transport (TCP ou UDP) et transmet les connexions ou les paquets sans lire la requête HTTP qu’ils contiennent. Chapitre 9

Équilibreur de charge de couche 7

Équilibreur de charge qui comprend le protocole applicatif, généralement HTTP, et peut donc router chaque requête selon le chemin, un en-tête ou un cookie, terminer TLS et effectuer de nouvelles tentatives. Chapitre 9

Équipe facilitatrice (enabling team)

Équipe de spécialistes qui aide d’autres équipes à acquérir une capacité qui leur manque, comme l’automatisation des tests ou l’observabilité, pendant une durée limitée puis passe à autre chose, plutôt que de faire le travail à leur place. Chapitre 11

Équipe orientée flux (stream-aligned team)

Équipe pérenne et pluridisciplinaire, alignée sur un flux de changement unique, comme un produit, un parcours utilisateur ou une capacité métier, capable de construire, d’exploiter et de modifier sa partie de bout en bout. La plupart des équipes d’une organisation devraient être de ce type. Chapitre 11

Équipe plateforme

Équipe qui fournit des services, des outils et une infrastructure internes sous la forme d’un produit en libre-service, afin que les équipes orientées flux puissent livrer sans expertise approfondie de la technologie sous-jacente. Chapitre 11

Équipe sous-système compliqué

Équipe responsable d’une partie du système qui exige des connaissances spécialisées rares, comme un algorithme d’optimisation ou un codec vidéo, afin que les équipes orientées flux puissent l’utiliser sans la maîtriser. Chapitre 11

Érosion de l’architecture

Dégradation progressive d’un système à mesure que des modifications enfreignent son architecture prévue, par exemple en contournant des couches ou en ajoutant des dépendances interdites. Chapitre 1

Erreur

Partie de l’état interne d’un système qui est incorrecte parce qu’une faute a été activée, comme un enregistrement corrompu. Une erreur peut entraîner ou non une défaillance. Chapitre 2

Espace de tuples

Mémoire associative partagée dans laquelle des processus écrivent des tuples et dans laquelle ils lisent ou prélèvent les tuples correspondants, sans se connaître les uns les autres. Introduit par le langage Linda de David Gelernter (1985). Chapitre 6

ETag

En-tête de réponse HTTP portant un identifiant d’une version d’une ressource, qu’un client peut renvoyer dans If-None-Match pour demander si elle a changé. Chapitre 7

État (infrastructure en tant que code)

L’enregistrement que tient un outil d’infrastructure des ressources réelles correspondant à chaque définition du code, utilisé pour déterminer ce qu’il faut créer, modifier ou supprimer. Chapitre 10

État souhaité

Description déclarative de ce à quoi un système doit ressembler (par exemple, trois copies de la version 2.4), que l’automatisation compare à l’état réel et s’efforce d’atteindre. Chapitre 10

Étendue technique (technical breadth)

Savoir que de nombreuses technologies et approches existent, ce pour quoi elles sont bonnes ou mauvaises et quand les utiliser, même sans expertise pratique approfondie de chacune. Chapitre 1

ETL

Extract, transform, load (extraire, transformer, charger) : pipeline qui prend des données dans des systèmes sources, les nettoie et les remodèle, puis les charge dans un stockage cible comme un entrepôt de données. Chapitre 5

Eval (évaluation)

Expérience reproductible qui fait passer un ensemble fixe d’entrées dans un système d’IA et note les résultats, produisant des chiffres comparables d’une version à l’autre. Chapitre 12

Éval de régression (regression eval)

Évaluation automatisée qui s’exécute chaque fois que les prompts, les modèles, la récupération ou les outils changent, et qui bloque la mise en production si la qualité descend sous un seuil ou une référence. Chapitre 12

Évaluation de l’architecture

Examen structuré d’une architecture, avant ou après sa construction, pour déterminer si ses décisions permettront au système d’atteindre ses objectifs métier et ses exigences de qualité, et où elles mettent ces objectifs en danger. Chapitre 11

Évaluation en ligne (online)

Évaluer un système d’IA sur le trafic réel, par exemple au moyen de déploiements fantômes (shadow), de déploiements canari ou de tests A/B. Chapitre 12

Évaluation hors ligne (offline)

Évaluer une version d’un système d’IA sur des jeux de données fixes avant qu’elle n’atteigne les utilisateurs. Chapitre 12

Événement

Enregistrement immuable d’un fait survenu, nommé au passé, comme OrderPlaced. Un nombre quelconque de destinataires peuvent y réagir. Chapitre 6

Événement de domaine (domain event)

Enregistrement d’un fait significatif survenu dans le domaine métier, nommé au passé, comme OrderPlaced ou CourierAssigned. Chapitre 5

Événement interne au processus (in-process event)

Message publié à l’intérieur d’une application en cours d’exécution afin que d’autres modules puissent réagir à un fait survenu, sans que l’émetteur sache qui écoute. Chapitre 5

Event sourcing

Stockage de chaque modification d’une entité sous forme d’événement, de sorte que le journal des événements soit la source de vérité et que l’état courant soit obtenu en le rejouant. Chapitre 6

Event storming

Format d’atelier créé par Alberto Brandolini dans lequel experts du domaine et développeurs placent des événements de domaine sur une ligne du temps pour explorer un processus métier et trouver des frontières. Chapitre 5

Exécution en parallèle (parallel run)

Faire tourner l’ancienne et la nouvelle implémentation côte à côte sur les mêmes entrées et comparer leurs résultats, l’ancienne restant celle qui fait foi, afin de prouver que la nouvelle est équivalente avant de basculer. Chapitre 11

Exigence

Énoncé de ce qu’un système doit faire, ou d’une qualité qu’il doit avoir, convenu avec les personnes qui en ont besoin. Chapitre 0

Exigence architecturalement significative (ASR)

Exigence qui a un effet mesurable sur l’architecture d’un système : si elle changeait, la structure devrait changer. La plupart des ASR sont des attributs de qualité ou des contraintes. Chapitre 2

Exigence fonctionnelle

Énoncé de ce qu’un système doit faire : un comportement, un calcul ou une information qu’il doit fournir, comme « un client peut annuler une commande avant qu’elle ne soit expédiée ». Chapitre 2

Exigence implicite

Qualité que chaque partie prenante tient pour acquise mais que personne ne consigne par écrit, comme « les commandes ne sont jamais perdues » ou « le système continue de fonctionner lors d’un changement d’heure ». Chapitre 2

Exigence non fonctionnelle (NFR)

Nom très répandu mais imprécis pour les exigences de qualité et les contraintes. De nombreux architectes l’évitent, car ces exigences qualifient les fonctions au lieu d’exister à part. Chapitre 2

Expansion-contraction (expand and contract)

Réalisation d’un changement cassant par étapes sûres : ajouter la nouvelle structure à côté de l’ancienne, migrer les lecteurs, les rédacteurs et les données, puis supprimer l’ancienne structure. Aussi appelé changement parallèle (parallel change). Chapitre 7

Expérience de chaos

Test maîtrisé qui injecte une défaillance réelle, comme l’arrêt brutal d’une instance ou le ralentissement d’une dépendance, pour vérifier une hypothèse énoncée sur la manière dont le système conserve son état stable. Chapitre 11

F

Facteur architectural

Objectif, exigence d’attribut de qualité ou contrainte qui façonne de manière significative l’architecture. Chapitre 2

Facteur contributif

L’une des différentes conditions qui, ensemble, ont rendu un incident possible ou l’ont aggravé ; les revues recherchent de nombreux facteurs contributifs plutôt qu’une cause racine unique. Chapitre 9

Facteur de décision

Force ou critère, comme un objectif de qualité ou une contrainte, auquel une décision d’architecture doit satisfaire et à l’aune duquel les options sont comparées. Chapitre 4

Facteurs métier (business drivers)

Objectifs, contraintes et contexte métier qui expliquent pourquoi un système existe et ce que signifie la réussite, comme des objectifs de croissance, la réglementation ou des contrats. Dans l’ATAM, ils sont présentés en premier afin que chaque constat puisse leur être rattaché. Chapitre 11

Failover (basculement)

Transfert du travail d’un composant défaillant vers un composant de secours ou une réplique en bon état, automatiquement ou manuellement. Chapitre 2

Fan-out (diffusion en éventail)

Patron dans lequel une requête entrante déclenche plusieurs requêtes parallèles vers d’autres services ou serveurs, dont les réponses sont ensuite combinées. Chapitre 2

Faute (fault)

Cause d’un problème, comme un bug, un disque défaillant ou une mauvaise configuration. Une faute peut rester latente jusqu’à ce que quelque chose l’active. Chapitre 2

Feature flag (indicateur de fonctionnalité)

Interrupteur de configuration qui active ou désactive un comportement à l’exécution sans déployer de nouveau code. Chapitre 1

Fenêtre de contexte

Nombre maximal de tokens qu’un modèle peut prendre en compte en un seul appel, y compris les instructions, l’historique, les documents fournis et sa propre réponse. Chapitre 12

Fenêtre glissante

Période de mesure qui avance en continu, comme les 28 derniers jours, par opposition à un mois civil qui repart à zéro le premier du mois. Chapitre 9

Fiabilité

La probabilité qu’un système fonctionne correctement, sans défaillance, pendant une période donnée et dans des conditions données. Un système peut être très disponible tout en étant peu fiable s’il tombe souvent en défaillance mais se rétablit rapidement. Chapitre 2

Fichier

Suite nommée d’octets stockée sur un disque et gérée par le système d’exploitation, comme une photo, une feuille de calcul ou un journal. Chapitre 0

Fidélité (faithfulness)

Dans l’évaluation d’un système RAG, degré auquel chaque affirmation d’une réponse est étayée par les passages récupérés ; aussi appelée ancrage (groundedness). Chapitre 12

File (canal point à point)

Canal de messagerie dans lequel chaque message est remis à exactement un des consommateurs qui y lisent, de sorte que plusieurs instances peuvent se partager le travail. Chapitre 6

File de lettres mortes (dead-letter queue)

Emplacement distinct où les messages dont le traitement échoue de façon répétée sont mis de côté pour inspection, afin qu’ils ne bloquent pas le reste du flux. Chapitre 5

File de messages

Logiciel qui stocke les messages des expéditeurs jusqu’à ce que les destinataires soient prêts à les traiter, de sorte que les deux n’ont pas besoin de tourner en même temps ni d’aller à la même vitesse. Chapitre 0

Filigrane (watermark)

L’estimation glissante d’un processeur de flux selon laquelle tous les événements jusqu’à un certain temps de l’événement sont probablement arrivés, utilisée pour décider quand le résultat d’une fenêtre peut être émis. Chapitre 7

Filtre

Étape de traitement autonome qui lit une entrée, puis la produit, la transforme, la teste ou la consomme, sans savoir quelles étapes la précèdent ou la suivent. Chapitre 5

Fine-tuning (affinage)

Entraînement complémentaire d’un modèle existant sur un jeu de données plus petit et ciblé, pour lui apprendre une tâche, un format, un ton ou un vocabulaire. Chapitre 12

FinOps

Pratique dans laquelle les équipes d’ingénierie, de finance et métier partagent la responsabilité des dépenses cloud et technologiques, en s’appuyant sur des données de coûts à jour pour prendre des décisions qui maximisent la valeur métier. Chapitre 10

Flapping (oscillation)

Situation où un autoscaler ajoute et retire de la capacité à répétition parce qu’il réagit à des changements de courte durée ou aux effets de ses propres actions. Chapitre 9

Flux d’événements

Suite ordonnée des événements d’un agrégat, numérotés par version, à partir de laquelle l’état de cet agrégat est reconstruit. Chapitre 7

Fonction

Morceau de code nommé et réutilisable qui prend des entrées (paramètres), effectue un travail et renvoie généralement une sortie. Chapitre 0

Fonction d’aptitude (fitness function)

Vérification automatisée qui vous indique si un système possède toujours une propriété architecturale, comme un test qui échoue lorsqu’un module dépend d’un autre qu’il ne doit pas utiliser. Chapitre 1

Fonction d’aptitude atomique

Fonction d’aptitude qui vérifie une seule caractéristique d’architecture dans un seul contexte, comme un test qui interdit les imports entre deux paquets. Chapitre 11

Fonction d’aptitude continue

Fonction d’aptitude qui s’exécute en permanence sur le système en production, comme la supervision des SLO ou les transactions synthétiques, plutôt que d’être déclenchée par un build ou un événement. Chapitre 11

Fonction d’aptitude holistique

Fonction d’aptitude qui vérifie plusieurs caractéristiques ensemble dans un contexte commun, comme un test de charge qui mesure la latence pendant que la sécurité et la journalisation sont activées. Chapitre 11

Fonction en périphérie (edge function)

Petit morceau de code exécuté par un CDN ou un fournisseur edge à des emplacements proches des utilisateurs, pour traiter ou modifier les requêtes avant qu’elles n’atteignent l’origine (ou à sa place). Chapitre 10

Fondement juridique (base légale)

L’un des six fondements prévus à l’article 6 du RGPD (consentement, contrat, obligation légale, intérêts vitaux, mission d’intérêt public, intérêts légitimes) sur lequel tout traitement de données à caractère personnel doit reposer. Chapitre 8

Force (de la connascence)

La difficulté à découvrir et à refactoriser une forme de connascence. Le nom est la forme la plus faible ; les formes dynamiques comme le timing, la valeur et l’identité comptent parmi les plus fortes. Chapitre 3

Format de table ouvert (open table format)

Spécification, comme Apache Iceberg, Delta Lake ou Apache Hudi, qui organise les fichiers de données et les métadonnées afin que de nombreux moteurs puissent les traiter comme des tables, avec transactions et voyage dans le temps (time travel). Chapitre 7

Forum consultatif d’architecture

Réunion régulière et ouverte où sont discutées les décisions proposées, les spikes et les avis recueillis. Elle apporte des conseils et de la visibilité mais ne décide pas elle-même. Chapitre 11

Framework

Code réutilisable qui fournit la structure d’ensemble d’une application et appelle votre code aux bons moments, comme Django ou Spring. Chapitre 0

Frontière de confiance

Ligne dans un système où des données ou le contrôle passent entre des parties ayant des niveaux de confiance ou de privilège différents, par exemple d’Internet vers une API ; les entrées doivent donc y être vérifiées. Chapitre 8

FURPS+

Classification de la qualité née chez Hewlett-Packard sous le nom de FURPS (fonctionnalité, utilisabilité, fiabilité, performances et supportabilité), étendue ensuite par un « + » pour des contraintes comme la conception, l’implémentation, les interfaces et les limites physiques. Chapitre 2

G

Game day (journée d’exercice)

Exercice planifié au cours duquel une équipe provoque ou simule délibérément une défaillance et s’entraîne à la détecter, à y répondre et à s’en rétablir. Chapitre 9

Garanties de session

Promesses de cohérence propres à chaque client, décrites par Terry et ses collègues en 1994 : lecture de ses propres écritures (read-your-writes), lectures monotones, écritures monotones et écritures après lectures (writes-follow-reads). Chapitre 6

Garde (guard)

Condition entre crochets sur une transition ou un flux, qui doit être vraie pour que celle-ci soit empruntée, comme [le code correspond]. Chapitre 4

Garde-fou (guardrail)

Limite ou vérification automatique qui garantit la sûreté de l’usage en libre-service (par exemple, une politique qui bloque les buckets de stockage publics) sans exiger qu’une personne approuve chaque demande. Chapitre 10

Gateway API

API de Kubernetes pour acheminer le trafic externe et interne vers les services, disponible en version stable depuis 2023 et successeur recommandé d’Ingress. Chapitre 10

Gauge (jauge)

Métrique qui enregistre une valeur courante pouvant monter ou descendre, comme la longueur d’une file, la mémoire utilisée ou la température. Chapitre 9

Génération augmentée par récupération (RAG)

Récupérer, au moment de la requête, des passages pertinents dans vos propres sources et les fournir au modèle afin qu’il réponde à partir de faits actuels, autorisés et citables. Chapitre 12

Gestion de configuration

Outils comme Ansible, Chef et Puppet qui amènent des serveurs existants et de longue durée dans une configuration décrite, en y installant des paquets et en modifiant des fichiers. Chapitre 10

Gestion de versions

Système qui enregistre chaque modification d’un ensemble de fichiers, qui l’a faite et pourquoi, afin que les personnes puissent travailler en parallèle, relire les modifications et revenir à n’importe quelle version antérieure. Chapitre 0

Gestion des secrets

Stocker, distribuer, renouveler et auditer des identifiants comme les mots de passe, les clés d’API et les clés privées dans un coffre-fort dédié plutôt que dans le code ou les fichiers de configuration. Chapitre 8

Gestionnaire de paquets

Outil comme pip (Python) ou npm (JavaScript) qui télécharge des bibliothèques et les bibliothèques dont elles dépendent, dans les versions qu’un projet spécifie. Chapitre 0

Git

Système de gestion de versions le plus utilisé, créé par Linus Torvalds en 2005. Chaque développeur dispose d’une copie complète de l’historique du projet. Chapitre 0

GitOps

Exploitation des systèmes en conservant leur état souhaité déclaratif dans Git et en laissant des agents le récupérer et réconcilier en continu le système en cours d’exécution pour qu’il y corresponde. Chapitre 10

Golden path (paved road, chemin balisé)

Manière préconisée, prise en charge et documentée d’accomplir une tâche courante, comme créer un nouveau service, qui est la plus simple mais pas la seule autorisée. Chapitre 10

Golden set (jeu de référence)

Collection sélectionnée et versionnée d’entrées de test, accompagnées pour chacune du résultat attendu, d’une réponse de référence ou d’une grille de notation, utilisée pour évaluer un système d’IA. Chapitre 12

Gouffre d’architecture (architecture sinkhole)

Anti-patron des systèmes en couches dans lequel les requêtes traversent des couches qui ne font que les transmettre, ajoutant du code et du délai sans ajouter de comportement. Chapitre 5

Gouvernance de l’architecture

Pratiques par lesquelles une organisation s’assure que les décisions techniques importantes sont bien prises, cohérentes avec ses objectifs et réellement appliquées, y compris qui décide, comment et avec quels contrôles. Chapitre 11

Grand modèle de langage (LLM)

Transformer de très grande taille entraîné sur d’énormes quantités de texte pour prédire le token suivant, puis ajusté pour suivre des instructions ; il génère du texte, du code et des données structurées. Chapitre 12

Granularité

Taille des modules ou des services par rapport à l’ensemble du système. À gros grain signifie peu de grandes parties ; à grain fin, beaucoup de petites. Chaque option a ses coûts. Chapitre 3

GraphQL

Langage de requête et environnement d’exécution pour les API, publié par Facebook en 2015, dans lequel le client envoie une requête nommant exactement les champs qu’il veut d’un schéma typé et reçoit une réponse de même forme. Chapitre 6

Grille de données en mémoire (in-memory data grid)

Logiciel qui conserve des données dans la mémoire de nombreuses machines sous la forme d’un seul stockage logique, avec partitionnement et réplication, pour un accès très rapide. Hazelcast, Apache Ignite et Oracle Coherence en sont des exemples. Chapitre 6

Grosse boule de boue (big ball of mud)

Système sans structure reconnaissable, dans lequel presque tout dépend de tout le reste ; le nom vient de Brian Foote et Joseph Yoder (1997). Chapitre 5

Groupe de consommateurs

Ensemble de consommateurs qui se partagent le travail de lecture d’un topic : chaque partition est lue par un seul membre, et chaque groupe conserve ses propres offsets. Chapitre 6

gRPC

Framework d’appel de procédure à distance, rendu open source par Google en 2015, qui envoie des messages Protocol Buffers sur HTTP/2 et génère du code client et serveur typé. Il prend en charge le streaming dans un sens, dans l’autre ou dans les deux. Chapitre 6

H

Hachage cohérent (consistent hashing)

Manière d’attribuer des clés à des nœuds sur un anneau de hachage de sorte que l’ajout ou le retrait d’un nœud ne déplace qu’environ 1/N des clés (Karger et ses collègues, 1997). Chapitre 7

Hachage des mots de passe

Stocker un mot de passe sous la forme du résultat d’une fonction délibérément lente et salée, comme Argon2id, scrypt ou bcrypt, afin qu’une base de données volée ne puisse pas être reconvertie à peu de frais en mots de passe. Chapitre 8

Hallucination

Production d’un modèle fluide et assurée mais fausse ou non étayée par ses sources, comme une citation ou une politique inventée. Chapitre 12

Heartbeat (battement de cœur)

Message périodique « je suis en vie » envoyé par un composant ; si les messages cessent, un moniteur considère que le composant est défaillant et agit. Chapitre 2

Histogramme

Métrique qui répartit les observations, comme la durée des requêtes, dans des plages de valeurs appelées buckets, afin de pouvoir estimer des percentiles et additionner les histogrammes de nombreux serveurs. Chapitre 9

HNSW

Hierarchical navigable small world graphs (Malkov et Yashunin, 2016) : index très utilisé pour la recherche approximative des plus proches voisins parmi des vecteurs. Chapitre 12

Horizontal Pod Autoscaler (HPA)

Contrôleur Kubernetes qui modifie le nombre de répliques de pods pour maintenir une métrique, comme l’utilisation moyenne du CPU rapportée aux requêtes de ressources, près d’une cible. Chapitre 10

Hotspot (point chaud)

Partie du code à la fois complexe et fréquemment modifiée, repérée en combinant l’historique de la gestion de versions avec une mesure de complexité ; un endroit tout désigné pour rembourser de la dette. Chapitre 1

HTTP

Hypertext Transfer Protocol : le langage de requêtes et de réponses du web, dans lequel un client envoie une méthode comme GET à une URL et un serveur répond par un code d’état et un contenu. Chapitre 0

Humain dans la boucle (human in the loop)

Conception dans laquelle une personne examine, approuve ou corrige le résultat d’un modèle avant ou après qu’il prend effet. Chapitre 12

Hyperviseur

Logiciel qui crée et exécute des machines virtuelles, en leur partageant les processeurs, la mémoire et les périphériques d’un ordinateur physique tout en les maintenant isolées. Chapitre 0

Hypothèse du miroir (mirroring hypothesis)

La version issue de la recherche de la loi de Conway : les dépendances techniques d’un produit tendent à correspondre aux liens de communication et d’organisation entre les personnes qui le construisent. Chapitre 3

Hypothèse d’état stable

Dans une expérience de chaos, la prédiction qu’un signe mesurable de comportement normal, comme le nombre de commandes par minute, restera dans certaines limites pendant l’injection d’une défaillance. Chapitre 9

I

IaaS (infrastructure en tant que service)

Modèle de cloud dans lequel vous louez des machines virtuelles, du stockage et des réseaux, et gérez vous-même le système d’exploitation et tout ce qui se trouve au-dessus. Chapitre 0

Idempotence

Propriété d’une opération qui a le même effet qu’elle soit exécutée une ou plusieurs fois, ce qui rend les nouvelles tentatives sûres. Généralement obtenue grâce à un identifiant unique de requête ou d’événement que le destinataire mémorise. Chapitre 6

Idempotent

Qualifie une opération qui a le même effet qu’elle soit appliquée une ou plusieurs fois, et qui peut donc être retentée sans risque. Chapitre 5

Identité de charge de travail (workload identity)

Identité vérifiable attribuée à un service en fonctionnement plutôt qu’à une personne, délivrée par la plateforme (par exemple un SPIFFE ID dans un certificat de courte durée), utilisée à la place de secrets partagés. Chapitre 8

Illusions de l’informatique distribuée

Huit hypothèses fausses sur les réseaux recensées chez Sun Microsystems par L Peter Deutsch et ses collègues, James Gosling ayant ajouté la huitième : par exemple, que le réseau est fiable et que la latence est nulle. Chapitre 6

Image de conteneur

Paquet versionné en lecture seule contenant une application et tout ce dont elle a besoin pour s’exécuter, à partir duquel des conteneurs identiques peuvent être démarrés n’importe où. Chapitre 0

Index

Structure de données supplémentaire, conservée à côté des données, qui permet à un système de trouver des éléments d’après un champ choisi sans tout parcourir, comme l’index à la fin d’un livre. Chapitre 0

Index de base de données

Structure de données supplémentaire, généralement un arbre B, qui permet à la base de données de trouver des lignes d’après la valeur d’une colonne sans lire toute la table. Il accélère les lectures mais ralentit les écritures et occupe de l’espace. Chapitre 0

Index secondaire

Index sur un attribut autre que la clé primaire ou la clé de partition. Dans un système partitionné, il est soit local à chaque partition, soit global et partitionné selon la valeur indexée. Chapitre 7

Indicateur de niveau de service (SLI)

Mesure soigneusement définie du comportement d’un service, comme la proportion de requêtes qui réussissent en moins de 300 ms. Chapitre 2

Inférence

Utilisation d’un modèle entraîné pour produire des résultats à partir de nouvelles entrées. En production, c’est un service doté d’une latence, d’un débit et d’un coût par appel, contrairement à l’entraînement, qui est une lourde tâche par lots. Chapitre 12

Inférence par lots

Traitement groupé et asynchrone de nombreuses requêtes adressées à un modèle, pour un coût par requête plus faible mais avec une attente plus longue des résultats. Chapitre 12

Informatique consciente du carbone (carbon-aware computing)

Exécution des logiciels de façon à en faire davantage quand l’électricité est plus propre et moins quand elle est plus polluante, en déplaçant le travail dans le temps ou dans l’espace ou en modulant la demande. Chapitre 11

Infrastructure à clés publiques (PKI)

Les autorités de certification, les certificats, les magasins de confiance, les politiques et les mécanismes de révocation qui, ensemble, permettent aux parties de vérifier mutuellement leurs clés publiques. Chapitre 8

Infrastructure en tant que code (IaC)

Définition des serveurs, réseaux, bases de données et autres éléments d’infrastructure dans des fichiers placés sous gestion de versions, que des outils appliquent automatiquement, au lieu de les configurer à la main. Chapitre 10

Infrastructure immuable

Pratique consistant à ne jamais modifier sur place un serveur ou un conteneur en cours d’exécution ; chaque modification se fait en construisant une nouvelle image et en remplaçant les anciennes instances. Chapitre 10

Ingénierie de plateforme (platform engineering)

La discipline qui consiste à construire et à exploiter des plateformes internes permettant aux équipes produit de provisionner, de déployer et d’exploiter des logiciels en libre-service. Chapitre 10

Ingénierie du chaos

Expérimentation sur un système, idéalement en production et de manière maîtrisée, en injectant des défaillances réalistes afin d’acquérir la confiance qu’il résiste à des conditions turbulentes. Chapitre 9

Injection de dépendances

Fourniture à un composant, depuis l’extérieur, des collaborateurs dont il a besoin (une base de données, une horloge, une passerelle de paiement) au lieu de le laisser les créer, afin de pouvoir les remplacer, par exemple par des imitations dans les tests. Chapitre 2

Injection de prompt (prompt injection)

Attaque dans laquelle un texte fourni par un utilisateur, ou caché dans un contenu que lit le modèle, contient des instructions qui supplantent ou détournent le comportement prévu de l’application. Chapitre 12

Injection de prompt indirecte

Injection de prompt transmise par un contenu que le système lit, comme une page web, un e-mail, un document ou le résultat d’un outil, plutôt que saisie par l’utilisateur. Chapitre 12

Instabilité (I)

Métrique de Martin I = Ce / (Ca + Ce), de 0 (stabilité maximale : uniquement des dépendances entrantes) à 1 (instabilité maximale : uniquement des dépendances sortantes). Chapitre 3

Intégration continue (CI)

Pratique consistant à fusionner fréquemment, au moins une fois par jour, les modifications de chaque développeur dans la ligne principale partagée, avec un build et des tests automatisés qui vérifient chaque modification. Chapitre 0

Interception d’événements

Patron de remplacement de système hérité qui intercepte les requêtes ou événements modifiant l’état sur leur chemin vers un système hérité et en transmet certains à un nouveau composant, en plus ou à la place. Chapitre 11

Intérêts (de la dette technique)

Effort, retard ou risque supplémentaire payé à chaque modification parce que la dette n’a pas été remboursée. Chapitre 1

Interface

Ensemble convenu d’opérations qu’un logiciel offre aux autres, avec leurs entrées et leurs sorties : un contrat qui cache la manière dont le travail est fait. Chapitre 0

Interface fournie

Dans un diagramme de composants UML, une interface qu’un composant offre aux autres, représentée par un petit cercle (une boule) au bout d’une tige. Chapitre 4

Interface requise

Dans un diagramme de composants UML, une interface dont un composant a besoin qu’un autre composant la fournisse, représentée par un demi-cercle (une prise). Chapitre 4

Interopérabilité

Degré auquel des systèmes peuvent échanger des informations et utiliser correctement ce qu’ils échangent, ce qui exige un accord sur le sens autant que sur le format. Chapitre 2

Interpréteur

Programme qui lit du code et exécute ses instructions au fur et à mesure, plutôt que de traduire tout le programme à l’avance. Chapitre 0

Invalidation du cache

Suppression d’une copie en cache, ou son marquage comme périmée, lorsque les données d’origine changent, afin que les lectures suivantes récupèrent la nouvelle valeur. Chapitre 7

Invariant

Condition toujours vraie pour un module ou un objet entre deux opérations, comme « le solde d’un compte ne descend jamais sous sa limite de découvert ». Chapitre 3

Inversion de contrôle

Organisation dans laquelle un framework, plutôt que votre propre code, contrôle le déroulement du programme et appelle votre code lorsque c’est nécessaire. Chapitre 0

Inversion des dépendances

Fait de faire dépendre un module de haut niveau et un module de bas niveau d’une même abstraction, généralement détenue par le côté de haut niveau, de sorte que la dépendance dans le code source pointe dans le sens inverse du flux de contrôle. Chapitre 3

ISO/IEC 25010

Norme internationale de modèle de qualité des produits. L’édition 2023 définit neuf caractéristiques, de l’adéquation fonctionnelle à la sûreté, chacune divisée en sous-caractéristiques. Chapitre 2

ISO/IEC 42001

Norme internationale (2023) qui spécifie les exigences d’un système de management de l’IA certifiable au sein d’une organisation. Chapitre 12

Isolation par instantané (snapshot isolation)

Niveau d’isolation dans lequel chaque transaction lit, dès son début, un instantané cohérent des données validées, et où les écritures conflictuelles sur une même ligne sont rejetées. Il empêche les mises à jour perdues mais permet le write skew. Chapitre 7

J

Jailbreak

Entrée conçue pour amener un modèle à enfreindre les règles de sûreté que son fournisseur lui a inculquées lors de l’entraînement. Chapitre 12

Jetabilité (disposability)

Propriété des processus qui démarrent rapidement, s’arrêtent proprement et peuvent être tués à tout moment sans dommage, de sorte qu’on peut les remplacer et les multiplier librement. Chapitre 10

Jeton d’accès (access token)

Justificatif de courte durée, délivré après la connexion d’un utilisateur ou d’une application, envoyé avec chaque requête d’API pour prouver ce que l’appelant a le droit de faire. Chapitre 0

Jitter (gigue aléatoire)

Part d’aléatoire ajoutée aux délais entre nouvelles tentatives ou aux plannings, afin que de nombreux clients n’agissent pas au même moment et ne créent pas de pics synchronisés. Chapitre 9

Jointure (join)

Opération SQL qui combine les lignes de deux tables ou plus en faisant correspondre des colonnes liées, par exemple les commandes avec les clients qui les ont passées. Chapitre 0

Journal des décisions (decision log)

Collection ordonnée des ADR d’un système, généralement accompagnée d’un index indiquant le numéro, le titre, le statut et la date de chaque enregistrement. Chapitre 4

Journal d’écriture anticipée (write-ahead log, WAL)

Journal sur disque en ajout seul (append-only) dans lequel une base de données enregistre chaque modification avant de l’appliquer, afin que le travail validé survive à une panne ; les répliques sont souvent alimentées à partir de ce journal. Chapitre 7

Journalisation structurée (structured logging)

Écrire les entrées de journal sous forme d’enregistrements clé-valeur lisibles par machine (souvent en JSON), avec des noms de champs cohérents, au lieu de phrases en texte libre. Chapitre 9

JSON (JavaScript Object Notation)

Format texte pour données structurées composé d’objets (paires nom-valeur entre accolades), de tableaux (listes entre crochets), de chaînes, de nombres, de true, false et null. Normalisé par la RFC 8259. Chapitre 0

JSON Web Token (JWT)

Jeton compact, signé (et éventuellement chiffré), qui porte des déclarations (claims) telles que l’émetteur, le sujet, l’audience et l’expiration, défini par la RFC 7519 ; très utilisé pour les jetons d’accès et les jetons d’identité (ID tokens). Chapitre 8

K

Kanban

Manière de gérer le travail comme un flux continu sur un tableau visuel, en limitant le nombre d’éléments pouvant être en cours en même temps. Chapitre 0

Kata d’architecture

Exercice pratique créé par Ted Neward dans lequel de petites équipes conçoivent une architecture à partir d’un énoncé court et délibérément incomplet, puis la présentent et la défendent devant leurs pairs. Chapitre 11

KISS

Keep it simple (restez simple) : règle empirique de conception, issue de l’ingénierie des années 1960, selon laquelle il faut éviter toute complexité inutile, car elle rend un système plus difficile à comprendre, à exploiter et à réparer. Chapitre 3

Kubernetes

L’orchestrateur de conteneurs open source le plus utilisé, créé chez Google, annoncé en 2014 et publié en version 1.0 en 2015 ; il maintient l’état réel d’un cluster conforme à un état souhaité déclaré. Chapitre 10

L

Lakehouse

Architecture qui ajoute des fonctionnalités d’entrepôt de données, telles que les transactions, les schémas et les requêtes rapides, à des données conservées dans des formats de fichiers ouverts sur un stockage objet. Chapitre 7

Langage de modélisation unifié (UML)

Langage de modélisation graphique généraliste normalisé par l’Object Management Group. La version actuelle est la 2.5.1 (2017). Chapitre 4

Langage omniprésent (ubiquitous language)

Vocabulaire partagé par les développeurs et les experts du domaine, et employé de manière cohérente dans les conversations, les documents, les tests et le code au sein d’un même contexte délimité. Chapitre 5

Langage publié (published language)

Format documenté et partagé pour échanger des informations entre contextes, comme un schéma d’événements versionné, souvent proposé au travers d’un service hôte ouvert. Chapitre 5

Last write wins (la dernière écriture l’emporte)

Règle de résolution des conflits qui conserve l’écriture portant l’horodatage le plus récent et écarte les autres. Simple, mais les mises à jour concurrentes sont perdues sans avertissement, et des écarts d’horloge peuvent désigner le mauvais gagnant. Chapitre 6

Latence

Le délai avant que des données arrivent ou qu’une réponse revienne, généralement mesuré en millisecondes. La distance, les sauts réseau et un traitement lent l’augmentent tous. Chapitre 0

Latence de queue (tail latency)

Les temps de réponse des requêtes les plus lentes, généralement décrits par des percentiles élevés comme p99 ou p99.9. À grande échelle, c’est souvent la queue qui détermine ce que vivent les utilisateurs. Chapitre 2

LCOM (manque de cohésion des méthodes)

Famille de métriques au niveau de la classe qui estiment la cohésion à partir de la façon dont les méthodes d’une classe partagent ses champs ; une valeur élevée laisse penser que la classe porte plusieurs responsabilités sans rapport entre elles. Chapitre 3

Leaky bucket (seau percé)

Algorithme de limitation de débit ou de mise en forme du trafic dans lequel les requêtes entrent dans un seau et en sortent à un rythme constant ; lorsque le seau est plein, les nouvelles requêtes sont rejetées. Chapitre 9

Lecteur tolérant (tolerant reader)

Consommateur qui ne lit que les champs dont il a besoin et ignore tout ce qu’il ne reconnaît pas, afin que les fournisseurs puissent ajouter des champs sans le casser. Chapitre 7

Lecture de ses propres écritures (read-your-writes)

Garantie qu’après qu’un client a écrit une valeur, les lectures ultérieures de ce même client voient cette écriture ou une valeur plus récente, même si d’autres clients ne la voient pas encore. Chapitre 6

Lectures monotones

Garantie qu’une fois qu’un client a vu une valeur, ses lectures ultérieures ne renvoient jamais une valeur plus ancienne, de sorte que les données ne semblent jamais remonter dans le temps. Chapitre 6

Les sept R (Seven Rs)

Les stratégies de migration qu’AWS recense pour faire passer des applications dans le cloud : retire, retain, rehost, relocate, repurchase, replatform, et refactor ou re-architect. Elles sont issues des cinq R proposés plus tôt par Gartner. Chapitre 11

Lignage des données (data lineage)

Enregistrement de l’origine d’une donnée et de chaque transformation qu’elle a subie en chemin. Chapitre 7

Ligne de vie

Dans un diagramme de séquence, la ligne verticale en pointillés sous un participant, le long de laquelle ses messages et ses activations sont montrés dans l’ordre chronologique. Chapitre 4

Limitation de débit (rate limiting)

Restreindre le nombre de requêtes qu’un client, une clé ou un locataire (tenant) peut faire sur une période, afin de protéger la capacité et de la partager équitablement ; les requêtes en excès reçoivent généralement une réponse HTTP 429. Chapitre 9

Limite de débit (rate limit)

Plafond du nombre de requêtes qu’un client peut faire sur une période, par exemple 100 par minute. Les requêtes au-delà sont refusées, généralement avec le code d’état HTTP 429. Chapitre 0

Linéarisabilité

Le modèle de cohérence le plus fort pour un objet unique : chaque opération semble se produire en un instant situé entre son début et sa fin, dans un ordre partagé par tous les clients et qui respecte le temps réel, comme s’il n’existait qu’une seule copie. Chapitre 6

Linux

Noyau de système d’exploitation libre et open source, utilisé avec d’autres logiciels comme système d’exploitation de la plupart des serveurs, des machines du cloud et des conteneurs, ainsi que des téléphones Android. Chapitre 0

Livraison au moins une fois (at-least-once)

Garantie que chaque message est traité, éventuellement plus d’une fois ; les doublons doivent être gérés par le destinataire. Chapitre 6

Livraison continue

Maintien du logiciel dans un état toujours livrable, de sorte que toute version qui passe le pipeline automatisé puisse être mise en production en appuyant sur un bouton. Chapitre 0

Livraison progressive (progressive delivery)

Mettre un changement en production pour des publics de plus en plus larges, avec des vérifications automatisées à chaque étape, afin qu’un mauvais changement atteigne le moins d’utilisateurs possible avant d’être arrêté. Chapitre 10

LLM comme juge (LLM-as-judge)

Utiliser un modèle de langage pour noter ou comparer des sorties selon une grille d’évaluation ; méthode qui passe à l’échelle mais qui est sujette à des biais qu’il faut mesurer par rapport au jugement humain. Chapitre 12

LLMOps

Pratiques pour construire, mettre en production, superviser et améliorer des applications fondées sur de grands modèles de langage, notamment le versionnage des prompts et des modèles, le traçage des appels et l’évaluation dans le pipeline. Chapitre 12

Localité (de la connascence)

La proximité des éléments connascents : au sein d’une même fonction, d’un même module, d’un même composant, ou à travers un réseau. Une connascence forte n’est tolérable que si elle est locale. Chapitre 3

Lockfile (fichier de verrouillage)

Fichier généré par un gestionnaire de paquets qui enregistre les versions exactes, et généralement les empreintes (hashes), de chaque dépendance résolue, afin que chaque installation utilise les mêmes paquets. Chapitre 8

Logiciel (software)

Les programmes, avec les données et la configuration dont ils ont besoin ; les instructions qui indiquent au matériel quoi faire. Chapitre 0

Loi de Conway

Observation de Melvin Conway (1968) selon laquelle les organisations conçoivent des systèmes dont la structure reflète leur propre structure de communication. Chapitre 1

Loi de Goodhart

Observation, souvent formulée ainsi : « lorsqu’une mesure devient un objectif, elle cesse d’être une bonne mesure », selon laquelle les gens optimisent le chiffre plutôt que ce qu’il était censé indiquer. Chapitre 3

Loi de Hyrum

Observation, nommée d’après Hyrum Wright, selon laquelle, avec suffisamment d’utilisateurs d’une API, chaque comportement observable finira par être utilisé par quelqu’un, quoi que promette le contrat. Chapitre 3

Loi de Little

La règle L = λ × W : le nombre moyen d’éléments dans un système stable est égal au taux d’arrivée moyen multiplié par le temps moyen que chaque élément y passe. Chapitre 2

Loi d’Amdahl

Formule (Gene Amdahl, 1967) montrant que l’accélération obtenue en ajoutant des processeurs est limitée par la part du travail qui doit s’exécuter en série. Chapitre 2

Loi universelle de scalabilité (USL)

Le modèle de Neil Gunther décrivant comment la capacité augmente avec l’ajout de nœuds, en tenant compte de la contention pour les ressources partagées et du coût du maintien de la cohérence des données. Il prédit un pic au-delà duquel ajouter des nœuds réduit la capacité. Chapitre 2

M

Machine virtuelle (VM)

Imitation logicielle d’un ordinateur complet, avec son propre système d’exploitation, qui s’exécute à côté d’autres VM sur une même machine physique sous le contrôle d’un hyperviseur. Chapitre 0

MADR

Markdown Architectural Decision Records : modèle d’ADR très utilisé, comprenant les facteurs de décision, les options envisagées, le résultat, les conséquences et la confirmation. Chapitre 4

Maintenabilité

Dans l’ISO/IEC 25010, l’efficacité et l’efficience avec lesquelles un produit peut être modifié, ce qui couvre la modularité, la réutilisabilité, l’analysabilité, la modifiabilité et la testabilité. Chapitre 2

Manœuvre de Conway inversée

Façonnage délibéré des équipes et de leurs canaux de communication pour qu’ils correspondent à l’architecture que vous voulez, afin que la loi de Conway joue en votre faveur plutôt que contre vous. Chapitre 3

Marge de capacité (headroom)

Capacité de réserve maintenue délibérément au-dessus du pic de charge prévu, pour absorber les rafales, les défaillances et le temps nécessaire pour ajouter de la capacité. Chapitre 9

Masquage de l’information (information hiding)

Principe de David Parnas (1972) selon lequel chaque module doit cacher une décision de conception difficile ou susceptible de changer, afin que cette décision puisse changer sans affecter les autres modules. Chapitre 3

Matériel (hardware)

Parties physiques d’un ordinateur que l’on pourrait toucher : le processeur, la mémoire, le stockage, la carte réseau, l’écran, etc. Chapitre 0

Matrice de décision pondérée

Tableau qui note chaque option selon des critères pondérés afin que le raisonnement derrière un choix soit explicite et puisse être contesté. Chapitre 1

Matrice pouvoir/intérêt

Matrice à quatre cases qui place les parties prenantes selon leur pouvoir sur un projet et leur intérêt pour celui-ci, utilisée pour planifier le degré d’implication de chaque groupe. Chapitre 1

Message

Toute donnée envoyée d’un programme à un autre par un canal ; elle peut porter un événement, une commande, une requête ou une réponse. Chapitre 6

Messagerie asynchrone

Communication dans laquelle l’émetteur dépose un message quelque part pour que le destinataire le traite plus tard, et poursuit son travail sans attendre de réponse. Chapitre 0

Mesure de la réponse

Le chiffre qui rend un scénario testable, par exemple « 99 % en moins de 800 ms », « service rétabli en moins de 2 minutes » ou « changement réalisé en 3 jours-personne ». Chapitre 2

Méthode RED

La liste de contrôle de Tom Wilkie pour superviser les services pilotés par les requêtes : Rate (débit), Errors (erreurs) et Duration (durée) des requêtes. Chapitre 9

Méthode USE

La liste de contrôle de Brendan Gregg pour analyser les ressources : pour chaque ressource, vérifier l’utilisation (Utilisation), la saturation (Saturation) et les erreurs (Errors). Chapitre 9

Métriques DORA

Mesures de la performance de livraison logicielle issues du programme de recherche DORA : délai de mise en œuvre des changements, fréquence de déploiement, temps de rétablissement après un déploiement en échec, taux d’échec des changements et taux de reprise des déploiements. Chapitre 2

Microsegmentation

Diviser un réseau en zones très petites, jusqu’à la charge de travail individuelle, afin que chacune n’accepte le trafic que des appelants dont elle a besoin. Chapitre 8

Microservices

Style dans lequel une application est construite sous forme de petits services, chacun dans son propre processus, organisé autour d’une capacité métier, déployable indépendamment et communiquant par des mécanismes légers. Chapitre 6

Migration

Script versionné qui fait passer un schéma de base de données ou ses données d’une version à la suivante, conservé dans la gestion de versions et appliqué automatiquement. Chapitre 7

Mise à jour perdue (lost update)

Anomalie dans laquelle deux transactions lisent une valeur, calculent chacune une nouvelle valeur et l’écrivent, de sorte qu’une modification écrase l’autre sans avertissement. Chapitre 7

Mise en cache des prompts (prompt caching)

Réutilisation de l’état calculé par un modèle pour un préfixe de prompt identique vu récemment, ce qui réduit le coût et la latence de la partie répétée. Chapitre 12

Mise en file d’attente (queueing)

Attendre une ressource occupée. La théorie des files d’attente étudie comment le temps d’attente augmente avec le taux d’utilisation ; elle explique pourquoi le temps de réponse grimpe brusquement lorsqu’une ressource approche 100 % d’occupation. Chapitre 2

Mode d’interaction

Dans Team Topologies, l’une des trois manières délibérées dont deux équipes travaillent ensemble : collaboration, X en tant que service ou facilitation. Les modes sont appelés à changer à mesure que les frontières sont découvertes et se stabilisent. Chapitre 11

Model card (fiche de modèle)

Court document publié avec un modèle, qui décrit son usage prévu, ses résultats d’évaluation selon les groupes, ses données d’entraînement, ses limites et les considérations éthiques (Mitchell et al., 2019). Chapitre 12

Model Context Protocol (MCP)

Protocole ouvert, introduit par Anthropic en novembre 2024 et désormais géré au sein de la Linux Foundation, pour connecter des applications d’IA à des serveurs qui exposent des outils, des données et des prompts. Chapitre 12

Modèle à poids ouverts (open-weight)

Modèle dont les poids entraînés sont publiés pour que d’autres puissent l’exécuter, sous une licence qui peut être permissive ou restrictive. Des poids ouverts ne suffisent pas à eux seuls à faire d’un modèle un modèle open source. Chapitre 12

Modèle C4

Approche de Simon Brown pour les diagrammes d’architecture : une hiérarchie de diagrammes de contexte système, de conteneurs, de composants et de code, plus quelques diagrammes complémentaires. Chapitre 4

Modèle client-serveur

Organisation dans laquelle des clients (comme des navigateurs ou des apps mobiles) envoient des requêtes et des serveurs, qui détiennent les données et la logique partagées, y répondent. Chapitre 0

Modèle de charge fermé

Modèle de charge avec un nombre fixe d’utilisateurs, chacun n’envoyant une nouvelle requête qu’après avoir reçu la réponse à la précédente (plus un temps de réflexion), de sorte que la charge baisse quand le système ralentit. Chapitre 9

Modèle de charge ouvert

Modèle de charge dans lequel les nouvelles requêtes arrivent à un rythme fixé, quelle que soit la rapidité avec laquelle les précédentes reçoivent une réponse, comme des clients qui arrivent sur un site web. Chapitre 9

Modèle de cohérence

Contrat qu’un stockage de données offre sur les valeurs que les lectures peuvent renvoyer compte tenu des écritures effectuées, et donc sur les résultats périmés ou réordonnés auxquels les clients doivent être préparés. Chapitre 6

Modèle de domaine

Petit diagramme ou petite description des concepts métier clés d’un système, de leurs attributs et de leurs relations, partagé par les développeurs et les experts du domaine. Chapitre 4

Modèle de données canonique

Représentation unique, à l’échelle de l’entreprise, de chaque entité métier, vers laquelle et depuis laquelle tous les messages sont traduits. Convient rarement bien à toutes les parties d’une entreprise. Chapitre 6

Modèle de qualité

Liste structurée de caractéristiques de qualité et de leurs sous-caractéristiques, utilisée comme vocabulaire commun et comme liste de contrôle pour spécifier ou évaluer la qualité. Chapitre 2

Modèle de raisonnement

Modèle de langage entraîné à générer des tokens de raisonnement intermédiaires avant de répondre, ce qui échange un surcoût et une latence supplémentaire contre de meilleurs résultats sur les tâches difficiles en plusieurs étapes. Chapitre 12

Modèle de responsabilité partagée

La répartition des obligations de sécurité et d’exploitation entre un fournisseur de cloud, qui sécurise le cloud lui-même, et le client, qui sécurise ses données, ses identités et sa configuration dans le cloud. Chapitre 10

Modèle de vues 4+1

Approche de Philippe Kruchten (1995) qui décrit un système à travers des vues logique, de processus, de développement et physique, reliées entre elles par un petit ensemble de scénarios. Chapitre 4

Modèle d’IA à usage général

Selon le règlement européen sur l’IA, modèle d’IA, comme un grand modèle de langage, capable d’exécuter un large éventail de tâches et d’être intégré dans de nombreux systèmes en aval. Chapitre 12

Modèle piloté par les risques

L’approche de George Fairbanks dans laquelle la quantité de travail d’architecture est fixée par les risques auxquels un projet fait face : identifier les risques, appliquer des techniques, évaluer la réduction obtenue. Chapitre 1

Modélisation des menaces

Manière structurée de se demander, à propos d’une conception, ce que l’on construit, ce qui peut mal tourner, ce que l’on va faire à ce sujet et si l’on a fait un travail suffisamment bon. Chapitre 8

Modifiabilité

La facilité et la sûreté avec lesquelles un système peut être modifié à moindre coût : le coût, l’effort et le risque d’un changement, et la mesure dans laquelle il se propage au-delà de l’endroit où il est fait. Chapitre 2

Modularité

Le degré auquel un système est divisé en parties qui peuvent être comprises, modifiées et testées en grande partie isolément. Sous-caractéristique de la maintenabilité dans l’ISO/IEC 25010. Chapitre 3

Module

Unité de code, souvent un seul fichier, qui regroupe sous un même nom des fonctions et des données liées et décide de ce qu’elle met à disposition du reste du code. Un paquet (package) est un groupe de modules. Chapitre 0

Module de sécurité matériel (HSM)

Matériel inviolable qui génère et utilise des clés en son sein et ne les divulgue jamais en clair ; les services KMS reposent généralement sur des HSM. Chapitre 8

Module logique

Unité de responsabilité dans la conception, comme Commandes ou Paiements, indépendamment de la façon dont son code est empaqueté ou déployé. Chapitre 3

Module physique

Unité que l’on construit, versionne ou déploie, comme un fichier JAR, un paquet Python, une image de conteneur ou un service. Une même conception logique peut être empaquetée en modules physiques de bien des façons. Chapitre 3

Module profond

Terme de John Ousterhout pour un module dont l’interface simple cache une grande quantité de fonctionnalités. Un module superficiel offre peu de comportement au regard de la complexité de son interface. Chapitre 3

Moindre privilège

Principe selon lequel chaque utilisateur, programme et service ne reçoit que les permissions dont il a besoin pour sa tâche, et seulement pour la durée nécessaire, afin qu’une erreur ou une compromission cause des dégâts limités. Chapitre 8

Moins de connexions (least connections)

Algorithme d’équilibrage de charge qui envoie chaque nouvelle requête à l’instance ayant le moins de requêtes ou de connexions en cours. Chapitre 9

Moins fréquemment utilisé (LFU)

Politique d’éviction qui retire, lorsque le cache est plein, l’élément lu le moins souvent. Chapitre 7

Moins récemment utilisé (LRU)

Politique d’éviction qui retire, lorsque le cache est plein, l’élément resté le plus longtemps sans être lu. Chapitre 7

Moment de liaison (binding time)

Moment où une décision est figée : à l’écriture du code, au build, au déploiement, au démarrage ou pendant l’exécution du système. Chapitre 2

Monolithe

Système construit et déployé comme une seule unité, même si son code est divisé à l’intérieur en modules bien séparés. Chapitre 1

Monolithe distribué

Système déployé sous forme de services distincts mais si fortement couplés qu’ils doivent être modifiés et publiés ensemble, ce qui cumule les coûts de la distribution sans ses avantages. Chapitre 5

Monolithe modulaire

Application déployable unique dont le code est divisé en modules selon des frontières métier, chacun avec une interface publique explicite et ses propres données. Chapitre 5

MonolithFirst (le monolithe d’abord)

Le conseil de Martin Fowler, en 2015, de commencer un nouveau système sous la forme d’un monolithe bien modularisé et d’en extraire des services plus tard, quand les frontières sont comprises et nécessaires. Chapitre 5

Moteur de recherche

Système de stockage construit autour d’un index inversé des mots vers les documents, qui offre une recherche plein texte classée par pertinence et tolérante aux fautes de frappe ; généralement alimenté à partir d’un système de référence. Chapitre 7

Mouvement latéral

La progression d’un attaquant depuis la première machine ou le premier compte compromis vers d’autres systèmes du même réseau ou de la même organisation. Chapitre 8

Multicloud

Utiliser les services de deux fournisseurs de cloud public ou plus, pour des services qui leur sont propres, à la suite d’acquisitions, pour peser dans les négociations ou pour des plans de sortie exigés par la réglementation. Chapitre 10

Multiplicité

Dans un diagramme de classes UML, le nombre d’objets qui peuvent participer à chaque extrémité d’une association, par exemple 1, 0..1, 0..* ou 1..*. Chapitre 4

N

NIST AI RMF

Le cadre volontaire de gestion des risques liés à l’IA (AI Risk Management Framework) publié par le National Institute of Standards and Technology des États-Unis (version 1.0, 2023), fondé sur les fonctions Govern, Map, Measure et Manage. Chapitre 12

Niveau (tier)

Frontière physique à l’exécution, comme un processus ou un serveur distinct. Une couche est une frontière logique dans le code ; plusieurs couches peuvent s’exécuter dans un même niveau (tier). Chapitre 5

Niveau de gravité

Classification prédéfinie de la gravité d’un incident, par exemple de SEV1 à SEV4, qui détermine qui est appelé, avec quelle rapidité et avec quelle diffusion il est communiqué. Chapitre 9

Niveau d’isolation

Paramètre qui indique dans quelle mesure des transactions concurrentes peuvent s’affecter mutuellement : read uncommitted, read committed, repeatable read, snapshot ou serializable. Les noms n’ont pas le même sens selon les bases de données. Chapitre 7

Nomenclature logicielle (SBOM)

Inventaire lisible par machine des composants et des dépendances d’un logiciel, dans un format standard comme SPDX ou CycloneDX. Chapitre 8

Non-risque

Décision jugée saine pour un scénario donné, consignée avec les hypothèses dont elle dépend, afin de pouvoir la réexaminer si ces hypothèses changent. Chapitre 11

NoSQL

Terme générique désignant les bases de données qui n’utilisent pas le modèle relationnel en tables, comme les bases orientées documents, clé-valeur, colonnes larges et graphes. Chapitre 0

Notation grand O (Big-O)

Manière de décrire comment le travail effectué par un algorithme augmente lorsque la quantité de données augmente, par exemple O(n) pour une croissance linéaire ou O(1) pour un temps constant. Chapitre 0

Notification d’événement

Événement qui ne fait que signaler un changement, en ne transportant souvent qu’un identifiant, de sorte que les destinataires qui ont besoin de détails doivent interroger l’émetteur. Chapitre 6

Noyau partagé (shared kernel)

Petite partie d’un modèle, et de son code, que deux contextes conviennent explicitement de partager et qui ne peut changer qu’avec l’accord des deux équipes. Chapitre 5

O

OAuth 2.0

Le cadre d’autorisation déléguée de la RFC 6749, dans lequel un serveur d’autorisation délivre des jetons d’accès qui permettent à un client d’appeler un serveur de ressources pour le compte d’un propriétaire de ressources, sans voir son mot de passe. Chapitre 8

Objectif de niveau de service (SLO)

Cible interne pour un SLI sur une fenêtre de temps, par exemple 99,9 % de requêtes réussies sur 30 jours. Chapitre 2

Objectif de point de reprise (RPO)

La plus grande quantité de données, mesurée en durée, que l’entreprise peut accepter de perdre en cas de sinistre, par exemple les 15 dernières minutes de modifications. Chapitre 2

Objectif de temps de reprise (RTO)

Le délai le plus long que l’entreprise peut accepter entre un sinistre et le rétablissement du service. Chapitre 2

Objet valeur (value object)

Objet du domaine défini uniquement par ses valeurs, sans identité propre, et généralement immuable, comme un montant d’argent ou une adresse. Chapitre 5

Observabilité

La capacité des personnes à comprendre ce qui se passe à l’intérieur d’un système en fonctionnement à partir des données qu’il émet (journaux, métriques, traces), y compris pour des problèmes que personne n’avait anticipés. Chapitre 2

Octet (byte)

Groupe de huit bits, pouvant prendre 256 valeurs différentes. La taille des fichiers et de la mémoire se compte en octets (kilo-octets, mégaoctets, gigaoctets). Chapitre 0

Offset (décalage)

La position séquentielle d’un événement au sein d’une partition ; les consommateurs enregistrent l’offset qu’ils ont atteint afin de pouvoir reprendre après un redémarrage. Chapitre 6

OLAP

Online analytical processing (traitement analytique en ligne) : charges de travail faites de grosses requêtes qui parcourent et agrègent de nombreux enregistrements, comme le chiffre d’affaires par région et par mois. Chapitre 7

OLTP

Online transaction processing (traitement transactionnel en ligne) : charges de travail faites de nombreuses petites lectures et écritures d’enregistrements individuels, comme passer des commandes ou enregistrer des paiements. Chapitre 7

Omission coordonnée (coordinated omission)

Erreur de mesure, nommée par Gil Tene, dans laquelle un générateur de charge attend les réponses lentes avant d’envoyer d’autres requêtes et n’enregistre donc jamais les délais que de vrais utilisateurs auraient subis. Chapitre 9

Open Container Initiative (OCI)

Projet de la Linux Foundation, fondé en 2015, qui maintient des normes ouvertes pour les formats d’images de conteneurs, les environnements d’exécution (runtimes) et les registres, afin que les outils de différents fournisseurs soient interopérables. Chapitre 10

OpenAPI

Format standard, lisible par machine, pour décrire les API HTTP (chemins, opérations, paramètres, schémas), anciennement la spécification Swagger. Il sert de base à la documentation, à la génération de code et aux tests. Chapitre 6

OpenID Connect (OIDC)

Couche d’identité au-dessus d’OAuth 2.0 qui ajoute un jeton d’identité (ID token), un JWT signé indiquant au client qui est l’utilisateur, ainsi que comment et quand il s’est authentifié. Chapitre 8

OpenTelemetry

Projet open source de la CNCF, indépendant des fournisseurs, qui fournit des API, des SDK, un protocole (OTLP) et un collecteur pour produire et exporter des traces, des métriques et des journaux. Chapitre 9

OpenTofu

Fork open source de Terraform créé en 2023 après le passage de Terraform sous Business Source Licence par HashiCorp ; hébergé par la Linux Foundation et projet de la CNCF. Chapitre 10

Orchestrateur de saga

Composant qui coordonne une saga en envoyant des commandes aux participants, en suivant la progression dans une machine à états persistante et en déclenchant les compensations en cas de défaillance. Chapitre 6

Orchestration

Coordination d’un processus en plusieurs étapes par un composant unique qui dit à chaque participant quoi faire et décide de la suite. Chapitre 6

Orchestration de conteneurs

Placement automatique des conteneurs sur des machines et maintien de leur fonctionnement : redémarrage après défaillance, mise à l’échelle, déploiement progressif de nouvelles versions et connexion aux réseaux et au stockage. Chapitre 10

Organisation en couches (layering)

Disposer les modules en couches où chaque couche ne peut utiliser que les couches situées en dessous. Une organisation en couches stricte n’autorise que la couche immédiatement inférieure ; une organisation en couches souple autorise n’importe quelle couche inférieure. Chapitre 3

Outbox transactionnelle (transactional outbox)

Patron dans lequel un service écrit les messages sortants dans une table outbox au sein de la même transaction locale que sa modification métier ; un relais les publie ensuite, ce qui assure une livraison au moins une fois (at-least-once) sans transaction distribuée. Chapitre 6

Outil de dessin

Outil de création de diagrammes qui ne connaît que des formes, des traits et du texte, de sorte qu’un même élément dessiné dans deux diagrammes n’a aucun lien d’un diagramme à l’autre. Chapitre 4

Outil de modélisation

Outil qui stocke des éléments et des relations dans un modèle et génère des diagrammes comme autant de vues de ce modèle, en assurant la cohérence de toutes les vues. Chapitre 4

P

PaaS (plateforme en tant que service)

Modèle de cloud dans lequel vous fournissez le code de votre application ou votre conteneur, et le fournisseur exécute, corrige et met à l’échelle la plateforme sous-jacente. Chapitre 0

PACELC

L’extension de CAP proposée par Daniel Abadi : en cas de Partition, arbitrer entre disponibilité (Availability) et cohérence (Consistency) ; sinon (Else), en fonctionnement normal, arbitrer entre latence (Latency) et cohérence (Consistency). Chapitre 6

Page de statut

Page publique ou destinée aux clients qui signale les incidents en cours et l’état de santé du service, mise à jour par la personne chargée de la communication pendant l’incident. Chapitre 9

Pagination par curseur

Parcours d’une collection page par page en transmettant un token opaque qui marque le dernier élément vu, plutôt qu’un offset numérique. Elle reste rapide et stable lorsque des éléments sont ajoutés pendant la pagination. Chapitre 6

Paiement à l’usage (pay-as-you-go)

Modèle de tarification dans lequel les ressources ne vous sont facturées que pendant que vous les utilisez, par exemple à la seconde de temps serveur ou au gigaoctet stocké. Chapitre 0

Paquet (réseau)

Petit bloc de données envoyé sur un réseau avec des informations d’adressage. Les messages volumineux sont découpés en de nombreux paquets, réassemblés à l’autre bout. Chapitre 0

Partie prenante

Personne, équipe ou organisation qui a un intérêt dans un système, comme les utilisateurs, les commanditaires, les développeurs, les exploitants, les responsables de la sécurité ou les autorités de régulation. Chapitre 1

Partition (d’un topic)

Dans Kafka et les journaux similaires, une partie ordonnée d’un topic, en ajout seul (append-only). Les événements de même clé vont dans la même partition ; l’ordre n’est garanti qu’à l’intérieur de celle-ci. Chapitre 6

Partition réseau

Faute réseau qui divise un système en groupes de nœuds incapables de communiquer entre eux, bien que chaque groupe puisse encore fonctionner et rester joignable par certains clients. Chapitre 6

Partitionnement (sharding)

Découper un jeu de données de sorte que chaque machine n’en détienne qu’une partie, choisie au moyen d’une clé de partition, afin de faire passer les écritures et le stockage à l’échelle au-delà d’une seule machine. Chapitre 7

Partitionnement par domaine

Division de la structure de premier niveau d’un système par capacité métier ou par sous-domaine, comme les commandes, les paiements et la livraison. Chapitre 5

Partitionnement technique

Diviser la structure de premier niveau d’un système selon le rôle technique, comme l’interface utilisateur, la logique métier et l’accès aux données. Chapitre 5

Passkey (clé d’accès)

Identifiant FIDO2/WebAuthn : une paire de clés créée pour un site web donné, dont la clé privée reste sur l’appareil ou dans le gestionnaire de mots de passe de l’utilisateur, ce qui rend la connexion résistante à l’hameçonnage et ne laisse aucun secret partagé sur le serveur. Chapitre 8

Patron architectural

Solution documentée et réutilisable à un problème structurel récurrent dans un contexte donné, qui nomme les parties, leurs responsabilités et leurs relations. Souvent employé comme synonyme de style. Chapitre 5

Patron de conception (design pattern)

Solution réutilisable à un problème récurrent à l’échelle de quelques classes ou objets, comme Strategy ou Observer ; de portée plus restreinte qu’un patron architectural. Chapitre 5

Paved road (golden path, chemin balisé)

Manière par défaut, prise en charge et bien documentée, de construire et d’exécuter des logiciels, par exemple un modèle de service où la journalisation, la sécurité et le déploiement sont déjà configurés, dont les équipes peuvent s’écarter lorsqu’elles ont une bonne raison. Chapitre 11

Percentile (p95, p99)

La valeur sous laquelle se situe une proportion donnée des mesures. Un p99 de 400 ms signifie que 99 % des requêtes ont pris 400 ms ou moins et que 1 % ont pris plus longtemps. Chapitre 2

Persistance polyglotte

Utiliser différents types de bases de données pour différentes données au sein d’un même système, choisis selon l’usage de chaque jeu de données, au prix d’un plus grand nombre de technologies à exploiter. Chapitre 7

Perspective

Dans l’approche de Rozanski et Woods, une préoccupation de qualité, comme la sécurité ou les performances, appliquée à l’ensemble des vues plutôt que représentée comme une vue à part. Chapitre 4

Pilot light (veilleuse)

Stratégie de reprise après sinistre qui maintient les données répliquées et l’infrastructure essentielle provisionnée dans une seconde région, mais ne démarre et ne met à l’échelle les serveurs d’application qu’en cas de sinistre. Chapitre 10

Pipeline CI/CD

Suite automatisée d’étapes (build, test, déploiement en staging, déploiement en production) par laquelle passe chaque modification pour parvenir aux utilisateurs. Chapitre 0

Pipeline de déploiement

Suite automatisée d’étapes (build, tests, empaquetage, déploiement, vérification) par laquelle passe chaque modification entre un commit et la production. Chapitre 10

Piste architecturale (architectural runway)

Dans le Scaled Agile Framework, le code, les composants et l’infrastructure existants nécessaires pour implémenter les fonctionnalités à court terme sans refonte ni retard excessifs. Chapitre 1

Piste d’audit

Enregistrement complet, chronologique et infalsifiable sans trace des actions définies, montrant qui a fait quoi et quand, conservé pour établir les responsabilités. Chapitre 8

PKCE

Proof Key for Code Exchange (RFC 7636) : le client envoie l’empreinte d’un secret à usage unique lorsqu’il démarre le flux de code d’autorisation, puis le secret lui-même lorsqu’il échange le code, de sorte qu’un code volé est inutilisable. Chapitre 8

Plan de contrôle (control plane)

Composants qui prennent les décisions pour un cluster ou un système (dans Kubernetes : le serveur d’API, etcd, l’ordonnanceur et les contrôleurs), par opposition aux nœuds qui exécutent les charges de travail. Chapitre 10

Plan de fracture

Ligne de séparation naturelle le long de laquelle un système logiciel peut être découpé afin que chaque partie convienne à une équipe, par exemple un contexte délimité, une frontière réglementaire, un rythme de changement différent ou un profil de risque différent. Chapitre 11

Planification de la capacité

Prévision de la demande future, mesure de ce que chaque unité d’infrastructure peut traiter et mise en place d’une capacité suffisante, avec une marge, avant qu’elle ne soit nécessaire. Chapitre 9

Plateforme interne de développement (IDP)

Ensemble d’outils, de services, de modèles et de documentation en libre-service que l’équipe plateforme d’une organisation fournit afin que les équipes produit puissent construire et exploiter des logiciels sans passer par des tickets. Chapitre 10

Plateforme viable la plus fine (thinnest viable platform)

Le plus petit ensemble de services partagés et de documentation qui accélère réellement les équipes produit ; la mise en garde de Team Topologies contre le fait de construire plus de plateforme que nécessaire. Chapitre 10

Plug-in

Module construit séparément qui ajoute un comportement à une application hôte au moyen d’un contrat publié par l’hôte, sans que le code de l’hôte soit modifié. Chapitre 5

Pod

La plus petite unité déployable dans Kubernetes : un ou plusieurs conteneurs planifiés ensemble sur un même nœud, qui partagent une adresse réseau et des volumes de stockage. Chapitre 10

Point de compromis

Décision architecturale qui affecte plus d’un attribut de qualité, en améliorant l’un tout en nuisant à un autre. Chapitre 2

Point de décision de politique (PDP)

Le composant qui évalue la politique d’accès et répond « autoriser » ou « refuser » ; un point d’application de politique (PEP) l’interroge, puis applique la réponse. Chapitre 8

Point de sensibilité

Propriété d’un ou de plusieurs composants ou connexions qui est déterminante pour obtenir une réponse de qualité donnée, comme le nombre de sauts synchrones sur le chemin de la commande. Chapitre 11

Point de validation (gate)

Point de contrôle où le travail s’arrête jusqu’à ce que quelqu’un l’approuve, comme la validation d’un comité de revue avant le build ou la mise en production. Chapitre 11

Point de vue

Spécification de la manière de construire et de lire un type de vue d’architecture : quelles parties prenantes et quelles préoccupations elle sert, et quelles conventions de modélisation elle utilise. Chapitre 1

Point d’application de politique (PEP)

Le composant situé sur le chemin du trafic, comme un proxy, une passerelle ou un sidecar, qui autorise ou bloque chaque requête selon une décision de politique. Chapitre 8

Point d’entrée (packaging Python)

Métadonnées d’un paquet Python installé qui annoncent un objet, comme une classe de plug-in, sous un groupe nommé afin qu’un autre code puisse le découvrir à l’exécution. Chapitre 5

Point d’extension

Emplacement nommé qu’une application hôte ou un plug-in déclare pour que d’autres plug-ins puissent y apporter du comportement, comme dans la plateforme Eclipse. Chapitre 5

Politique de budget d’erreur

Énoncé écrit et convenu de ce qu’une équipe fera lorsque son budget d’erreur est dépensé trop vite ou épuisé, comme le gel des mises en production risquées. Chapitre 9

Politique en tant que code (policy as code)

Écrire les règles portant sur l’infrastructure et les déploiements (pas de stockage public, chiffrement obligatoire, régions approuvées) sous forme de code que des outils vérifient automatiquement avant ou pendant les changements. Chapitre 10

Port

Nombre de 0 à 65535 qui identifie le programme d’un appareil qui doit recevoir le trafic réseau, par exemple 443 pour HTTPS. Chapitre 0

Portail des développeurs

Interface web, comme Backstage, qui rassemble en un seul endroit un catalogue de logiciels, des modèles, de la documentation et des liens vers les services de la plateforme. Chapitre 10

Ports et adaptateurs (architecture hexagonale)

Le style d’Alistair Cockburn dans lequel une application ne communique avec le monde extérieur qu’au travers de ports (des interfaces qui lui appartiennent), et où des adaptateurs font la traduction entre chaque port et une technologie particulière. Chapitre 5

Postcondition

Condition qu’une opération garantit vraie lorsqu’elle se termine, à condition que sa précondition ait été remplie. Chapitre 3

Pre-mortem

Technique de Gary Klein (2007) dans laquelle une équipe imagine que son projet a déjà échoué et où chaque personne écrit pourquoi, ce qui fait émerger des risques que l’on hésite sinon à soulever. Chapitre 11

Précision et rappel (precision and recall)

La précision est la proportion des éléments signalés par un modèle qui sont réellement positifs ; le rappel est la proportion des positifs réels que le modèle détecte. Augmenter l’une fait généralement baisser l’autre. Chapitre 12

Précondition

Condition qui doit être vraie avant l’appel d’une opération ; la remplir est l’obligation de l’appelant. Chapitre 3

Préoccupation

Intérêt qu’une partie prenante porte à un système, comme son coût, ses performances, sa sécurité, sa facilité de modification ou sa conformité juridique. Chapitre 1

Préoccupation transversale (cross-cutting concern)

Préoccupation qui touche simultanément de nombreuses parties d’un système, comme la journalisation, la sécurité, la gestion des erreurs ou la persistance, et qui fait donc généralement l’objet d’une décision unique pour tout le système. Chapitre 1

Preuve de concept (proof of concept)

Petit morceau de code fonctionnel, réalisé en un temps limité, pour vérifier si une idée, une technologie ou un choix de conception fonctionne avant de s’y engager. Chapitre 1

Principal (de la dette technique)

L’effort nécessaire pour corriger un élément de dette technique, c’est-à-dire pour amener le code ou la structure à l’état dans lequel il devrait être. Chapitre 1

Principe de fermeture commune (CCP)

Les classes qui changent pour les mêmes raisons et aux mêmes moments appartiennent au même composant ; c’est le principe de responsabilité unique appliqué aux composants. Chapitre 3

Principe de responsabilité unique (SRP)

Un module doit rendre des comptes à un seul acteur : un seul groupe de personnes qui en demandent les modifications. Le code qui change pour des raisons différentes, à la demande de personnes différentes, doit être séparé. Chapitre 3

Principe de réutilisation commune (CRP)

Les classes utilisées ensemble vont ensemble, et les utilisateurs d’un composant ne doivent pas être contraints de dépendre de classes qu’ils n’utilisent pas. Chapitre 3

Principe de ségrégation des interfaces (ISP)

Les clients ne doivent pas être contraints de dépendre d’opérations qu’ils n’utilisent pas ; préférez plusieurs petites interfaces propres à chaque client à une seule grande interface. Chapitre 3

Principe de substitution de Liskov (LSP)

Tout ce qui se présente comme un sous-type doit pouvoir être utilisé partout où son supertype est attendu sans que l’appelant remarque de différence de comportement. Nommé d’après Barbara Liskov. Chapitre 3

Principe des abstractions stables

Le principe de Robert C. Martin selon lequel un composant doit être aussi abstrait qu’il est stable, afin que les composants stables puissent malgré tout être étendus. Chapitre 3

Principe des dépendances acycliques

Principe de Robert C. Martin selon lequel le graphe de dépendances entre composants ne doit contenir aucun cycle. Chapitre 3

Principe des dépendances stables

Le principe de Robert C. Martin selon lequel un composant ne doit dépendre que de composants plus stables que lui : il faut dépendre dans le sens de la stabilité. Chapitre 3

Principe d’architecture

Règle durable qui guide les décisions d’architecture, rédigée dans le style TOGAF avec un nom, un énoncé, une justification et ses implications. Chapitre 11

Principe d’équivalence réutilisation/publication (REP)

L’unité de réutilisation est l’unité de publication : les classes regroupées dans un composant doivent avoir un sens à être publiées, versionnées et réutilisées ensemble. Chapitre 3

Principe d’inversion des dépendances (DIP)

La politique de haut niveau ne doit pas dépendre des détails de bas niveau ; les deux doivent dépendre d’abstractions, et l’abstraction doit appartenir au côté de la politique. Chapitre 3

Principe ouvert-fermé (OCP)

Un module doit être ouvert à l’extension mais fermé à la modification : un nouveau comportement doit s’ajouter en ajoutant du code, par exemple une nouvelle implémentation d’une interface, et non en modifiant du code qui fonctionne. Énoncé pour la première fois par Bertrand Meyer en 1988. Chapitre 3

Prise de décision par consentement

Règle de décision dans laquelle une proposition est adoptée sauf si quelqu’un soulève une objection motivée selon laquelle elle causerait un tort ou ferait reculer le groupe ; elle demande si chacun peut vivre avec une proposition, et non si chacun la préfère. Chapitre 11

Problem details (RFC 9457)

Format JSON standard pour les erreurs des API HTTP, avec les membres type, title, status, detail et instance, servi en application/problem+json. La RFC 9457 (2023) a remplacé la RFC 7807. Chapitre 6

Problème des requêtes N+1

Défaut de performance dans lequel le code effectue une requête pour récupérer une liste de N éléments, puis une requête supplémentaire par élément, soit N+1 allers-retours là où une ou deux suffiraient. Chapitre 6

Processus

Instance en cours d’exécution d’un programme, avec sa propre mémoire privée et sa part de temps CPU, créée et gérée par le système d’exploitation. Chapitre 0

Processus de consultation (advice process)

Mode de prise de décision décentralisé dans lequel chacun peut décider, à condition d’avoir d’abord demandé l’avis des personnes concernées et des experts compétents. Chapitre 4

Processus d’arrière-plan (background worker)

Processus qui prend dans une file des tâches lentes ou arrivant par rafales, comme des e-mails ou des rapports, et les traite en dehors de la requête qui les a créées. Chapitre 5

Production

L’environnement réel dont dépendent les vrais utilisateurs et les vraies données. Chapitre 0

Produit de données (data product)

Jeu de données publié par une équipe de domaine pour que d’autres l’utilisent, avec un propriétaire, une documentation, des garanties de qualité et une interface stable. Chapitre 7

Programme

Liste d’instructions précises qu’un ordinateur suit pour accomplir une tâche. Un programme en cours d’exécution s’appelle un processus. Chapitre 0

Projection

Code qui écoute des changements ou des événements et tient à jour un modèle de lecture ; le terme désigne aussi le modèle de lecture ainsi produit. Chapitre 7

Prompt

Tout ce qui est envoyé à un modèle de langage en un seul appel : instructions système, historique de la conversation, documents récupérés, définitions d’outils et message de l’utilisateur. Chapitre 12

Propagation des échéances (deadline propagation)

Transmission du temps restant pour l’ensemble d’une requête à chaque appel en aval, afin qu’aucun service ne continue à travailler sur une requête que son appelant a déjà abandonnée. Chapitre 9

Propagation du contexte

Transmission des identifiants de trace (et d’autres éléments du contexte de la requête) d’un service au suivant avec chaque appel ou message, par exemple dans l’en-tête W3C traceparent. Chapitre 9

Propriété conjointe

Situation dans laquelle plusieurs services écrivent tous les mêmes données. On peut la résoudre en scindant la table, en créant un petit domaine de données partagé, en confiant les écritures à un seul propriétaire ou en fusionnant les services. Chapitre 7

Propriété des données

Règle selon laquelle chaque donnée est écrite par exactement un module ou service, que les autres doivent interroger plutôt que de lire ou de modifier directement son stockage. Chapitre 3

Protection des données dès la conception et par défaut

Obligation de l’article 25 du RGPD d’intégrer les principes de protection des données dans les systèmes au moyen de mesures appropriées, et de ne traiter par défaut que les données nécessaires à chaque finalité. Chapitre 8

Protocol Buffers

Format binaire compact et indépendant du langage pour les données structurées, défini dans des fichiers .proto où chaque champ porte un numéro permanent. Utilisé par gRPC et de nombreux systèmes de messagerie. Chapitre 6

Provenance

Informations vérifiables sur l’origine d’un artefact : quelle plateforme de build l’a construit, à partir de quelle révision du code source, avec quelles entrées et quels paramètres. Chapitre 8

Provenance des données

Origine et historique documentés des données : d’où elles viennent, sous quelle licence ou avec quel consentement, et comment elles ont été transformées. Chapitre 12

Pseudonymisation

Traiter des données à caractère personnel de façon qu’elles ne puissent plus être attribuées à une personne sans recourir à des informations supplémentaires conservées séparément ; au sens du RGPD, les données pseudonymisées restent des données à caractère personnel. Chapitre 8

Publication-abonnement (publish-subscribe)

Patron de messagerie dans lequel un éditeur envoie un message à un topic et chaque abonné en reçoit sa propre copie, sans que l’éditeur sache qui ils sont. Chapitre 6

Puissance de deux choix aléatoires (power of two choices)

Méthode d’équilibrage de charge qui choisit deux instances au hasard et envoie la requête à la moins chargée ; Mitzenmacher a montré qu’elle équilibre presque aussi bien que la vérification de chaque instance. Chapitre 9

Pull request

Demande de fusion d’une branche dans la ligne principale, sur un service comme GitHub, où des collègues relisent le changement et où des vérifications automatisées s’exécutent avant qu’il soit accepté. Chapitre 0

Pyramide de la connaissance

Modèle à trois couches : ce que vous savez, ce que vous savez ne pas savoir, et ce que vous ne savez pas que vous ne savez pas. Les architectes élargissent délibérément la couche du milieu. Chapitre 1

Pyramide des tests

Repère, dû à Mike Cohn, sur les proportions des tests automatisés : beaucoup de tests unitaires rapides, moins de tests d’intégration et seulement quelques tests de bout en bout, lents. Chapitre 0

Q

Qualité en utilisation

La qualité qu’un produit apporte aux personnes dans un contexte d’utilisation donné (s’il est bénéfique, exempt de risque et acceptable). Depuis 2023, elle a sa propre norme, l’ISO/IEC 25019. Chapitre 2

Quality Attribute Workshop (QAW)

Méthode animée du SEI dans laquelle les parties prenantes proposent, regroupent, votent et affinent des scénarios d’attributs de qualité au début d’un projet. Chapitre 2

Quantum d’architecture (architecture quantum)

Partie d’un système déployable indépendamment, à forte cohésion fonctionnelle, qui comprend tout ce dont elle a besoin pour fonctionner, comme sa base de données ; le périmètre au sein duquel s’applique un même ensemble de caractéristiques d’architecture. Chapitre 5

Quatre signaux d’or (four golden signals)

Latence, trafic, erreurs et saturation : les quatre mesures que le livre SRE de Google recommande de superviser pour tout système en contact avec les utilisateurs. Chapitre 9

Quorum (R + W > N)

Dans un système de stockage à N répliques, une écriture attend W accusés de réception et une lecture R réponses ; si R + W > N, chaque ensemble de lecture recoupe chaque ensemble d’écriture sur au moins une réplique. Chapitre 6

R

Racine de composition

Endroit unique, généralement le code de démarrage du programme, où les adaptateurs concrets sont créés et branchés sur l’application. Chapitre 5

Radar technologique

Carte des technologies et des techniques, actualisée périodiquement, regroupées en quadrants et placées sur des anneaux comme Adopt, Trial, Assess et Hold (renommé Caution dans les éditions récentes de Thoughtworks), popularisée par Thoughtworks. Chapitre 11

RAM (mémoire)

Mémoire vive (random-access memory) : stockage rapide et temporaire qui contient les programmes et les données utilisés en ce moment. Son contenu est perdu lorsque l’alimentation est coupée ou que le programme se termine. Chapitre 0

Rapatriement depuis le cloud (cloud repatriation)

Déplacement de charges de travail hors d’un cloud public vers du matériel détenu en propre ou hébergé en colocation, généralement parce qu’une charge stable rend la propriété moins chère. Chapitre 10

Rayon d’impact (blast radius)

Part du système et nombre d’utilisateurs qu’une défaillance, une modification ou une expérience peut affecter ; les expériences de chaos le maintiennent délibérément réduit. Chapitre 9

Re-ranking (reclassement)

Seconde étape de recherche dans laquelle un modèle plus précis mais plus lent attribue une nouvelle note aux meilleurs candidats de la première étape et ne garde que les quelques meilleurs. Chapitre 12

ReAct

Reasoning and acting (raisonner et agir ; Yao et ses collègues, 2022) : patron dans lequel un modèle alterne étapes de raisonnement et actions, et utilise chaque observation pour décider de l’étape suivante. Chapitre 12

Recherche approximative des plus proches voisins

Recherche rapide des vecteurs les plus proches d’un vecteur de requête à l’aide d’un index qui sacrifie un peu de rappel pour de grands gains de vitesse. Chapitre 12

Recherche hybride

Recherche qui combine les résultats par mots-clés (creux) et par embeddings (denses), généralement en fusionnant leurs classements, pour tirer parti des points forts des deux. Chapitre 12

Récit utilisateur (user story)

Courte description d’une fonctionnalité du point de vue de la personne qui la souhaite, souvent rédigée ainsi : En tant que [rôle], je veux [capacité], afin de [bénéfice]. Chapitre 0

Red teaming

Tests adverses délibérés dans lesquels des personnes ou des outils tentent de faire dysfonctionner un système, de lui faire divulguer des données ou de lui faire causer des dommages, afin que les faiblesses soient découvertes avant que des attaquants ne les trouvent. Chapitre 12

Redimensionnement (rightsizing)

Ajuster la taille des ressources provisionnées (types de machines, requêtes des conteneurs, niveaux de base de données) à ce qu’une charge de travail utilise réellement. Chapitre 10

Redondance

Disposer de plus d’un exemplaire d’un composant afin qu’un autre puisse prendre le relais en cas de défaillance de l’un d’eux. Chapitre 2

Réécriture big bang

Remplacement d’un système en en construisant un nouveau à partir de zéro et en basculant d’un seul coup ; largement considéré comme très risqué, car la valeur n’arrive qu’à la fin et le comportement caché se perd facilement. Chapitre 11

Refactorisation (refactoring)

Modifier la structure interne du code sans changer son comportement externe, pour le rendre plus facile à comprendre et à modifier. Chapitre 1

Région

Zone géographique, comme l’Europe de l’Ouest ou l’Est des États-Unis, où un fournisseur de cloud exploite un groupe distinct de centres de données. Les régions sont isolées les unes des autres. Chapitre 0

Registre de plug-ins

La partie d’un système central qui enregistre les plug-ins disponibles, leurs noms, leurs versions et leurs contrats, afin que le système central puisse les trouver sans les nommer dans le code. Chapitre 5

Registre de schémas

Service qui stocke chaque version de chaque schéma de message et rejette les nouvelles versions qui enfreignent la règle de compatibilité convenue. Chapitre 7

Registre des risques

Liste tenue à jour des risques identifiés, avec leur probabilité, leur impact, leur responsable, leur atténuation et leur statut, afin que les risques soient suivis jusqu’à leur clôture au lieu d’être oubliés après une réunion. Chapitre 11

Règle de dépendance

Règle de Robert C. Martin pour la clean architecture : les dépendances du code source pointent uniquement vers l’intérieur, de sorte que les anneaux intérieurs ne nomment jamais rien de ce qui est déclaré dans les anneaux extérieurs. Chapitre 5

Règlement européen sur l’IA (AI Act)

Règlement (UE) 2024/1689, la législation de l’Union européenne sur l’intelligence artificielle fondée sur les risques, modifié en 2026 par le règlement (UE) 2026/1744. Chapitre 12

Règlement sur la cyberrésilience (Cyber Resilience Act, CRA)

Règlement (UE) 2024/2847, qui fixe des exigences de cybersécurité ainsi que des obligations de gestion et de signalement des vulnérabilités pour les produits matériels et logiciels vendus dans l’UE. Chapitre 8

Regroupement des requêtes (request coalescing)

Laisser une seule requête aller chercher un élément manquant pendant que les autres requêtes portant sur le même élément attendent son résultat et le partagent ; on parle aussi de single flight. Chapitre 7

Relation

Lien entre des éléments, par exemple un module qui en utilise un autre, un service qui en appelle un autre ou un service déployé sur un serveur. Chapitre 1

Remise pour engagement d’utilisation

Prix réduit en échange d’un engagement sur un niveau d’utilisation ou de dépense pendant un ou trois ans, comme les instances réservées, les savings plans ou les committed use discounts. Chapitre 10

Réplication

Conserver des copies des mêmes données sur plusieurs machines pour la disponibilité, la capacité de lecture et une latence plus faible à proximité des utilisateurs. Chapitre 7

Réplication leader-suiveur

Schéma de réplication dans lequel un nœud (le leader, ou primaire) accepte toutes les écritures et transmet en continu ses modifications à des suiveurs (répliques), qui peuvent servir les lectures. Chapitre 7

Réplication multi-leader

Schéma dans lequel plusieurs nœuds acceptent des écritures et se répliquent mutuellement, ce qui exige un moyen de détecter et de résoudre les écritures conflictuelles. Chapitre 7

Réplication sans leader

Schéma inspiré de Dynamo dans lequel les clients écrivent et lisent directement sur plusieurs répliques et utilisent des quorums au lieu d’un leader unique. Chapitre 7

Réplique en lecture (read replica)

Copie d’une base de données qui reçoit les modifications de la base primaire et sert les requêtes de lecture, ce qui réduit la charge sur la base primaire au prix de données légèrement périmées. Chapitre 5

Réponse aux incidents

Traitement organisé d’un incident de sécurité : le détecter et l’analyser, le contenir, éliminer la cause, rétablir le service et en tirer des enseignements. Chapitre 8

Repository (entrepôt)

Objet qui charge et enregistre des agrégats entiers et se présente au domaine comme une collection, en masquant comment et où ils sont stockés. Chapitre 5

Reprise après sinistre (DR)

Plans, copies et procédures qui rétablissent un service et ses données après une défaillance de grande ampleur, comme la perte d’un centre de données ou d’une région entière. Chapitre 10

Requête de couverture (hedged request)

Envoi d’une seconde copie d’une requête lente à une autre réplique après un court délai, en utilisant la première réponse qui arrive, afin de réduire la latence de queue. Chapitre 9

Requêtes et limites de ressources (requests and limits)

Réglages de CPU et de mémoire propres à chaque conteneur dans Kubernetes : les requêtes (requests) réservent de la capacité et guident la planification ; les limites (limits) plafonnent la consommation, en bridant le CPU et en arrêtant les conteneurs qui dépassent leur mémoire. Chapitre 10

Réseau de diffusion de contenu (CDN)

Réseau de serveurs répartis en de nombreux endroits qui conserve des copies de contenus comme les images, les scripts et les vidéos à proximité des utilisateurs, afin qu’ils se chargent plus vite et que le serveur d’origine travaille moins. Chapitre 0

Résidence des données

Exigence selon laquelle certaines données doivent être stockées, et parfois traitées, uniquement dans un pays ou une région donnés. Chapitre 2

Résilience

La capacité plus large d’un système à absorber une perturbation, à maintenir son service essentiel (éventuellement sous une forme dégradée) et à revenir ensuite à la normale. Chapitre 2

Responsable du traitement (controller)

Organisation qui détermine les finalités et les moyens du traitement des données à caractère personnel et qui porte la responsabilité première du respect du droit de la protection des données. Chapitre 8

REST (Representational State Transfer)

Style architectural pour les API web, décrit par Roy Fielding en 2000, dans lequel les clients agissent sur des ressources identifiées par des URL au moyen des méthodes HTTP standard. Chapitre 0

Résumé d’architecture en une page

Une page unique qui présente l’objectif d’un système, ses objectifs de qualité, son contexte, ses principaux blocs de construction, ses décisions clés et ses risques, comme porte d’entrée vers une documentation plus complète. Chapitre 4

Retard de réplication (replication lag)

Le délai entre une écriture sur le leader et son apparition sur un suiveur ; il conduit les utilisateurs à lire des données périmées. Chapitre 7

Retour arrière (rollback)

Ramener un système à un état ou à une version antérieure connue comme saine après qu’un changement a causé des problèmes. Chapitre 2

Rétrocompatibilité

Une modification de schéma est rétrocompatible lorsque le code utilisant le nouveau schéma peut encore lire les données écrites avec l’ancien. Chapitre 7

Réversibilité

La facilité et la sûreté avec lesquelles on peut revenir sur une décision à moindre coût. Les décisions très réversibles peuvent être prises rapidement ; les décisions irréversibles méritent une analyse plus poussée. Chapitre 1

Revue de code

Examen d’une modification de code proposée par des collègues avant sa fusion, afin de trouver des défauts, de partager les connaissances et de garder une conception cohérente. Chapitre 0

Revue de conception (revue de RFC)

Revue écrite d’un document de conception proposé ou d’une demande de commentaires (request for comments), dans laquelle les personnes concernées commentent de manière asynchrone avant que la conception ne soit approuvée et ses décisions consignées. Chapitre 11

Revue post-incident

Réunion structurée et rapport écrit, après un incident, qui reconstituent ce qui s’est passé, pourquoi cela paraissait logique aux personnes impliquées et ce qui va changer ; on parle aussi de postmortem. Chapitre 9

Risk-storming

Technique collaborative de Simon Brown dans laquelle les participants marquent en silence les risques sur des diagrammes d’architecture avec des notes adhésives, notées selon la probabilité et l’impact, puis rapprochent leurs points de vue et s’accordent sur les priorités et les atténuations. Chapitre 11

Risque (dans l’évaluation d’architecture)

Décision architecturale, ou absence de décision, susceptible d’empêcher le système de satisfaire une exigence de qualité ou un objectif métier important. Chapitre 11

Roll forward (correction vers l’avant)

Se remettre d’une mauvaise version en déployant un nouveau correctif plutôt qu’en revenant à la version précédente. Chapitre 10

Runbook (procédure d’exploitation)

Procédure écrite et testée pour traiter pas à pas une situation d’exploitation ou de sécurité précise, y compris la manière de vérifier chaque étape et de revenir en arrière. Chapitre 8

S

SaaS (logiciel en tant que service)

Logiciel complet utilisé par Internet, généralement au moyen d’un navigateur ou d’une application, le fournisseur se chargeant de tout faire fonctionner. Chapitre 0

Saga

Transaction métier mise en œuvre sous la forme d’une suite de transactions locales, chacune associée à une transaction compensatoire, de sorte que soit toutes les étapes aboutissent, soit les étapes terminées sont annulées sur le plan sémantique. Introduite par Garcia-Molina et Salem en 1987. Chapitre 6

Sandbox (bac à sable)

Environnement isolé, aux permissions, à l’accès réseau et aux ressources strictement limités, dans lequel du code non fiable, comme du code écrit par un modèle, peut s’exécuter en toute sécurité. Chapitre 12

Sauvegarde

Copie des données conservée séparément de l’original afin de pouvoir les restaurer après une perte, une corruption ou une suppression. Chapitre 0

Sauvegarde immuable

Copie de sauvegarde qui ne peut être ni modifiée ni supprimée avant la fin de sa durée de conservation, même par un administrateur, ce qui la protège contre les rançongiciels et les personnes malveillantes en interne. Chapitre 8

Scalabilité

La capacité d’un système à absorber davantage de charge en ajoutant des ressources, idéalement avec une augmentation prévisible et à peu près proportionnelle de la capacité et du coût. Chapitre 2

Scalabilité horizontale (scaling out)

Absorber davantage de charge en ajoutant des machines et en répartissant le travail entre elles, généralement derrière un équilibreur de charge. Chapitre 0

Scalabilité verticale (scaling up)

Absorber davantage de charge en passant à une machine plus puissante, dotée de plus de processeurs ou de mémoire. Chapitre 0

Scénario concret

Scénario rédigé pour un système particulier, avec des acteurs, des événements, des conditions et des chiffres précis, prêt à servir de base à la conception et aux tests. Chapitre 2

Scénario d’attribut de qualité

Énoncé court et testable d’une exigence de qualité en six parties : source du stimulus, stimulus, artefact, environnement, réponse et mesure de la réponse. Chapitre 2

Scénario général

Modèle indépendant de tout système qui recense les sources, stimuli, environnements, réponses et mesures typiques pour un attribut de qualité. Chapitre 2

Schéma

La structure déclarée d’une base de données : ses tables, ses colonnes, ses types de données, ses clés et ses règles. Chapitre 0

Schéma en étoile

Modèle dimensionnel composé d’une table de faits centrale contenant des mesures, entourée de tables de dimensions qui les décrivent, comme la date, le client et le produit. Chapitre 7

Scrum

Framework agile dans lequel une petite équipe travaille par cycles fixes appelés sprints, d’un mois ou moins, avec des événements, des responsabilités et des artefacts définis. Chapitre 0

SDK (kit de développement logiciel)

Bibliothèque, généralement fournie par le propriétaire d’une API, qui enveloppe les appels HTTP de l’API dans des fonctions ordinaires pour un langage de programmation donné. Chapitre 0

Secure Software Development Framework (SSDF)

NIST SP 800-218 : ensemble de pratiques de développement sécurisé regroupées sous les intitulés « préparer l’organisation », « protéger le logiciel », « produire un logiciel bien sécurisé » et « répondre aux vulnérabilités ». Chapitre 8

Sécurisé par défaut

Livrer un produit dont la configuration d’origine est la configuration sûre, de sorte que les utilisateurs doivent choisir délibérément d’affaiblir la protection plutôt que de penser à l’activer. Chapitre 8

Sécurité périmétrique

Le modèle traditionnel qui protège un réseau interne de confiance par des pare-feu et des VPN et considère comme amical tout ce qui se trouve déjà à l’intérieur ; on parle parfois de sécurité « château fort ». Chapitre 8

Sécurité psychologique

Conviction partagée au sein d’une équipe qu’il est sans danger de prendre des risques interpersonnels, comme reconnaître ses erreurs ou contredire un collègue plus haut placé ; étudiée par Amy Edmondson depuis 1999. Chapitre 11

Séparation commande-requête (CQS)

Principe de Bertrand Meyer selon lequel une méthode doit soit modifier l’état (une commande), soit renvoyer une réponse (une requête), mais pas les deux. Chapitre 7

Séquence principale (main sequence)

La droite A + I = 1 sur un graphique du degré d’abstraction en fonction de l’instabilité, où se situent les composants bien équilibrés. La distance à cette droite est D = |A + I - 1|. Chapitre 3

Sérialisabilité

La garantie d’isolation la plus forte : des transactions concurrentes produisent le même résultat que si elles s’étaient exécutées une par une dans un certain ordre. Chapitre 7

Serverless

Modèle de cloud dans lequel le fournisseur exécute vos fonctions ou vos flux de travail à la demande et facture à l’usage, de sorte que vous ne gérez pas vous-même de serveurs. Chapitre 1

Serverless et FaaS (fonction en tant que service)

Modèle de cloud dans lequel vous envoyez des fonctions individuelles qui ne s’exécutent que lorsqu’un événement les déclenche ; le fournisseur gère tous les serveurs et vous payez à l’exécution. Chapitre 0

Serveur

Ordinateur, ou programme qui s’exécute sur un ordinateur, qui attend les requêtes d’autres ordinateurs (les clients) et y répond. Chapitre 0

Service (Kubernetes)

Objet Kubernetes qui donne à un ensemble changeant de pods un nom et une adresse virtuelle stables, et qui répartit le trafic entre eux. Chapitre 10

Service de domaine

Dans une architecture à base de services, service déployé séparément qui couvre tout un domaine d’activité, comme les commandes ou les paiements, de l’API à l’accès aux données. Chapitre 6

Service de gestion de clés (KMS)

Service managé qui crée, stocke, renouvelle et contrôle l’usage des clés cryptographiques, en effectuant lui-même les opérations avec elles afin que les applications ne voient jamais les clés maîtres. Chapitre 8

Service externe (backing service)

Tout service qu’une application utilise par le réseau, comme une base de données, une file, un cache ou une API d’e-mail, traité comme une ressource attachée que la configuration permet de remplacer. Chapitre 10

Service hôte ouvert (open host service)

Patron de carte de contextes dans lequel un contexte amont offre un protocole ou une API unique, bien défini et documenté, à tous ses consommateurs. Chapitre 5

Service managé

Service cloud, comme une base de données, une file de messages ou un service de stockage, que le fournisseur installe, exploite, corrige et met à l’échelle, afin que les clients l’utilisent sans avoir à le faire tourner eux-mêmes. Chapitre 0

Service mesh (maillage de services)

Couche d’infrastructure faite de proxys réseau, configurés de manière centralisée, qui assure le chiffrement entre services, les nouvelles tentatives, les délais d’expiration, le contrôle du trafic et la télémétrie. Chapitre 6

Service sans état

Instance de service qui ne conserve aucune donnée entre deux requêtes dans sa propre mémoire ni sur son disque, de sorte que n’importe quelle instance peut traiter n’importe quelle requête et que l’on peut ajouter ou retirer des instances librement. Chapitre 9

Session persistante (sticky session, affinité de session)

Réglage d’un équilibreur de charge qui envoie toutes les requêtes d’un même client vers la même instance, généralement pour que les données de session conservées dans la mémoire de cette instance puissent être retrouvées. Chapitre 9

Shift left

Avancer les activités de sécurité (ou de test) dans le cycle de développement, dans les exigences, la conception et le codage, là où les problèmes coûtent moins cher à corriger qu’en production. Chapitre 8

Showback

Communiquer à chaque équipe ou produit les coûts qui lui sont attribués, sans les imputer réellement à son budget. Chapitre 10

Shuffle sharding

Affecter chaque client à une petite combinaison de ressources choisie au hasard, de sorte que deux clients partagent rarement toutes leurs ressources et qu’un client problématique n’en affecte que peu d’autres. Chapitre 10

SIEM

Security information and event management (gestion des informations et des événements de sécurité) : système qui collecte les journaux de sécurité de nombreuses sources, les corrèle et déclenche des alertes lorsqu’ils correspondent à des règles de détection. Chapitre 8

Sigstore

Projet open source pour signer et vérifier des artefacts logiciels au moyen de certificats de courte durée liés à une identité et d’un journal de transparence public, ce qui évite les clés de signature de longue durée. Chapitre 8

SLSA

Supply-chain Levels for Software Artifacts : cadre de niveaux d’assurance croissants qu’un artefact a été construit à partir du code source attendu par un build digne de confiance et résistant aux altérations. Chapitre 8

Snapshot (instantané)

Copie stockée de l’état d’un agrégat à une version d’événement connue, utilisée pour éviter de rejouer un long flux depuis le début ; c’est un cache, pas une source de vérité. Chapitre 7

Software Carbon Intensity (SCI)

Spécification de la Green Software Foundation, publiée sous la référence ISO/IEC 21031:2024, qui exprime les émissions de carbone d’un logiciel sous forme de taux : ((énergie x intensité carbone du réseau électrique) + émissions incorporées) par unité fonctionnelle. Chapitre 2

Software Carbon Intensity (SCI)

La spécification de la Green Software Foundation, publiée sous la référence ISO/IEC 21031:2024, qui évalue un logiciel par la formule ((E × I) + M) par R : l’énergie multipliée par l’intensité carbone du réseau électrique, plus les émissions incorporées, par unité fonctionnelle. Chapitre 11

SOLID

Moyen mnémotechnique pour cinq principes de conception orientée objet réunis par Robert C. Martin : responsabilité unique, ouvert-fermé, substitution de Liskov, ségrégation des interfaces et inversion des dépendances. Chapitre 3

Sonde (liveness, readiness, startup)

Vérification périodique d’un conteneur par Kubernetes : la sonde liveness décide s’il faut le redémarrer, la sonde readiness s’il faut lui envoyer du trafic, la sonde startup s’il a fini de démarrer. Chapitre 10

Sonde de disponibilité (readiness probe)

Contrôle de santé qui vérifie si une instance peut servir du trafic à cet instant ; un échec retire l’instance de l’équilibreur de charge sans la redémarrer. Chapitre 9

Sonde de vivacité (liveness probe)

Contrôle de santé qui vérifie si un processus est bloqué sans possibilité de rétablissement ; un échec amène l’orchestrateur à redémarrer l’instance. Chapitre 9

Sortie de données (egress)

Données qui quittent le réseau d’un fournisseur cloud, ou qui passent d’une de ses zones ou régions à une autre, généralement facturées au gigaoctet. Chapitre 10

Sortie structurée

Sortie d’un modèle contrainte à un format déclaré, généralement un JSON Schema, afin que l’application puisse l’analyser et la valider de manière fiable. Chapitre 12

Sous-caractéristique

Qualité plus spécifique au sein d’une caractéristique d’un modèle de qualité ; par exemple, la tolérance aux pannes et la capacité de récupération sont des sous-caractéristiques de la fiabilité dans l’ISO/IEC 25010. Chapitre 2

Sous-domaine

Domaine distinct de l’activité d’une entreprise, comme les cartes, les commandes, les paiements ou l’affectation des livreurs. Les sous-domaines relèvent du problème, qu’il existe ou non un logiciel. Chapitre 5

Sous-domaine de soutien (supporting subdomain)

Sous-domaine propre à l’entreprise et nécessaire à son activité, mais qui n’est pas le terrain sur lequel elle se distingue de la concurrence ; il mérite une conception solide mais plus simple. Chapitre 5

Sous-domaine générique

Sous-domaine dont les problèmes sont communs à de nombreuses entreprises et pour lequel de bonnes solutions existent, comme les paiements ou l’identité ; généralement acheté, ou construit de façon minimale. Chapitre 5

Sous-traitant (processor)

Organisme qui traite des données à caractère personnel pour le compte d’un responsable du traitement, selon ses instructions et dans le cadre d’un contrat, par exemple un fournisseur cloud d’envoi de SMS ou d’e-mails. Chapitre 8

Sous-typage comportemental

Règle qui sous-tend la substitution de Liskov : un sous-type ne peut pas exiger davantage des appelants (préconditions plus fortes), promettre moins (postconditions plus faibles) ni enfreindre les invariants du supertype. Chapitre 3

Span

Une opération chronométrée au sein d’une trace, comme un appel HTTP ou une requête de base de données, avec un nom, une heure de début, une durée, des attributs et un lien vers son span parent. Chapitre 9

Spike (investigation limitée dans le temps)

Investigation ou prototype court, limité dans le temps, réalisé pour répondre à une question technique ou réduire un risque, et normalement jeté ensuite. Chapitre 1

Split brain (cerveau divisé)

Défaillance dans laquelle deux nœuds se croient tous deux leader et acceptent tous deux des écritures, si bien que leurs données divergent. Chapitre 7

SQL (Structured Query Language)

Le langage standard pour définir, interroger et modifier les données des bases de données relationnelles. Vous décrivez le résultat voulu et la base de données détermine comment l’obtenir. Chapitre 0

SQL distribué (NewSQL)

Bases de données relationnelles comme Spanner et CockroachDB qui conservent SQL et les transactions ACID tout en partitionnant et en répliquant les données sur de nombreux nœuds ou régions. Chapitre 7

Squelette ambulant (walking skeleton)

Implémentation minuscule du système qui réalise une petite fonction de bout en bout en traversant tous les principaux composants architecturaux, généralement construite en premier. Chapitre 1

Stabilité statique

Propriété selon laquelle un système continue de fonctionner pendant une défaillance sans avoir à effectuer de changements, comme lancer de nouveaux serveurs ou mettre à jour la configuration, au moment de la défaillance. Chapitre 10

Staff engineer

Rôle de contributeur individuel senior, au-dessus de l’ingénieur senior, qui exerce un leadership technique à travers plusieurs équipes sans encadrer de personnes ; le principal engineer est généralement le niveau suivant. Chapitre 1

Staff-plus engineer

Contributeur individuel senior (staff, principal ou distinguished engineer) qui exerce un leadership technique à travers plusieurs équipes sans encadrer de personnes ; terme popularisé par Will Larson. Chapitre 11

Stimulus

L’événement sur lequel porte un scénario d’attribut de qualité, comme une rafale de requêtes, la panne d’un serveur, une demande de changement ou une attaque. Chapitre 2

Strangler fig (figuier étrangleur)

Approche de modernisation incrémentale, nommée par Martin Fowler, dans laquelle de nouveaux composants reprennent peu à peu le comportement d’un système hérité derrière une couche d’interception, jusqu’à ce que l’ancien système puisse être arrêté. Chapitre 11

Stratégie de sortie

Plan documenté, et idéalement répété, pour quitter un fournisseur ou un produit, couvrant l’export des données, les services de remplacement, les contrats, les délais et les coûts. Chapitre 10

STRIDE

Moyen mnémotechnique pour six types de menaces (usurpation d’identité ou spoofing, falsification ou tampering, répudiation, divulgation d’informations, déni de service et élévation de privilèges), créé chez Microsoft par Loren Kohnfelder et Praerit Garg en 1999. Chapitre 8

Structure

Ensemble d’éléments et des relations entre eux, vu sous un angle donné : par exemple les modules de code et leurs dépendances, ou les services en fonctionnement et la manière dont ils communiquent. Chapitre 1

Structure de données

Manière d’organiser des données en mémoire, comme une liste, un dictionnaire, un ensemble, une file, une pile, un arbre ou un graphe, choisie pour rendre rapides les opérations dont vous avez besoin. Chapitre 0

Structurizr

Les outils de Simon Brown pour le modèle C4, dans lesquels un modèle textuel génère de nombreux diagrammes cohérents. Chapitre 4

Style architectural

Famille nommée d’architectures définie par les types d’éléments et de connecteurs qu’elle utilise et par les contraintes sur la manière de les combiner, comme l’architecture en couches ou les tubes et filtres. Chapitre 5

Suivre une requête

Explication d’un système en suivant un seul événement concret, comme une commande, étape par étape à travers chaque partie qu’il touche. Chapitre 4

Supervision (monitoring)

Collecter et surveiller des mesures et des contrôles définis à l’avance afin que les types de défaillance connus soient détectés et signalés. Chapitre 9

Surapprentissage (overfitting)

Situation dans laquelle un modèle apprend les particularités de ses données d’entraînement au lieu du schéma général, de sorte qu’il obtient de bons résultats sur les exemples déjà vus et de mauvais sur les nouveaux. Chapitre 12

Surcoût des microservices (microservice premium)

Le terme de Martin Fowler (2015) pour le coût et le risque supplémentaires qu’ajoutent les microservices, qui ne sont rentables qu’une fois qu’un système et une organisation sont suffisamment complexes. Chapitre 5

Sûreté (safety)

Absence de risque inacceptable de dommage pour les personnes, les biens ou l’environnement causé par le système, que quelqu’un agisse ou non avec malveillance. Chapitre 2

Surface d’attaque

Ensemble des points par lesquels un attaquant peut tenter d’introduire des données dans un système, d’en extraire ou d’interagir autrement avec lui : endpoints, ports, fichiers, files, outils d’administration, ainsi que les personnes et le code auxquels il fait confiance. Chapitre 8

Système central (core system)

Dans une architecture micronoyau, partie minimale de l’application dont chaque installation a besoin : le flux de travail principal, les services partagés et les points où se branchent les plug-ins. Chapitre 5

Système de gestion de base de données (SGBD, DBMS)

Logiciel qui stocke une base de données et en contrôle l’accès : il répond aux requêtes, fait respecter les règles, gère de nombreux utilisateurs à la fois et se rétablit après une panne. PostgreSQL et MySQL en sont des exemples. Chapitre 0

Système de référence (system of record)

La source qui fait autorité pour une donnée, dont la valeur l’emporte lorsque les copies divergent, comme le grand livre central d’une banque pour les soldes des comptes. Chapitre 7

Système distribué

Ensemble de programmes s’exécutant sur des ordinateurs différents, qui coopèrent en s’envoyant des messages par un réseau afin que les utilisateurs voient un seul service. Chapitre 6

Système d’exploitation

Le logiciel qui gère le matériel d’un ordinateur et le partage entre les programmes : temps CPU, mémoire, fichiers, réseau et sécurité. Exemples : Linux, Windows, macOS, Android et iOS. Chapitre 0

Système d’IA à haut risque

Selon le règlement européen sur l’IA, système d’IA qui est un composant de sécurité d’un produit réglementé (annexe I) ou qui est utilisé dans un domaine sensible énuméré à l’annexe III, comme l’emploi ou le crédit. Chapitre 12

Système hérité (legacy)

Système existant qui apporte encore de la valeur mais qui est devenu difficile, risqué ou coûteux à modifier, souvent en raison de son âge, de l’absence de tests, de compétences rares ou d’une technologie qui n’est plus prise en charge. Chapitre 11

Système logiciel (C4)

Dans le modèle C4, le niveau d’abstraction le plus élevé : quelque chose qui apporte de la valeur à ses utilisateurs, généralement détenu par une seule équipe ou organisation. Chapitre 4

T

Table de dimensions

Table d’attributs descriptifs, comme le nom, le type de cuisine et la ville d’un restaurant, utilisée pour filtrer et regrouper les faits. Chapitre 7

Table de faits

Table centrale d’un schéma en étoile, qui contient une ligne par événement métier à une granularité définie, avec des mesures numériques et des clés vers les dimensions. Chapitre 7

Tactique

Décision de conception qui influe sur la manière dont un système répond à un stimulus de qualité, comme la mise en cache pour réduire la latence ou la redondance pour survivre à une panne. Les tactiques sont les blocs de construction des patrons. Chapitre 2

TARA

La Tiny Architectural Review Approach, méthode légère d’Eoin Woods pour examiner un système existant en combinant le jugement d’experts et l’analyse automatisée de son code et de ses données d’exécution. Chapitre 11

Taux de consommation (burn rate)

Vitesse à laquelle un budget d’erreur est dépensé par rapport au rythme qui l’épuiserait exactement à la fin de la fenêtre ; un taux de consommation de 1 le dépense entièrement en exactement une fenêtre. Chapitre 9

Taux de succès du cache (cache hit ratio)

Fraction des consultations auxquelles le cache peut répondre à partir de son propre contenu ; les autres sont des échecs (misses) qui vont vers la source plus lente. Chapitre 7

Taux d’actualisation

Taux annuel utilisé pour convertir de l’argent futur en valeur actuelle, qui reflète le coût du capital et le risque ; généralement fixé par le service financier. Chapitre 11

Taux d’utilisation

La fraction du temps pendant laquelle une ressource est occupée, généralement notée ρ (rho). Un serveur qui traite 40 requêtes par seconde nécessitant chacune 20 ms de travail est utilisé à 80 %. Chapitre 2

TCP

Transmission Control Protocol : fournit un flux de données fiable et ordonné entre deux programmes, en renvoyant les paquets perdus. La plus grande partie du trafic web l’a traditionnellement utilisé. Chapitre 0

Team Topologies

Approche d’organisation des équipes logicielles pour un flux rapide, présentée par Matthew Skelton et Manuel Pais dans le livre du même nom (2019 ; deuxième édition en 2025) : quatre types d’équipes, trois modes d’interaction, et la charge cognitive de l’équipe comme contrainte principale. Chapitre 11

Télémétrie

Les données qu’un système en fonctionnement émet sur son propre comportement : journaux, métriques, traces, profils et événements. Chapitre 9

Température

Paramètre d’échantillonnage qui accentue (en dessous de 1) ou aplatit (au-dessus de 1) les probabilités du token suivant du modèle, rendant la sortie plus reproductible ou plus variée. Chapitre 12

Tempête de nouvelles tentatives (retry storm)

Afflux de charge créé lorsque de nombreux clients, souvent à plusieurs niveaux, refont en même temps des requêtes qui échouent, ce qui maintient en surcharge un service déjà surchargé. Chapitre 9

Temps de l’événement (event time)

Moment où un événement s’est réellement produit, par opposition au temps de traitement, moment où un système l’observe. Chapitre 7

Temps de réponse

Le temps total entre l’envoi d’une requête par un client et la réception de la réponse : le temps de service, plus tout temps d’attente dans des files, plus les délais réseau. Chapitre 2

Temps de service

Le temps qu’une ressource passe réellement à travailler sur une requête, sans compter le temps pendant lequel la requête attend cette ressource. Chapitre 2

Temps moyen de réparation (MTTR)

Le temps moyen entre une défaillance et le rétablissement du service. Certaines organisations comprennent le R comme recover ou restore (rétablir) ; précisez toujours quels points de départ et d’arrivée sont mesurés. Chapitre 2

Temps moyen entre défaillances (MTBF)

Le temps moyen qui sépare une défaillance d’un composant ou d’un système réparable de la suivante. Chapitre 2

Temps moyen jusqu’à la défaillance (MTTF)

Le temps moyen pendant lequel un composant fonctionne correctement avant de tomber en défaillance. Chapitre 2

Test de bout en bout

Test automatisé qui pilote l’ensemble du système comme le ferait un utilisateur, par exemple en parcourant une app à coups de touchers, afin de vérifier un parcours complet. Chapitre 0

Test de caractérisation

Test qui enregistre ce que fait réellement le code existant, plutôt que ce qu’il devrait faire, afin que les modifications puissent être vérifiées par rapport au comportement actuel. Le terme vient de Michael Feathers. Chapitre 11

Test de charge

Test de performances qui applique la charge attendue (ou le pic prévu) pendant une période donnée afin de vérifier que les objectifs de latence et d’erreurs sont atteints. Chapitre 9

Test de pic (spike test)

Test de performances qui augmente brusquement la charge, par exemple d’un facteur dix en quelques secondes, pour vérifier l’autoscaling, les files et les mécanismes de protection. Chapitre 9

Test de point de rupture

Test de performances qui augmente la charge régulièrement jusqu’à ce que le système cède, afin de trouver sa capacité maximale et son premier goulot d’étranglement. Chapitre 9

Test de stress

Test de performances qui pousse la charge au-delà du pic attendu pour voir comment le système défaille et s’il se rétablit. Chapitre 9

Test d’architecture

Test automatisé qui fait échouer le build lorsque le code enfreint une règle structurelle, comme une dépendance interdite entre couches ou modules ; parmi les outils figurent ArchUnit et import-linter. Chapitre 5

Test d’endurance (soak test)

Long test de performances sous charge normale, exécuté pendant des heures ou des jours, pour révéler des problèmes lents comme les fuites de mémoire ou les files qui grossissent ; on parle aussi de test d’endurance. Chapitre 9

Test d’intégration

Test automatisé qui vérifie que plusieurs parties fonctionnent correctement ensemble, comme du code avec une vraie base de données ou l’API d’un autre service. Chapitre 0

Test unitaire

Test automatisé qui vérifie isolément un petit morceau de code, comme une fonction, et qui s’exécute en quelques millisecondes. Chapitre 0

Testabilité

La facilité avec laquelle on peut montrer, par des tests, qu’un système ou un composant se comporte comme prévu, ce qui suppose de pouvoir contrôler ses entrées et son état et observer ses sorties. Chapitre 2

Tests de contrat

Test de chaque côté d’une intégration de manière isolée, par rapport à une description partagée de leurs interactions, au lieu de déployer les deux ensemble pour des tests de bout en bout. Chapitre 6

Thème de risque

Groupe de risques liés qui partagent une cause commune, rattaché aux facteurs métier qu’il menace. Les thèmes de risque sont généralement le résultat d’une évaluation le plus utile pour les managers. Chapitre 11

Théorème CAP

Résultat, conjecturé par Eric Brewer en 2000 et démontré par Gilbert et Lynch en 2002, selon lequel, pendant une partition réseau, un système répliqué ne peut pas être à la fois linéarisable et disponible pour chaque requête. Chapitre 6

Thread (fil d’exécution)

Une séquence d’instructions en cours d’exécution à l’intérieur d’un processus. Les threads d’un même processus partagent sa mémoire ; ils peuvent donc travailler en même temps, mais doivent se coordonner. Chapitre 0

TLS et HTTPS

Transport Layer Security chiffre les données échangées entre deux programmes et, au moyen de certificats, prouve l’identité du serveur. HTTPS est du HTTP transporté sur TLS. Chapitre 0

TLS mutuel (mTLS)

TLS dans lequel les deux parties présentent et vérifient des certificats, de sorte qu’un service sait quel service l’appelle, en plus de l’appelant qui connaît le serveur. Chapitre 8

TOGAF

The Open Group Architecture Framework, cadre et méthode très utilisés pour l’architecture d’entreprise, publiés par The Open Group ; sa version actuelle est le TOGAF Standard, 10th Edition (2022). Chapitre 1

Token

L’unité de texte qu’un modèle de langage lit et écrit : un mot ou un morceau de mot issu d’un vocabulaire fixe. Les limites, les prix et la vitesse se comptent tous en tokens. Chapitre 12

Token bucket (seau à jetons)

Algorithme de limitation de débit dans lequel des jetons sont ajoutés à un seau à un rythme fixe jusqu’à une capacité maximale, et où chaque requête consomme un jeton ; il autorise des rafales jusqu’à cette capacité et un débit moyen régulier. Chapitre 9

Tokenisation

Remplacer une valeur sensible, comme un numéro de carte, par un jeton dépourvu de signification, tandis que la valeur réelle est conservée dans un coffre-fort distinct et étroitement protégé, souvent exploité par un prestataire de paiement. Chapitre 8

Tolérance aux pannes

Capacité d’un système à continuer de rendre son service même si l’une de ses parties est défaillante, généralement grâce à la redondance. Chapitre 2

Topologie à courtier (broker)

Topologie pilotée par les événements sans coordinateur central : les processeurs réagissent aux événements et publient d’autres événements, de sorte que le flux de travail émerge de leurs réactions. Chapitre 6

Topologie à médiateur

Topologie pilotée par les événements dans laquelle un médiateur reçoit un événement initial et dirige le flux de travail en envoyant des commandes à des processeurs dans un ordre défini. Chapitre 6

Traçage distribué (distributed tracing)

Enregistrement du chemin et de la durée d’une requête au fil de son passage par de nombreux services, afin de pouvoir trouver l’étape lente ou défaillante. Chapitre 9

Trafic fantôme (shadow traffic, dark launch)

Copier des requêtes réelles vers une nouvelle version dont les réponses sont comparées ou écartées, mais jamais renvoyées aux utilisateurs, afin de la tester sous charge réelle sans impact pour les utilisateurs. Chapitre 10

Traitement de flux (stream processing)

Traiter en continu un flux illimité d’enregistrements, chacun peu de temps après son arrivée. Chapitre 5

Traitement par lots

Traitement d’un ensemble borné de données en une seule exécution, comme toutes les commandes de la veille, qui se termine ensuite. Chapitre 5

Transaction

Groupe d’opérations de base de données traité comme une seule unité : soit toutes prennent effet (commit), soit aucune (rollback). Chapitre 0

Transaction compensatoire

Nouvelle transaction qui annule sémantiquement l’effet d’une transaction antérieure déjà validée, comme l’annulation d’une autorisation de carte. Contrairement à un retour arrière, l’original a pu déjà être vu. Chapitre 6

Transfert d’état porté par les événements (event-carried state transfer)

Événements qui transportent suffisamment de données pour que les destinataires conservent leur propre copie, de sorte qu’ils n’ont pas besoin d’appeler l’émetteur. Chapitre 6

Transformer

L’architecture de réseau de neurones présentée par Vaswani et ses collègues en 2017, fondée sur l’auto-attention, qui sous-tend les grands modèles de langage actuels et la plupart des modèles d’embedding. Chapitre 12

Triade CIA

Les trois objectifs classiques de la sécurité de l’information : confidentialité (seules les parties autorisées peuvent lire), intégrité (aucune modification non autorisée) et disponibilité (utilisable quand on en a besoin). Chapitre 2

Trio fatal (lethal trifecta)

Le nom donné par Simon Willison (2025) à la combinaison dangereuse de l’accès à des données privées, de l’exposition à des contenus non fiables et de la capacité à communiquer vers l’extérieur. Chapitre 12

Tube (pipe)

Canal à sens unique qui transporte les données d’un filtre au suivant, généralement avec un tampon entre les deux. Chapitre 5

Tubes et filtres (pipes and filters)

Style dans lequel les données circulent à travers une chaîne d’étapes de traitement indépendantes (les filtres), reliées par des canaux à sens unique (les tubes). Chapitre 5

Type de données

Nature de la valeur que représente une donnée, comme un entier, un nombre décimal, du texte ou vrai/faux, qui détermine les opérations qui ont un sens sur elle. Chapitre 0

Type de modèle (model kind)

Dans l’ISO/IEC/IEEE 42010, les conventions propres à un type de modèle, comme un diagramme de séquence UML ou un diagramme de conteneurs C4. Chapitre 4

U

UDP

User Datagram Protocol : envoie des paquets individuels sans garantie de livraison ni d’ordre. Plus rapide et plus simple que TCP ; utilisé pour les appels vidéo, les jeux et le DNS. Chapitre 0

Unité de déploiement

Ce qui est construit, publié et démarré d’un seul tenant : par exemple un exécutable, une image de conteneur ou une archive web. Chapitre 5

Upcasting

Convertir un événement stocké dans une ancienne version de schéma vers la version actuelle au moment de sa lecture, afin que le code de l’application n’ait à gérer qu’une seule forme. Chapitre 7

UTF-8

La manière dominante d’encoder du texte en octets. Il peut représenter tous les caractères Unicode, avec un octet pour les lettres de base de l’anglais et jusqu’à quatre octets pour les autres. Chapitre 0

Utilisateur virtuel

Utilisateur simulé dans un outil de test de charge, qui exécute un script de requêtes, généralement en boucle. Chapitre 9

V

Valeur actuelle nette (VAN, NPV)

La somme des flux de trésorerie futurs d’un investissement, chacun actualisé à sa valeur d’aujourd’hui, moins le coût initial ; une VAN positive signifie que l’investissement rapporte plus que le taux d’actualisation. Chapitre 11

Valeur magique

Nombre ou chaîne littéral dont la signification n’est pas indiquée dans le code, par exemple un statut 3 qui signifie « expédié ». Elle crée une connascence de signification entre tout ce qui l’utilise. Chapitre 3

Validation en deux phases (two-phase commit, 2PC)

Protocole qui fait valider ou annuler ensemble plusieurs participants : un coordinateur demande d’abord à tous de se préparer et de voter, puis leur communique à tous le résultat. Les participants qui ont voté oui restent bloqués si le coordinateur tombe en panne. Chapitre 6

Verrouillage pessimiste

Empêcher les conflits en verrouillant les lignes au moment de leur lecture (par exemple avec SELECT ... FOR UPDATE), de sorte que les autres transactions attendent la libération du verrou. Chapitre 7

Versionnage d’API

Publication des modifications d’une API sous un nouvel identifiant de version, comme /v2/, en maintenant l’ancienne version en service pendant un certain temps pour que les clients puissent migrer à leur rythme. Chapitre 0

Versionnage sémantique

Convention de numérotation des versions, MAJOR.MINOR.PATCH, dans laquelle le numéro majeur change pour les changements cassants, le mineur pour les ajouts rétrocompatibles et le correctif (patch) pour les corrections. Chapitre 5

Violation de données à caractère personnel

Au sens de l’article 4, point 12, du RGPD, une violation de la sécurité entraînant, de manière accidentelle ou illicite, la destruction, la perte, l’altération, la divulgation non autorisée de données à caractère personnel, ou l’accès non autorisé à de telles données. Chapitre 8

Vue

Représentation d’une ou de plusieurs structures d’un système, destinée à des préoccupations précises de parties prenantes précises, comme un diagramme de déploiement pour les équipes d’exploitation. Chapitre 1

Vue composants et connecteurs

Vue de ce qui existe à l’exécution, comme les services, les clients, les bases de données et les files, et des connecteurs (appels, messages, données partagées) qui les relient. Chapitre 4

Vue des modules

Vue des unités d’implémentation (paquets, bibliothèques, couches) et de leurs dépendances, telles qu’elles existent au moment du développement. Chapitre 4

Vue d’allocation

Vue qui met en correspondance le logiciel avec des éléments qui lui sont extérieurs : l’infrastructure (déploiement), les fichiers et les builds (implémentation) ou les équipes (affectation du travail). Chapitre 4

W

Warm standby (secours tiède)

Stratégie de reprise après sinistre qui maintient en fonctionnement, dans une seconde région, une copie réduite mais pleinement opérationnelle du système, prête à recevoir le trafic et à monter en charge. Chapitre 10

WCAG

Les Web Content Accessibility Guidelines (règles pour l’accessibilité des contenus web) du W3C. La version 2.2 (2023) fixe des critères de succès testables aux niveaux A, AA et AAA ; le niveau AA est la référence juridique habituelle. Chapitre 2

Webhook

Requête HTTP qu’un fournisseur envoie à une URL enregistrée par son client lorsqu’un événement se produit, comme un paiement réussi. Elle inverse le sens habituel d’un appel d’API. Chapitre 0

Write skew (biais d’écriture)

Anomalie dans laquelle deux transactions lisent des données qui se recoupent, jugent chacune qu’une modification est sans danger et mettent à jour des lignes différentes, enfreignant ensemble une règle que chacune avait vérifiée. Chapitre 7

X

X en tant que service (X-as-a-Service)

Mode d’interaction dans lequel une équipe consomme ce qu’une autre équipe fournit, au travers d’une interface claire et documentée et avec peu de collaboration au quotidien. Chapitre 11

XA

L’interface standard X/Open (1991) entre un gestionnaire de transactions et des gestionnaires de ressources comme les bases de données et les courtiers de messages, utilisée pour exécuter une validation en deux phases entre eux. Chapitre 6

Y

Y-statement (déclaration en Y)

Enregistrement de décision en une phrase, proposé par Olaf Zimmermann : dans le contexte de…, face à…, nous avons choisi… et écarté…, pour obtenir…, en acceptant que… Chapitre 4

YAGNI

You aren’t gonna need it (vous n’en aurez pas besoin) : pratique de l’Extreme Programming consistant à ne pas construire de capacités pour des besoins seulement supposés, car elles coûtent de l’effort maintenant et de la complexité plus tard. Chapitre 3

Z

Zero trust (confiance zéro)

Modèle de sécurité qui n’accorde aucune confiance implicite fondée sur l’emplacement réseau : chaque requête est authentifiée, autorisée et chiffrée, par ressource et par session (NIST SP 800-207). Chapitre 8

Zone de disponibilité

L’un des groupes de centres de données physiquement séparés au sein d’une région cloud, chacun disposant de sa propre alimentation électrique, de son refroidissement et de son réseau, suffisamment proches pour des connexions rapides. Chapitre 0