Un accès distant ouvre un chemin vers des ressources internes ou administrées. Sa maîtrise relie identité, état du terminal, périmètre autorisé, durée, surveillance et fermeture après usage.
L’accessibilité vise à rendre les services utilisables par des personnes ayant des capacités et modes d’interaction variés. Elle se vérifie dans les parcours réels et complète l’ergonomie générale.
Le choix entre achat, développement et assemblage dépend du caractère différenciant du besoin, des contraintes, des compétences et du coût complet. Aucune option n’est systématiquement supérieure ; chacune crée des responsabilités et dépendances différentes.
TOGAF fournit un cadre et une méthode d’architecture d’entreprise à adapter au contexte. Son adoption utile consiste à sélectionner les pratiques, rôles et livrables nécessaires, plutôt qu’à appliquer mécaniquement tous les éléments d’un référentiel.
La conduite du changement aide les personnes à utiliser durablement un nouveau fonctionnement. Elle relie compréhension, formation, soutien, adaptation des processus et mesure des effets ; communiquer une date de lancement ne suffit pas.
Un agent d’IA peut enchaîner des étapes et appeler des outils pour atteindre un objectif. Le risque augmente lorsque ses sorties déclenchent des actions réelles ; les permissions doivent donc être contrôlées hors du modèle.
L’analyse d’impact relative à la protection des données examine les risques qu’un traitement peut faire peser sur les droits et libertés des personnes. Elle porte sur le traitement et ses effets, pas seulement sur la sécurité de l’application.
L’alignement consiste à relier les choix du SI aux objectifs de l’organisation et à vérifier cette relation dans le temps. Il ne signifie pas accepter toutes les demandes ni figer les outils jusqu’à la prochaine stratégie.
L’analyse des risques cyber relie des événements redoutés aux menaces, vulnérabilités et conséquences pour l’organisation. Des méthodes comme EBIOS Risk Manager structurent cette réflexion ; elles doivent être appliquées avec leur périmètre et leurs hypothèses.
Une API expose des fonctions ou données selon un contrat. Ce contrat doit préciser sens, formats, droits, erreurs, limites et évolution, afin que producteurs et consommateurs puissent changer sans rupture imprévisible.
Une application comptable transforme et conserve des opérations selon des règles de gestion et de contrôle. La fiabilité du système dépend autant des flux amont, pièces et rapprochements que du logiciel de tenue lui-même.
L’authentification multifacteur combine plusieurs catégories de preuve d’identité. Sa robustesse dépend des mécanismes utilisés, du contexte et du processus de récupération, qui peut devenir le point faible.
Un workflow organise l’enchaînement de tâches et décisions. La RPA automatise souvent des interactions avec une interface utilisateur ; elle reste sensible aux changements d’écran, de données et d’habilitations.
Une base de connaissances organise des informations réutilisables pour résoudre, décider ou transmettre. Sa valeur dépend de la qualité, de la recherche, du contexte et du maintien des contenus.
La Business Impact Analysis étudie les conséquences d’une interruption dans le temps. Elle identifie les activités prioritaires, ressources nécessaires et seuils de tolérance ; elle ne se confond pas avec une analyse des menaces.
Le budget DSI traduit les engagements de service et de transformation en moyens financiers. Une prévision actualisée complète le budget initial pour rendre visibles les écarts, nouveaux besoins et risques de dépassement.
Le cadrage d’audit fixe les objectifs, les critères, le périmètre, les limites et les modalités de travail. Il permet de savoir ce que les conclusions couvriront réellement et ce qu’elles ne pourront pas démontrer.
La gestion de capacité rapproche les besoins de service des ressources disponibles. La performance perçue dépend de toute la chaîne, et non du seul taux d’utilisation d’un serveur.
Une capacité métier décrit ce que l’organisation doit être capable de faire, indépendamment d’un processus précis ou d’un logiciel. Une application est un moyen possible de soutenir cette capacité, pas sa définition.
La cartographie des données montre où les informations sont créées, stockées, transformées, transmises et utilisées. Elle relie les objets métier aux systèmes, aux responsabilités et aux règles de protection.
Une cartographie des flux décrit les échanges entre systèmes : contenu, origine, destination, fréquence, protocole, responsabilité et traitement des erreurs. Elle doit aussi rendre visibles les échanges manuels et les dépendances de séquencement.
Une cartographie d’infrastructure relie équipements, plateformes, réseaux, services techniques et applications. Elle rend visibles les dépendances physiques et logiques qui influencent disponibilité, sécurité et capacité.
La cartographie des processus décrit les activités, décisions, acteurs et échanges nécessaires à un résultat. Elle devient utile au SI lorsqu’elle relie ces éléments aux informations et services réellement utilisés.
Un catalogue de données décrit les jeux de données, leur sens, leurs responsables et leurs conditions d’utilisation. Il aide à les découvrir, mais sa présence ne garantit ni leur qualité ni le droit de les réutiliser.
Un catalogue de services décrit ce que la DSI fournit, pour qui, dans quelles conditions et par quel circuit. Il doit parler en usages et résultats, pas seulement en noms de technologies.
La cellule de crise traite une situation qui dépasse le fonctionnement habituel et exige des arbitrages rapides sous incertitude. Elle distingue orientation stratégique, coordination opérationnelle et expertise.
Le chiffrement protège certaines propriétés des données selon le mécanisme utilisé. Les certificats et clés demandent une gestion de cycle de vie : inventaire, émission, stockage, renouvellement, révocation et récupération.
Une chaîne de valeur décrit comment les activités contribuent à un résultat utile. Son rapprochement avec le SI montre quelles informations, applications et compétences soutiennent cette création de valeur, ainsi que les dépendances qui peuvent l’interrompre.
La charge représente le travail nécessaire ; la capacité correspond au temps et aux compétences réellement disponibles. La disponibilité doit tenir compte de l’exploitation, des absences, des interruptions et de l’apprentissage.
Une charte de projet formalise le problème à résoudre, le résultat attendu, le périmètre, le sponsor et les premières contraintes. Elle autorise une démarche de préparation sans prétendre connaître dès le départ tous les détails de réalisation.
IaaS, PaaS et SaaS correspondent à des niveaux différents de service et de responsabilité. Plus le service est intégré, moins l’organisation administre certaines couches, mais elle garde la maîtrise des usages, données et engagements qui lui reviennent.
Un ERP rassemble plusieurs fonctions de gestion autour de données et de règles partagées. Son intégration peut réduire les ressaisies, mais ne dispense pas de définir les responsabilités, les contrôles et les échanges avec les autres applications.
La réversibilité organise la capacité à poursuivre le service après changement ou arrêt d’un fournisseur. Le contrat doit être complété par un plan opérationnel précisant données, formats, assistance, délais et critères d’acceptation.
Une CMDB décrit des éléments de configuration et leurs relations pour soutenir la gestion opérationnelle des services. Un référentiel d’architecture couvre aussi les capacités, processus, décisions et trajectoires. Leurs périmètres se recoupent sans être identiques.
Un comité d’investissement décide d’engager, de poursuivre ou d’arrêter des dépenses sur la base d’options, de risques et de bénéfices attendus. Son utilité se mesure aux arbitrages rendus, pas au nombre de présentations examinées.
La communication d’incident informe les acteurs concernés sur les faits, impacts et actions utiles. Elle doit être cohérente, régulière et explicite sur les incertitudes, sans attendre une cause parfaitement connue.
La gestion des compétences critiques identifie les connaissances nécessaires à l’exploitation et à l’évolution du SI. Elle cherche à éviter qu’une personne unique soit indispensable sans transmission ni solution de remplacement.
Une identité technique permet à un programme ou un service d’accéder à une ressource. Elle doit avoir un propriétaire, un usage défini, des droits limités et un mécanisme de gestion adapté à l’automatisation.
Le risque de concentration apparaît lorsque plusieurs activités reposent sur un même fournisseur ou sur une dépendance commune. Il peut exister même avec plusieurs contrats ou marques commerciales distincts.
Le confinement cherche à limiter l’extension ou les conséquences d’un incident de sécurité. Il doit être adapté au contexte et coordonné avec les besoins de preuve, de sécurité des personnes et de continuité.
Le cycle de conservation distingue usage courant, archivage justifié et suppression. Les durées doivent être reliées aux finalités, obligations et besoins de preuve ; conserver indéfiniment par précaution n’est pas une politique.
Un constat décrit un fait observé au regard d’un critère explicite. Une non-conformité suppose un écart à une exigence applicable ; une recommandation peut aussi viser une amélioration sans constituer une obligation.
Un conteneur regroupe une application et des dépendances dans un environnement d’exécution isolé selon des mécanismes définis. L’orchestration automatise placement et cycle de vie, sans supprimer les besoins de sécurité, stockage et exploitation.
La continuité d’un fournisseur doit être appréciée à travers le service qu’il permet à l’organisation de maintenir. Un plan déclaré ou une certification ne démontre pas que les dépendances propres au client sont couvertes.
Un contrat numérique décrit droits, obligations et mécanismes de relation. Un SLA précise certains niveaux de service, mais il faut vérifier leur mesure, leurs exclusions et les conséquences d’un écart.
Un incident majeur exige une coordination transversale car plusieurs équipes ou services sont affectés. Le coordinateur organise faits, priorités, actions et communication sans remplacer les spécialistes techniques.
Une copie immuable limite sa modification pendant des conditions définies ; une copie hors ligne n’est pas accessible en permanence par le réseau. Ces propriétés répondent à des risques différents et doivent être vérifiées dans leur mise en œuvre.
Le coût d’un système d’IA comprend les appels au modèle, mais aussi les données, l’intégration, les contrôles, les erreurs et l’exploitation. La rentabilité doit porter sur une valeur réalisée, pas sur le seul nombre de tâches automatisées.
Le coût total de possession, ou TCO, rassemble les coûts nécessaires pour acquérir, utiliser, maintenir et retirer une solution sur un horizon défini. Il inclut les coûts internes et de transition, pas seulement le prix du contrat.
Le coût d’indisponibilité estime les conséquences économiques d’une interruption selon sa durée et son contexte. Il combine pertes directes, rattrapage, pénalités possibles et effets différés, en explicitant les incertitudes.
Un coût unitaire rapporte le coût d’un service à une unité d’usage définie : utilisateur actif, dossier traité, transaction ou volume stocké. Il n’est interprétable que si le service et la qualité restent comparables.
Un coût irrécupérable est déjà engagé et ne peut plus être évité par la décision présente. Il doit être distingué des coûts futurs pour comparer lucidement poursuite, réduction de périmètre, remplacement ou arrêt.
La criticité traduit l’importance d’une activité ou d’un composant au regard des conséquences de sa défaillance. Elle dépend du contexte, de la durée d’arrêt, des périodes sensibles et des solutions de contournement disponibles.
Un CRM organise les informations et interactions utiles à la relation client. Il n’est pas nécessairement la source de référence pour la facturation ou l’identité juridique des clients ; ces rôles doivent être explicitement attribués.
Le cycle de vie des identités organise création, évolution, suspension et suppression des comptes. Les droits doivent suivre la situation et la mission réelles de la personne, pas seulement son arrivée initiale.
Le décisionnel transforme des données en informations de pilotage. La qualité d’un tableau de bord dépend des définitions, transformations et périodes autant que de sa présentation graphique.
Les droits de décision indiquent qui peut autoriser un changement, engager une dépense, accepter un risque ou accorder une exception. Les délégations précisent les limites de cette autorité et les situations nécessitant une escalade.
DYNAMAP SI est une méthode progressive d’architecture d’entreprise. Il propose une démarche progressive reliant connaissance de l’existant, décisions de transformation, collaboration métier–IT et tableaux de bord, sans imposer de commencer par un dispositif lourd.
Une dépendance entre projets existe lorsqu’un résultat, une ressource ou une décision conditionne un autre chantier. Elle doit être explicitée avec un responsable et une condition d’acceptation.
Une dépendance vitale est un élément dont la perte empêche une activité essentielle de fonctionner ou de reprendre. Elle peut être technique, humaine, contractuelle, financière ou informationnelle et rester invisible dans une cartographie centrée sur les applications.
Distinguer fonctionnement et transformation aide à comprendre les moyens consacrés au service courant et à son évolution. Les catégories run et build sont des conventions de gestion, pas une frontière comptable universelle.
Le déploiement met une solution à disposition ; la bascule transfère l’activité vers elle. Un retour arrière prévoit comment revenir à une situation maîtrisée lorsque les critères de réussite ne sont pas atteints.
La dette technique désigne des choix qui facilitent parfois le présent mais augmentent les coûts ou risques futurs de modification et d’exploitation. La dette d’architecture concerne notamment les couplages, responsabilités et structures devenus inadaptés.
Une démarche DevSecOps intègre réalisation, exploitation et sécurité dans la chaîne de livraison. Elle rend les contrôles plus précoces et reproductibles, sans supprimer les responsabilités d’acceptation ou les contrôles humains nécessaires.
Le DHCP permet d’attribuer automatiquement des paramètres réseau aux clients, notamment des adresses avec une durée de bail. Les plages, réservations, relais et options doivent rester cohérents avec l’architecture.
Un diagnostic de maturité évalue la capacité de l’organisation à maîtriser ses pratiques de manière répétable et démontrable. Il distingue l’intention, la formalisation, le déploiement et l’efficacité, au lieu de compter seulement les outils installés.
Le DNS associe des noms à des informations utiles aux services, notamment des adresses. Résolveurs, serveurs faisant autorité, zones et caches jouent des rôles différents ; leurs dépendances doivent être connues.
La documentation technique décrit ce qu’une équipe doit comprendre pour exploiter, modifier et reprendre un service. Elle est utile lorsqu’elle reste liée aux versions et couvre les procédures réellement exécutables.
DORA est un règlement européen portant sur la résilience opérationnelle numérique du secteur financier dans son champ d’application. Il articule gestion du risque informatique, incidents, tests et risques liés aux prestataires, avec des modalités à qualifier pour chaque entité.
Un dossier d’architecture explique comment une solution répond aux besoins et contraintes. La vue générale présente les choix et interactions ; la vue technique précise les composants et conditions d’exploitation. Les intitulés DAG et DAT varient selon les organisations.
Le durcissement réduit les fonctions, accès et configurations inutiles d’un système selon son usage. Une configuration de référence doit être testée, maintenue et adaptée aux contraintes du service.
L’échantillonnage consiste à contrôler une partie d’une population selon une méthode explicitée. Il doit permettre une conclusion proportionnée, en tenant compte des risques et des différences entre les éléments examinés.
Un entretien d’audit recueille la compréhension des pratiques, contraintes et responsabilités. Il devient plus fiable lorsqu’il est complété par l’observation et des preuves, plutôt que traité comme une déclaration suffisante.
Évaluer un modèle consiste à mesurer sa capacité à réussir un usage défini, dans des conditions représentatives. Une note générale sur un benchmark ne remplace pas une évaluation des erreurs et conséquences propres à l’organisation.
Un échange asynchrone permet à un producteur de transmettre un message sans attendre l’achèvement immédiat du traitement consommateur. Il découple certains délais mais impose de gérer doublons, ordre, rejets et visibilité de l’état.
Le traitement des demandes de droits organise réception, qualification, recherche, décision et réponse selon les règles applicables. Il doit permettre de retrouver les données sans communiquer celles d’une autre personne.
Un exercice vérifie les décisions, coordinations et capacités dans un scénario défini. Un test technique vérifie un mécanisme précis ; les deux sont complémentaires et doivent produire des enseignements suivis.
Les exigences fonctionnelles décrivent ce que le service doit faire. Les exigences non fonctionnelles précisent les qualités et contraintes attendues : performance, sécurité, disponibilité, accessibilité ou exploitabilité. Les deux doivent être vérifiables.
La démarche FinOps rapproche usages, coûts et responsabilités pour piloter les dépenses cloud. Elle associe visibilité, optimisation et arbitrage de valeur, sans réduire le sujet à supprimer des ressources techniques.
Une gestion électronique de documents organise classement, recherche, versions, accès et circulation des documents. Elle ne constitue pas à elle seule un système d’archivage probant ni une politique de conservation.
La gestion des changements d’exigences organise l’évolution du besoin en évaluant ses effets sur valeur, coût, délai, risque et architecture. Elle ne vise pas à interdire le changement mais à le rendre explicite.
La gestion des correctifs organise l’identification, la qualification, le déploiement et la vérification des mises à jour. La priorité dépend de l’exposition et de l’impact, pas uniquement de l’ancienneté du correctif.
Une vulnérabilité est une faiblesse susceptible de compromettre un objectif de sécurité. Sa gestion relie détection, validation, priorité, correction et vérification dans le contexte réel des actifs.
Un glossaire métier définit les termes utilisés dans les processus, décisions et données. Il distingue les sens voisins et précise les conventions nécessaires à une compréhension commune.
La haute disponibilité vise à maintenir un service malgré certaines défaillances. Plusieurs instances ne suffisent pas si elles partagent une dépendance commune, un défaut logiciel ou une administration unique.
L’Infrastructure as Code décrit les ressources et configurations dans des fichiers versionnés et exécutables par des outils. Elle rend les changements plus reproductibles, mais requiert des contrôles de droits, de revue et d’état.
L’interopérabilité permet à des systèmes d’échanger des informations utilisables avec un sens compatible. Un contrat de données précise schéma, sémantique, qualité, disponibilité et règles de changement entre producteur et consommateur.
Un inventaire de sécurité relie les actifs à leurs propriétaires, usages, versions et modes d’exposition. Il aide à déterminer ce qui doit être protégé et surveillé, y compris les services externes et équipements oubliés.
Un inventaire applicatif recense les applications réellement utilisées et leurs caractéristiques utiles : service rendu, responsables, utilisateurs, données, interfaces, hébergement, contrats et cycle de vie. Il constitue une base de connaissance, pas un simple catalogue de logiciels achetés.
Un journal de crise conserve chronologie, faits, hypothèses, décisions et actions. Il facilite coordination et retour d’expérience sans transformer chaque échange en compte rendu exhaustif.
La journalisation conserve des événements utiles ; un SIEM les rapproche pour soutenir la détection et l’investigation. L’efficacité dépend des sources, de la qualité des règles et de la capacité à traiter les alertes.
Une landing zone rassemble les règles et composants de base nécessaires à un usage maîtrisé du cloud : comptes, identités, réseaux, journaux, sécurité et suivi des dépenses. Elle doit rester proportionnée au périmètre.
La gestion des licences rapproche les droits acquis des usages réels. Les métriques peuvent dépendre des utilisateurs, machines, cœurs, environnements ou modalités d’accès ; elles doivent être comprises avant déploiement.
Le mandat de la DSI précise ce que l’organisation attend d’elle : assurer les services, maîtriser les risques, accompagner les métiers et préparer les transformations. Il définit aussi les décisions qu’elle peut prendre et celles qui relèvent de la direction générale.
Le Master Data Management organise la maîtrise des données de référence partagées, telles que clients, produits ou organisations. Il combine règles, responsabilités et mécanismes de rapprochement ; il ne se réduit pas à une base centrale.
MLOps organise le cycle de vie des modèles, données et déploiements. Pour l’IA générative, la configuration, les prompts, le corpus documentaire et les outils peuvent aussi modifier le comportement et doivent être tracés.
Moderniser un système ancien consiste à réduire ses contraintes ou risques tout en préservant le service et les données. Le remplacement complet n’est qu’une option parmi stabilisation, encapsulation, refonte partielle ou migration progressive.
Un mode dégradé maintient une partie de l’activité avec des moyens ou contrôles adaptés à une perturbation. Il doit prévoir la traçabilité et le rattrapage pour éviter qu’une continuité apparente crée des erreurs durables.
Le moindre privilège consiste à accorder les droits nécessaires à une mission, pour le périmètre et la durée utiles. Les revues vérifient que ces droits restent justifiés et que les décisions de retrait sont exécutées.
NIS 2 est une directive européenne de cybersécurité dont l’application concrète dépend notamment du champ d’activité, des critères de qualification et de la transposition nationale. Une démarche de préparation doit partir de cette qualification, pas d’une checklist universelle.
La synchronisation temporelle rapproche les horloges des systèmes d’une référence définie. NTP est un protocole courant pour cet usage ; la précision nécessaire dépend des services, preuves et contrôles concernés.
Un objet métier représente une notion manipulée par l’organisation, comme un client, un contrat ou une facture. Les données en sont des représentations informatiques. Plusieurs applications peuvent décrire le même objet avec des identifiants et règles différents.
Les outils collaboratifs permettent de partager contenus, échanges et tâches. Leur gouvernance organise les espaces, propriétaires, droits et cycles de vie, afin d’éviter que l’information utile se disperse dans des canaux sans responsable.
La gestion des accès privilégiés encadre les comptes capables d’administrer ou de modifier des éléments sensibles. Elle combine limitation des droits, attribution temporaire, traçabilité et contrôle des usages.
Les parties prenantes sont les personnes ou groupes qui utilisent, financent, administrent, contrôlent ou subissent les effets d’un changement du SI. Leur influence et leur connaissance du travail réel peuvent être très différentes.
Le plan de continuité d’activité organise le maintien des activités prioritaires à un niveau acceptable malgré une perturbation. Il couvre personnes, locaux, fournisseurs, informations et technologies, pas seulement l’informatique.
Un pipeline collecte, transforme et transmet des données entre systèmes. Sa fiabilité exige des contrôles de complétude, de cohérence, de reprise et d’observabilité, au-delà du simple statut technique de fin de traitement.
Un planning relie les travaux, dépendances, ressources et décisions dans le temps. Les jalons marquent des résultats ou autorisations vérifiables, pas seulement des dates de réunion.
Un plan d’action transforme un écart en travaux pilotables avec responsable, échéance, moyens et critère de réussite. La fermeture doit constater un résultat, pas seulement la réalisation d’une tâche ou l’achat d’un outil.
Une politique SI exprime les règles et orientations durables qui encadrent les usages, les responsabilités et les décisions. Elle doit être suffisamment claire pour guider l’action sans devenir un catalogue de procédures techniques.
Un portail client expose des services et documents à des utilisateurs externes. Son architecture doit vérifier l’autorisation sur chaque ressource et action, pas seulement lors de la connexion.
Un portefeuille regroupe les initiatives afin d’arbitrer leur valeur, leur risque et leur consommation de ressources. Il permet de voir les interactions entre projets, améliorations, obligations et travaux de maintien du SI.
Le plan de reprise d’activité informatique décrit comment rétablir les services après un sinistre selon un ordre compatible avec les besoins métier. Il comprend décisions, ressources, dépendances, procédures et validation.
La préservation des traces cherche à conserver des éléments fiables pour comprendre un incident et, le cas échéant, soutenir une démarche juridique. Elle demande intégrité, traçabilité des manipulations et contrôle d’accès.
Une preuve d’audit est une information pertinente et suffisamment fiable pour étayer un constat. Sa force dépend de son origine, de sa date, de son intégrité et de la façon dont elle a été obtenue.
Un principe d’architecture est une règle de décision durable, accompagnée d’une justification et de conséquences concrètes. Il guide les choix sans imposer nécessairement un produit ou une technologie précise.
Prioriser consiste à ordonner les initiatives selon leur valeur, leur risque, leur urgence et leur faisabilité, sous contrainte de capacité. Cela implique aussi de différer ou de refuser certains travaux.
Un processus organise des activités pour atteindre un résultat ; une procédure précise les règles et responsabilités ; un mode opératoire explique comment réaliser une tâche. Ces niveaux se complètent sans être interchangeables.
Le propriétaire d’une donnée est responsable de ses usages, règles et arbitrages dans un périmètre défini. Il ne s’agit pas nécessairement du propriétaire juridique ni de l’administrateur technique qui héberge la base.
La protection des données dès la conception intègre les exigences de confidentialité et de maîtrise dans les choix de service. La protection par défaut limite les données et accès aux besoins justifiés, sans attendre une configuration manuelle après déploiement.
Qualifier un incident consiste à établir les faits disponibles, le périmètre touché, l’impact et l’urgence. La priorité doit refléter les conséquences pour le service, pas seulement le nombre de tickets ou le rang de la personne qui signale.
Qualifier une demande consiste à comprendre le problème, le résultat recherché et les contraintes avant de choisir une solution. La demande initiale exprime souvent un moyen imaginé plutôt que le besoin véritable.
La qualité des données s’évalue par rapport à un usage. Exactitude, complétude, cohérence, fraîcheur et unicité sont des dimensions différentes ; une donnée peut être acceptable pour un usage et insuffisante pour un autre.
Un dispositif RAG recherche des documents puis les fournit comme contexte à un modèle génératif. Il peut améliorer l’ancrage documentaire, mais n’empêche ni une mauvaise sélection des sources ni une réponse inventée ou mal interprétée.
La réalisation des bénéfices consiste à vérifier que le changement produit les résultats attendus après la livraison. Elle nécessite un propriétaire métier, une situation de référence et des actions d’adoption ou d’organisation.
La recette d’un export vérifie que les éléments livrés sont complets, cohérents, lisibles et reliés à leur contexte. Le nombre de fichiers ou la taille totale ne suffisent pas à démontrer la qualité de la restitution.
La recette vérifie qu’une solution répond aux exigences et scénarios convenus dans des conditions représentatives. L’acceptation est une décision qui tient compte des résultats, réserves et risques résiduels.
Un référentiel d’architecture stocke les objets et relations décrivant le SI, avec leurs responsables, sources et versions. Les cartographies sont des vues de ce référentiel, ce qui évite de maintenir séparément des schémas contradictoires.
Un registre de décisions conserve le contexte, les options, les raisons du choix, le décideur et les conditions de révision. Il permet de comprendre une architecture et d’éviter de rediscuter les mêmes sujets sans information nouvelle.
Un registre d’IA identifie les systèmes, usages, modèles, fournisseurs et responsables. Il rend visibles les dépendances et les décisions, y compris les usages intégrés à des logiciels achetés.
Le registre des traitements décrit les usages de données personnelles, leurs finalités, acteurs et conditions de maîtrise. Il doit refléter les activités réelles ; il ne se limite pas à une liste de logiciels.
Un registre des risques relie des scénarios redoutés à leurs causes, conséquences, mesures de maîtrise et responsables. Il sert à décider d’un traitement et à suivre le risque résiduel, pas à produire une liste de menaces génériques.
Le règlement européen sur l’IA organise des exigences selon les systèmes, usages et rôles des acteurs. La qualification ne se réduit pas au nom du modèle ; finalité, contexte, intégration et responsabilités sont déterminants.
Le retour sur investissement compare les bénéfices attribuables à une initiative aux coûts engagés sur un périmètre et une période. Il doit distinguer économies réellement encaissables, capacité libérée et gains qualitatifs.
La répartition des coûts attribue les dépenses partagées aux services, processus ou entités selon des règles explicites. La refacturation ajoute un mécanisme de facturation interne ; elle ne prouve pas que le coût est évitable.
Le réseau local relie les équipements d’un site ; le réseau étendu relie des sites et services distants. Leur disponibilité dépend des chemins, équipements, opérateurs et règles d’exploitation.
La responsabilité partagée distingue ce que le fournisseur prend en charge et ce qui reste à l’organisation. La répartition varie selon le service, le contrat et la configuration utilisée.
Le retour à la normale rétablit un fonctionnement jugé sûr et acceptable, puis retire progressivement les mesures temporaires. Il nécessite une validation métier et technique, pas seulement la disparition d’une alerte.
Le retour d’expérience analyse ce qui a contribué à l’incident, à son impact et à la réponse. Il distingue causes, facteurs organisationnels et opportunités d’amélioration sans se limiter à chercher une personne fautive.
La réversibilité d’un service d’IA permet de changer de modèle, fournisseur ou organisation sans perdre les données, règles et capacités essentielles. Elle concerne aussi les évaluations, prompts, index et interfaces.
Une revue d’architecture examine une solution à un moment où les choix peuvent encore évoluer. Elle confronte les exigences aux décisions, risques, dépendances et conditions d’exploitation, puis formule des conclusions actionnables.
Le risque fournisseur couvre les conséquences possibles de sa défaillance, de ses pratiques ou de ses propres dépendances. L’évaluation initiale doit être prolongée par un suivi proportionné à la criticité du service.
Le RSSI anime la maîtrise des risques de sécurité ; la politique de sécurité fixe les objectifs, responsabilités et règles retenus par l’organisation. La sécurité reste une responsabilité collective, avec des arbitrages portés au bon niveau.
Le RTO exprime un objectif de durée de rétablissement ; le RPO exprime la perte de données acceptable en termes de recul temporel. Ils décrivent deux contraintes distinctes, à relier à la tolérance d’interruption de l’activité.
Une sauvegarde est une copie conservée pour permettre la récupération après perte ou altération. Sa valeur se démontre par une restauration exploitable, cohérente et réalisable dans le délai attendu.
Un schéma directeur organise la trajectoire du SI entre l’existant et une cible soutenant la stratégie. Il combine priorités, dépendances, ressources, risques et décisions ; ce n’est pas seulement une liste de projets sur plusieurs années.
Un secret donne accès à une ressource ou permet une opération sensible. Sa gestion comprend création, stockage, distribution, rotation, révocation et récupération ; le retirer du code ne suffit pas à maîtriser son cycle de vie.
La segmentation sépare des zones ou usages et contrôle les communications autorisées entre eux. Elle limite certaines propagations, à condition que les règles soient cohérentes avec les flux réellement nécessaires.
Sélectionner un fournisseur consiste à évaluer sa capacité à fournir un service utile, durable et maîtrisable. Le prix et la démonstration commerciale doivent être complétés par des preuves, engagements et scénarios de sortie.
Un cas d’usage d’IA décrit un problème métier, une décision ou une tâche que l’on envisage d’améliorer. La présence d’un modèle performant ne suffit pas : il faut comparer l’IA aux options plus simples et définir les conséquences d’une erreur.
La séparation des fonctions répartit des actions incompatibles pour limiter erreurs et abus. Dans une petite équipe, certains cumuls peuvent être nécessaires, mais ils doivent être compensés par des contrôles adaptés et traçables.
Le séquestre de code organise la conservation et la remise de certains éléments selon des conditions convenues. Il peut soutenir la continuité, mais n’apporte pas automatiquement les compétences, dépendances et droits nécessaires à l’exploitation.
Un service métier correspond à un résultat utile pour un client ou une activité. Un service informatique fournit une capacité qui contribue à ce résultat. La disponibilité d’un outil ne prouve donc pas que le service métier est rendu.
Le shadow IT regroupe les usages numériques qui échappent partiellement à la connaissance ou à la gouvernance de la DSI. Il peut révéler un risque, mais aussi un besoin métier mal couvert ou un circuit de demande trop lent.
Le SIRH soutient les processus de ressources humaines et leurs données. Les interfaces de paie doivent préserver les identités, périodes, règles de calcul et contrôles de confidentialité ; un échange réussi techniquement ne prouve pas une paie correcte.
Un indicateur de niveau de service mesure un comportement ; un objectif de niveau de service fixe une cible ; un accord de service formalise des engagements dans un contexte donné. Les définitions doivent rester explicites et partagées.
La sobriété numérique cherche à satisfaire les besoins utiles avec moins de ressources et d’effets indésirables. Elle examine usages, durée de vie, données, équipements et services plutôt qu’une optimisation technique isolée.
La sortie d’un service cloud organise la récupération des données, la reconstruction des fonctions et le changement des dépendances. Exporter des fichiers ne démontre pas que le service peut être exploité ailleurs.
Un sous-traitant traite des données personnelles pour le compte d’un responsable de traitement dans un cadre défini. La qualification dépend des rôles réels, et le contrat doit être cohérent avec les opérations effectuées.
La souveraineté numérique se traduit, pour une organisation, par une capacité de décision et d’action sur ses données, services et dépendances. La localisation est une dimension, mais ne suffit pas à établir cette maîtrise.
Le SSO permet de réutiliser une authentification pour accéder à plusieurs services selon des mécanismes de confiance. La fédération relie des systèmes d’identité distincts ; elle doit préciser attributs, rôles et durée des sessions.
Les standards d’architecture définissent des solutions ou règles de référence pour les besoins récurrents. Les dérogations permettent un écart justifié, maîtrisé et révisable lorsque le standard ne répond pas au contexte.
Le stockage fournit des capacités de conservation et d’accès aux données. Redondance, performance, sauvegarde et archivage répondent à des besoins différents et ne doivent pas être confondus.
Une stratégie cloud définit quels services placer dans quels environnements et pourquoi. Une architecture hybride combine plusieurs lieux ou modes d’hébergement avec leurs règles de liaison, de sécurité et d’exploitation.
Le suivi d’audit vérifie que les corrections prévues ont été réalisées et qu’elles répondent au constat initial. Il peut conduire à fermer, maintenir ou reformuler un constat selon les nouvelles preuves.
La supervision suit des états et seuils connus ; l’observabilité aide à comprendre le comportement du service à partir de mesures, journaux et traces. Les deux doivent être reliées aux impacts vécus par les utilisateurs.
La supervision humaine organise qui contrôle, comprend, corrige et peut arrêter l’usage d’un système d’IA. Elle ne se résume pas à ajouter un bouton de validation à la fin du processus.
Le support organise l’accueil, la qualification, la résolution et le suivi des demandes et incidents. Un ticket utile contient les faits et le contexte nécessaires, sans imposer à l’utilisateur un diagnostic technique préalable.
Un système d’information associe des personnes, des règles, des processus, des données et des moyens techniques pour produire et utiliser l’information. L’informatique n’en constitue que la partie automatisée : une validation manuelle ou une procédure papier appartient aussi au SI.
Un tableau de bord de DSI relie service, risques, coûts, capacité et trajectoire aux décisions de direction. Il doit sélectionner des mesures utiles et explicables plutôt qu’accumuler des chiffres techniques.
Une stratégie de tests combine contrôles unitaires, intégration, parcours complets et vérifications non fonctionnelles selon les risques. L’automatisation améliore la répétabilité, mais ne remplace pas l’analyse du besoin ni les essais exploratoires.
Un test d’intrusion évalue, dans un cadre explicitement autorisé, si des faiblesses peuvent compromettre le périmètre convenu. Il complète d’autres contrôles mais ne démontre pas une sécurité absolue.
Le data lineage décrit l’origine, les transformations et les destinations d’une donnée. Une vue technique des traitements doit être complétée par le sens métier des règles et par les versions concernées.
Une transaction regroupe des opérations selon des garanties de cohérence. Dans un système distribué, plusieurs composants peuvent ne pas partager la même transaction ; il faut alors définir les états intermédiaires, reprises et compensations acceptables.
La localisation décrit où des données sont stockées ou traitées ; un transfert de données personnelles exige une qualification juridique selon les acteurs, accès et pays concernés. Le lieu de stockage ne résume pas tous les accès possibles.
L’urbanisation organise le SI en ensembles cohérents afin de limiter les couplages, les redondances et les changements incontrôlés. Elle relie les domaines métier aux applications, données et échanges, sans se réduire à dessiner des zones colorées.
La gestion des versions identifie précisément ce qui est construit et déployé. Une release regroupe des changements rendus disponibles avec leurs conditions d’exploitation, de compatibilité et de retour arrière.
La virtualisation permet d’exécuter plusieurs environnements sur des ressources partagées. Elle facilite certains déplacements et reprises, mais concentre aussi les dépendances sur l’hyperviseur, le stockage et l’administration.
Une architecture cible décrit l’organisation souhaitée des capacités, processus, données, applications et moyens techniques. Elle doit expliquer les compromis et permettre une trajectoire réaliste depuis l’existant.
Un réseau Wi-Fi professionnel combine couverture radio, capacité, authentification et séparation des usages. Un signal fort ne garantit pas une bonne expérience si les canaux, équipements ou services associés sont saturés.