Le jargon de la gestion des incidents

Accusé de réception de l'incident (« ack »)

Une fois qu'une alerte d'incident est générée, un utilisateur peut en accuser réception (« ack ») dans la plupart des outils d'alerte utilisés pour la gestion des astreintes. Cela signifie que l'utilisateur se charge du ticket et travaille à sa résolution.

Alerte exploitable

Une alerte exploitable est une alerte qui décrit clairement un problème et son impact, et qui est acheminée aux bonnes personnes au bon moment afin que l'équipe puisse agir immédiatement.

Surveillance active

Les systèmes équipés d'un dispositif de surveillance actif sont régulièrement vérifiés ou sont contrôlés automatiquement à l'aide d'un logiciel pour détecter tout changement de performance susceptible d'entraîner des incidents.

Revue après action (AAR)

Une revue après action est un processus d'examen structuré qui a lieu après un événement. Le processus décrit généralement ce qui s'est passé en détail, tente d'identifier les raisons pour lesquelles l'événement s'est produit et désigne les domaines à améliorer afin d'éviter ces événements ou les événements similaires à l'avenir. Les revues après action sont également communément appelées post-mortems ou revues post-incident.

Temps de service convenu (AST)

Le temps de service convenu désigne la durée, habituellement mesurée en heures par année, durant laquelle un service devrait être disponible. Cette information est généralement indiquée dans un accord de niveau de service (SLA) conclu entre le fournisseur et le client. Les services à haute disponibilité promettent généralement une disponibilité de 99,99 %, ce qui représente moins d'une heure de temps d'arrêt par an.

Alerte

Alarme ou avertissement généré lorsque les outils de surveillance identifient des changements, des actions à haut risque ou des défaillances dans l'environnement informatique.

Bruit d'alerte

Lorsque trop d'alertes sont créées en peu de temps, les intervenants peinent à identifier avec précision les services concernés et à prioriser leur travail. On parle de bruit d'alerte, lequel peut contribuer à la fatigue d'alerte.

Fatigue d'alerte

La fatigue d'alerte survient lorsque les intervenants en cas d'incident sont submergés par le volume ou la fréquence des alertes. Elle entraîne souvent des réponses lentes (voire l'absence de réponse), car les intervenants ont tendance à percevoir les alertes constantes comme « normales ».

Services en continu

Service censé fonctionner en continu.

Actifs/Gestion des actifs

Composants de tout système ou réseau ayant une valeur métier. La gestion des actifs définit le travail d'une personne ou d'une équipe qui examine ces composants pour comprendre l'impact d'une mise à jour ou de la suppression d'un système.

Contrôle

Examen officiel de la disponibilité et de l'utilisation d'un système ou d'un processus, et vérification du respect des politiques, des lignes directrices et des bonnes pratiques.

Disponibilité

Lorsqu'un produit ou un système est disponible et fonctionne comme prévu. Également connu sous le nom de disponibilité du système.

Retour arrière

Pratique consistant à rétablir un service à un état ou une base de référence fiable antérieur(e). Il s'agit généralement d'une correction rapide appliquée lorsqu'une mise à jour ou une version altère un élément essentiel dans un système.

Sauvegarde

Copie de données stockée ou système redondant disponible pour une utilisation en cas de compromission ou de perte de l'original.

Base de référence

Point de référence pour le comportement attendu. Les bases de référence aident les équipes à mesurer les changements et les améliorations.

Référence

Point de référence qui fonctionne comme une base de référence pour mesurer l'avancement ou comparer les résultats. Par exemple, si la norme dans notre secteur est de 99,99 % de temps de disponibilité, cette référence peut être utilisée pour comparer nos performances par rapport à la concurrence et aux attentes des clients.

Bug

Problème involontaire dans les logiciels, le code, ou encore les programmes qui peut provoquer un comportement anormal ou une défaillance.

Analyse d'impact métier (BIA)

Évaluation systématique de l'impact potentiel des interruptions de service et des temps d'arrêt dus à un incident majeur. L'analyse d'impact métier a pour objectif de comprendre l'effet de chaque service sur l'entreprise et de définir les exigences en matière de restauration en cas d'incident.

Capacité

Quantité maximale d'informations pouvant être transférées entre les réseaux ou fournies via un service. Le dépassement de la capacité est un indicateur courant pour les incidents.

Changement

Toute modification apportée à un service, à une configuration, à un réseau ou à un processus informatique. Les changements sont souvent suivis dans une pratique connue sous le nom de gestion des changements.

Historique des modifications

Enregistrement complet des changements apportés à un service, à une configuration, à un réseau ou à un processus informatique depuis le début de son cycle de vie jusqu'à l'état actuel.

Gestion des changements

Pratique informatique axée sur la réduction des interruptions pendant les changements/mises à jour des systèmes et services critiques. Pour certaines équipes, cette pratique englobe tous les aspects du changement, de l'aspect technique aux personnes et aux processus. Pour d'autres équipes, s'appuyant sur les lignes directrices d'ITIL 4, la gestion des changements se concentre sur la gestion des aspects humains ou culturels du changement, tandis qu'une autre pratique appelée contrôle des changements se concentre sur l'évaluation des risques, les calendriers et l'autorisation des changements.

ChatOps

Pratique consistant à utiliser des outils de chat et de collaboration pour la gestion des incidents. Comme l'explique Sean Regan d'Atlassian :

« ChatOps est un modèle de collaboration qui rassemble les personnes, les outils, les processus et l'automatisation dans un workflow transparent. Ce workflow centralise les tâches à réaliser, en cours et terminées dans un espace persistant composé de personnes, de robots et d'outils connexes. »

État fermé

Un incident est fermé lorsque toutes les mesures nécessaires ont été prises et qu'un ticket est clos.

« Cold standby » (reprise progressive)

Mode de récupération utilisé lorsqu'un système agit en tant que système de secours. Si le système principal tombe en panne, le « cold-standby » remplace le système principal pendant sa correction. Il s'agit d'une stratégie particulièrement utile si la panne du système principal nécessite une reprise progressive (qui peut prendre des semaines) dans le cas où du matériel informatique doit être remplacé et configuré.

Démarrage à froid

Un démarrage à froid se produit lorsqu'une app non exécutée prend plus de temps à démarrer qu'une app « chaude » ou déjà en cours d'exécution.

Responsable des communications

Membre de l'équipe chargé de la communication lors d'un incident.

Conformité

Respect des règlements. Souvent, des systèmes de surveillance seront programmés pour surveiller les problèmes de conformité et déclencher des alertes si la conformité d'un système est compromise.

Analyse d'impact de la défaillance des composants (CFIA)

Processus de détermination de l'impact sur un service lorsqu'un composant ou une configuration cesse de fonctionner comme prévu.

Simultanéité/Accès concurrents

Nombre total d'actions identiques qui se produisent simultanément au sein d'un système. Par exemple : combien d'utilisateurs accèdent à la même opération ou effectuent la même transaction ?

Contrôle

Procédures et politiques qui gèrent les risques, garantissent le fonctionnement prévu d'un produit ou d'un service et assurent la conformité.

Service de base

Service qui assure une fonction centrale pour les utilisateurs/clients.

Contre-mesure

Action réactive spécifique prise pour protéger un système ou restaurer les opérations.

Service orienté client

Service que les clients utilisent et avec lequel ils interagissent.

Framework Cynefin

Framework de prise de décision qui a été adapté aux processus de gestion des incidents pour aider les responsables à organiser la réponse la plus efficace. Ce framework divise les situations en cinq catégories en fonction de la complexité d'un incident, et chaque catégorie a son propre ensemble (différent) d'étapes suivantes.

Tableau de bord

Visualisation sur un seul écran des systèmes, des alertes et des incidents, conçue pour organiser la présentation des données issues de divers outils grâce à des informations contextuelles fournies dans un format propre et précis.

Dépendance

Relation entre deux services, processus ou configurations qui dépendent l'un de l'autre pour fonctionner.

Obsolescence/Déclassement

Lorsqu'une entité ou un outil est mis hors service, n'est plus utilisé ou mis à jour.

Diagnostic

Processus d'analyse d'un incident et de sa cause profonde, et résultat.

Diagnostics

Symptômes ou signes qui conduisent à un diagnostic d'incident.

Temps d'arrêt/panne

Intervalle durant lequel un service ne fonctionne pas ou n'est pas disponible comme prévu.

Changement urgent

Mise à jour ou correctif déployé(e) rapidement, généralement dans le cadre de la résolution des incidents. Les changements urgents ignorent souvent les processus d'approbation des changements parce que les risques associés à l'attente des approbations sont plus élevés que ceux associés au déploiement de ces changements.

Service de soutien

Service nécessaire pour qu'un service de base fonctionne, mais qui n'est pas directement proposé aux clients.

Environnement de test*

Infrastructure dans laquelle est testée le fonctionnement attendu d'un service, d'une fonctionnalité, d'un processus, ou encore d'un élément de configuration. Cet environnement est contrôlé étroitement pour mettre en miroir la production.

Environnement de production

Infrastructure dans laquelle un service est fourni à un client. Les livrables dans cet environnement sont disponibles, et ce dernier est parfois également appelé environnement réel.

Erreur

Erreur qui provoque une défaillance d'un élément de configuration ou d'un service. Il peut s'agir d'une erreur de design, de traitement ou humaine.

Remontée

Processus de transfert d'une assignation de gestion d'incident à une équipe ou à une personne possédant des compétences ou une expérience plus pertinentes. Une remontée fonctionnelle désigne une situation où une alerte ou un incident est transféré(e) à une personne ou à une équipe ayant plus d'expertise. Une remontée hiérarchique désigne une situation où l'alerte ou l'incident est transféré(e) d'une personne subalterne à un responsable.

Événement

Système ou situation de service notable. Les événements sont généralement causés par une action de l'utilisateur ou par un incident.

Rapport d'exception

Rapport généré lorsque les indicateurs de performance clés (KPI) dépassent leurs seuils ou ne répondent pas aux attentes.

Tolérance de panne

La tolérance aux pannes décrit la capacité d'un service à continuer de fonctionner même en cas de défaillance d'un élément de configuration ou d'un composant individuel.

Analyse par arbre de pannes

Technique utilisée pour déterminer les événements qui ont mené à un incident et prédire quels événements pourraient engendrer des incidents à l'avenir. Elle est souvent utilisée pour déterminer la cause profonde d'un incident majeur.

Support de première ligne

Intervenant censé intervenir en premier sur un incident. Il s'agit généralement de la personne d'astreinte.

Corriger

Action ou méthode de réparation.

Actif fixe

Élément physique, valorisé et à long terme de l'entreprise, comme un bureau, un ordinateur ou une licence.

Planning « Follow-the-sun »

Méthode de support client ou de gestion des incidents qui fait tourner les responsabilités d'astreinte entre les fuseaux horaires pour offrir une couverture continue sans nécessiter d'équipes d'astreinte au milieu de la nuit.

Analyse forensique/Investigation numérique

Enquête scientifique fondée sur des données probantes dans un système informatique afin d'identifier la cause d'un incident.

Fonctionnel

Un service est décrit comme fonctionnel lorsqu'il est en état de fonctionner comme prévu.

Reprise progressive

Processus de reprise qui prend plus de temps que d'habitude (des semaines au lieu d'heures). Lorsque cela se produit, un système en « cold-standby » (système de sauvegarde) sera généralement activé pour remplacer le système affecté.

« Hot standby »

Option de reprise où les ressources redondantes s'exécutent simultanément pour prendre en charge un service informatique en cas de panne. Si le système actif tombe en panne, le « hot standby » est déjà en cours d'exécution et prêt à prendre sa place sans qu'aucune action soit requise de la part de l'équipe et, sans temps d'arrêt. Elle est également connue sous le nom de reprise immédiate.

Correctif logiciel

Mise à jour appliquée au logiciel pour résoudre un problème ou corriger un bug. Elle est souvent utilisée pour résoudre un ticket signalé par le client.

Impact

Mesure du coût (argent, temps, réputation) qu'entraîne une interruption de service, un incident ou un changement. Également connue sous le nom de coût des temps d'arrêt.

Alerte inexploitable

Alerte qui ne permet pas à un intervenant d'agir. Cela signifie souvent que l'alerte ne contient pas de renseignements contextuels, a été acheminée vers la mauvaise personne ou que son périmètre n'est pas clair. Les alertes inexploitables peuvent contribuer à la fatigue d'alerte.

Incident

Événement ayant provoqué une perturbation ou une réduction de la qualité d'un service nécessitant une réponse d'urgence. À la place, les équipes qui adoptent les pratiques ITIL ou ITSM utilisent parfois le terme « incident majeur ».

Réponse aux incidents

Réaction des équipes face à un incident. Généralement, la réponse aux incidents est un processus prédéfini avec des règles, des rôles et des bonnes pratiques définis avant qu'un incident ne se produise.

Gestion des incidents

Processus utilisé par les équipes DevOps et des opérations informatiques pour répondre à un événement imprévu ou une interruption de service et rétablir le fonctionnement du service.

Coordinateur gestion des incidents

Membre des équipes informatiques ou DevOps qui est responsable de gérer la réponse aux incidents. Il est le chef de l'équipe de gestion des incidents et a le contrôle ultime et le dernier mot sur toutes les décisions relatives aux incidents. Ce rôle est aussi souvent appelé gestionnaire d'incident.

Cycle de vie des incidents

Vie d'un incident, de son apparition à sa détection jusqu'à sa résolution.

Métriques d'E/S

Ensemble de métriques qui mesurent l'entrée et la sortie. Les métriques courantes de cette catégorie comprennent l'attente d'E/S (le temps qu'un CPU attend une demande d'E/S) et les E/S par seconde (nombre de demandes d'E/S par seconde).

Orchestration de la réponse aux incidents

Fonctionnalité Opsgenie qui permet aux équipes d'identifier rapidement et efficacement les problèmes, d'informer les bonnes personnes, de faciliter la communication entre les unités opérationnelles et de collaborer entre les équipes pour la gestion des incidents.

Enregistrement d'incident

Enregistrement des informations et des processus utilisés au cours d'un incident spécifique.

Intervenant en cas d'incident

Personnes et/ou équipes responsables de l'enquête et de la résolution d'un incident.

Parties prenantes/observateurs d'un incident

Personnes qui doivent être tenues au courant d'un incident parce que cela a une incidence sur leur travail ou leur capacité à le réaliser. Ces personnes peuvent ou non influencer la résolution des incidents, mais elles ne sont pas des intervenants actifs.

Reprise intermédiaire

Également connu sous le nom de « warm standby », ce type de reprise prend généralement entre 24 et 72 heures. La restauration des données et/ou la configuration matérielle et logicielle expliquent généralement le temps de récupération relativement long.

Information Technology Infrastructure Library (ITIL)

Ensemble documenté de bonnes pratiques largement acceptées pour les services informatiques.

Gestion des services informatiques (ITSM)

Tous les aspects des processus et procédures nécessaires à la fourniture d'un service informatique aux clients. Cela inclut tous les aspects du cycle de vie du service, de la conception à la livraison en passant par la gestion des incidents.

Méthode Kepner Tregoe (KT)

Analyse des causes profondes et méthode de prise de décision où les problèmes sont évalués séparément de la décision finale au sujet d'un ticket.

Indicateurs de performance clés (KPI)

Mesure des performances des systèmes ou des produits. Les KPI sont déterminés à l'avance, suivis régulièrement et génèrent souvent des alertes en cas de dépassement des seuils attendus. Par exemple, si votre temps moyen entre pannes (MTBF) devient de plus en plus court, une alerte peut être générée afin que votre équipe puisse identifier et étudier le problème.

Erreur connue

Ticket préexistant qui a déjà une solution de contournement.

Latence

Retard survenu lors du transfert des données.

Journaux

Enregistrements de tous les événements liés à un service ou à une app. Cela inclut les données transférées, les heures et les dates, les incidents, les changements, les erreurs, etc.

Maintenabilité

Mesure de la facilité avec laquelle des changements peuvent être appliqués à un service ou à une fonctionnalité.

Solution de contournement manuelle

Solution implémentée manuellement (par opposition à automatiquement).

Temps moyen entre pannes (MTBF)

Temps moyen entre les pannes réparables d'un produit technologique. Il est également connu sous le nom de temps moyen entre les incidents de service (MTBSI).

Temps moyen d'accusé de réception (MTTA)

Temps moyen qu'il faut entre le déclenchement d'une alerte et le début du travail sur le ticket.

Temps moyen de bon fonctionnement (MTTF)

Temps moyen entre les pannes non réparables d'un produit technologique.

Temps moyen jusqu'à la réparation (MTTR)

Temps moyen nécessaire à la réparation d'un système, généralement technique ou mécanique. Il inclut à la fois le temps de réparation et les temps de test.

Délai moyen de reprise (MTTR)

Temps moyen nécessaire à la remise en route suite à une panne d'un produit ou d'un système. Il inclut la durée totale de la panne, depuis le moment où le système ou le produit tombe en panne jusqu'au moment où il est à nouveau pleinement opérationnel.

Durée moyenne de résolution (MTTR)

Temps moyen nécessaire à la résolution complète d'une panne, y compris le temps passé à s'assurer que la panne ne se reproduira plus.

Temps moyen de réponse (MTTR)

Temps moyen nécessaire à la reprise d'activité suite à une panne d'un produit ou d'un système, à partir du moment où vous êtes averti pour la première fois de cette panne. Cela n'inclut aucun retard dans votre système d'alerte.

Modèle/Modélisation

Représentation d'un système, d'un service, d'une app, etc.

Monitoring

Processus répété de contrôle d'un service ou d'un processus pour s'assurer qu'il fonctionne comme prévu.

Changement normal

Changement non urgent pour lequel il n'existe pas de processus défini et pré-approuvé.

Planning d'astreinte

Planning qui garantit que la bonne personne est toujours disponible, de jour comme de nuit, pour intervenir rapidement en cas d'incidents et de pannes. Les plannings d'astreinte sont courants dans les secteurs médicaux et technologiques.

Salle de contrôle

Emplacement physique où intervient la surveillance des services informatiques.

Responsable des opérations

Personne responsable de la supervision des opérations quotidiennes. Dans certains cas, cette personne peut également être le gestionnaire d'incident (ou le coordinateur gestion des incidents), responsable de la résolution des incidents.

Résultat

Résultat d'un événement, d'un processus ou d'un changement informatique. Les équipes parlent souvent des résultats prévus et des résultats réels.

Analyse de la valeur de dérangement

Analyse utilisée pour identifier l'impact d'un incident sur l'entreprise. Elle tient généralement compte du coût des temps d'arrêt, de la durée d'un incident, de l'impact sur les utilisateurs et du nombre d'utilisateurs concernés.

Surveillance passive

Lorsque la fonctionnalité d'un service est automatiquement surveillée (plutôt qu'activement ou manuellement).

Temps de paix

Lorsque les services et les opérations fonctionnent comme prévu, sans interruption.

Dégradation des performances

Mesure de la diminution des performances d'un système en raison d'un événement ou d'un incident.

Interruptions planifiées

Période pendant laquelle un service informatique n'est intentionnellement pas disponible à des fins de maintenance ou de mise à jour.

Playbook

Ensemble de « scénarios » ou d'actions spécifiques qu'une équipe peut réaliser pour résoudre un problème ou un incident ou pour atteindre un objectif spécifique.

Post-mortem/Analyse post-incident/revue post-incident

Processus visant à comprendre un incident après sa résolution. Le but d'un post-mortem est d'améliorer les processus de réponse, de prévenir les incidents futurs et de comprendre la cause de l'incident le plus récent.

Priorité

Ordre dans lequel les incidents doivent être traités. Les éléments hautement prioritaires sont plus urgents que les éléments de priorité inférieure. La priorité est déterminée par l'urgence, la gravité et l'impact potentiel sur l'entreprise.

Enregistrement de problème

Document qui couvre tous les aspects d'un problème, de sa détection à sa résolution.

Panne de service prévue

Document décrivant l'impact de la maintenance ou des tests futurs sur les niveaux de service normaux.

Assurance qualité

Processus de test visant à s'assurer que les normes sont respectées pour tout ce qui concerne les technologies de l'information, des nouvelles fonctionnalités aux guides pratiques.

Système de gestion de la qualité

Framework ou systèmes en place pour fournir l'assurance qualité.

Surveillance réactive

Surveillance effectuée en réaction à un événement ou à un incident.

Récupération

Processus de restauration des fonctionnalités et de l'intégrité de base d'un service.

Objectif de point de reprise

Perte maximale de données autorisée pendant la reprise.

Durée maximale d’interruption admissible

Durée maximale tolérée pour une interruption de service.

Livraison

Changement déployé pour les utilisateurs.

Gestion des livraisons

Planification, conception, tests, planification, dépannage et déploiement de changements.

Résilience

Capacité d'un système à résister à une panne et à récupérer rapidement en cas d'incident.

Temps de réponse

Temps nécessaire entre la génération d'une alerte et la première action prise par l'équipe.

Évaluation des risques

Processus consistant à déterminer le risque associé à un actif en évaluant sa valeur, les menaces potentielles et l'incidence potentielle de ces menaces.

Gestion des risques

Processus de traitement des menaces qui passe par leur identification et leur contrôle.

Cause profonde

Généralement considérée comme la raison particulière d'une panne de service ou d'app. Cependant, les pannes impliquent souvent de nombreux facteurs interconnectés, de sorte que les équipes commencent à se demander si ce terme est utile dans la gestion des incidents, et beaucoup d'entre elles ont adopté la forme plurielle : les causes profondes.

Runbooks

Documents qui fournissent des procédures détaillées pour la gestion des incidents. Ils sont généralement gérés par un administrateur système ou une équipe de contrôle des opérations réseau (NOC). Ils peuvent être numériques ou imprimés.

Périmètre

Étendue d'un problème, d'une solution, d'un projet, ou encore d'une capacité.

Support de deuxième ligne

Personnes ayant des capacités supplémentaires (temps, expérience, connaissances, ressources) pour résoudre des problèmes qui peuvent dépasser les capacités des intervenants en première ligne.

Changement de service

Mises à jour, corrections, déclassements ou autres changements apportés à un service.

Centre de services

Équipe qui prend en charge les demandes de support client et intervient en tant que point de contact entre les clients et les services informatiques.

Analyse des défaillances de service

Processus d'inspection d'une interruption de service pour en identifier la cause.

Accord de niveau de service (SLA)

Accord entre le fournisseur et le client sur des métriques mesurables telles que la disponibilité, la réactivité et les responsabilités.

Graphique SLAM (surveillance des accords de niveau de service)

Document qui consigne l'avancement et les données sur les objectifs de niveau de service.

Objectifs de niveau de service (SLO)

Accord au sein d'un SLA concernant une métrique spécifique comme le temps de disponibilité.

Niveaux de gravité (SEV)

Mesure dans laquelle un service est touché par un incident. Généralement, les équipes utilisent une structure de niveau de gravité comprenant 3 à 5 niveaux, 1 correspondant à la gravité la plus élevée et 3 ou 5 correspondant aux problèmes moins graves et moins urgents.

Point de défaillance unique

Variable dont dépend un système pour fonctionner. Par exemple : un élément de configuration essentiel.

Spécification

Enregistrement officiel des exigences relatives à une configuration informatique.

Ingénieur chargé de la fiabilité du site (SRE)

Ingénieur logiciel chargé des opérations. Les SRE sont généralement responsables de l'automatisation des tâches manuelles, de la gestion des SLO et des incidents.

Changements standard

Changements à faible risque, souvent répétés et pré-approuvés, comme l'ajout de mémoire ou de stockage.

De secours

Ressources inactives disponibles pour soutenir la gestion des incidents.

État

État actuel d'un service.

Page d'état

Emplacement dédié à la communication de l'état actuel d'un service, avec des mises à jour régulières sur l'état des incidents.

Expert en la matière

Personne ayant des connaissances spécifiques sur un problème ou encore un service spécifique.

Pile technologique

Langages de programmation, logiciels et composants d'une app. La stack techique comprend deux aspects : le front-end (orienté client) et le back-end (orienté développeur).

Métriques en tension

Données qui, lorsqu'un ensemble ou un point est modifié, ont un impact négatif sur d'autres points de données.

Seuil

Niveau ou nombre prédéfini qui, lorsqu'il est dépassé, génère une alerte. Par exemple, le seuil de chargement de la page de connexion peut être de trois secondes. Si la page prend plus de temps à charger, une alerte est générée.

Chronologie

Liste complète des événements, des changements, des corrections, des résultats et du moment où ils se sont produits au cours d'un incident.

Analyse de tendance

Enquête sur l'évolution temporelle des tendances. L'analyse des tendances part du principe que les tendances passées permettent de prédire les tendances futures en matière de données. Cela en fait une pratique précieuse pour la prévention des incidents.

Solution

Façon efficace d'implémenter une correction rapide qui permet de restaurer les fonctionnalités du système même si l'incident sous-jacent n'est pas encore résolu.

Charge de travail

Ressources (humaines et machines) nécessaires à la fourniture d'un service informatique.