# Processus · Documentation CentOps > Comment s’enchaînent événements, incidents, problèmes, demandes et changements, et par quels états passe chaque enregistrement. URL: https://centops.eywo.digital/fr/docs/processes/ Language: fr Last updated: 2026-10-30 Documentation # Processus Comment s’enchaînent événements, incidents, problèmes, demandes et changements, et par quels états passe chaque enregistrement. 1. [Vue d’ensemble](https://centops.eywo.digital/fr/docs/) 2. [Modules](https://centops.eywo.digital/fr/docs/modules/) 3. [Processus](https://centops.eywo.digital/fr/docs/processes/) 4. [Modèle CMDB](https://centops.eywo.digital/fr/docs/cmdb-model/) 5. [Termes et FAQ](https://centops.eywo.digital/fr/docs/terms/) 6. [Fiche produit](https://centops.eywo.digital/fr/docs/datasheet/) ## Enchaînement des processus ### Détecter et rétablir Du signal de supervision à la correction durable 1. **Événement** La supervision (Zabbix, Prometheus, Checkmk, Grafana, Dynatrace, API générique) envoie un événement. L’application l’associe à un élément de configuration par nom d’hôte, IP, numéro de série ou ID d’entité et ajoute le service, le client et l’équipe. Les règles de filtrage écartent le bruit. 2. **Alerte** Les événements répétés d’un même problème (même empreinte) forment une alerte et n’augmentent que son compteur. Un message OK résout l’alerte. Un changement en cours sur l’élément supprime l’alerte pour qu’elle ne réveille pas l’opérateur. 3. **Situations** Les alertes sont regroupées en situations selon une simulation de panne dans la CMDB : la cause n’est qu’un élément dont la panne explique réellement les alertes (panne d’hyperviseur → ses VM et applications). Les alertes expliquées sont des symptômes – sans notification, résolues avec la cause. Si le support commun de plusieurs éléments en alerte est silencieux, l’application le déduit de la topologie. Le regroupement se fait ensuite par service et période ou par changement associé. L’opérateur confirme la situation, l’attribue à une équipe, la met en sourdine ou en crée un incident. 4. **Incident** Une interruption non planifiée d’un service. L’impact et l’équipe sont calculés à partir de la CMDB (selon l’impact réel de la panne – une perte de redondance signifie un impact faible), la priorité à partir de l’impact et de l’urgence, les échéances à partir du SLA. Les alertes restent liées à l’incident – leur résolution propose de résoudre l’incident. Pour P1/P2, une war room peut être ouverte. 5. **Problème** La cause d’incidents récurrents ou majeurs. Il naît d’un incident, de l’analyse d’un incident majeur, d’une revue après changement ou du contrôle quotidien des incidents récurrents. Une erreur connue comporte un contournement. 6. **Changement** La correction définitive est réalisée par un changement créé depuis le problème ou lié à celui-ci (un changement urgent se crée depuis l’incident). Un changement peut résoudre plusieurs incidents et problèmes. Après une réussite, un problème dont la cause est documentée passe à Résolu et les incidents liés sont invités à vérifier ; un changement en échec renvoie le problème en analyse. 7. **Vérification après changement** Pendant 24 h après la fin d’un changement, l’application surveille les alertes sur ses éléments. S’il en apparaît, la revue post-implémentation est obligatoire et vous pouvez créer depuis la fiche du changement un incident qui l’enregistre comme cause – et cet incident peut mener à un nouveau problème. ### Demander et livrer De la demande d’un utilisateur à l’infrastructure livrée 1. **Demande** L’utilisateur choisit un élément du catalogue (nouveau serveur, capacité, pare-feu, accès…), remplit le formulaire et la demande passe par l’approbation selon les règles de l’élément. 2. **Conversion incident ↔ demande** Un incident qui n’est pas une panne mais une demande de service est converti en demande (et inversement). Le nouvel enregistrement reprend la description, l’élément et le déclarant, le délai court à partir de la conversion et l’enregistrement d’origine est annulé avec un lien. 3. **Traitement** L’équipe de résolution prend en charge la demande et coche les étapes de traitement dans le délai fixé par le catalogue et les heures ouvrées. 4. **Changement** Un élément qui modifie l’infrastructure est lié à un modèle de changement. Pour un modèle standard, l’application crée et planifie elle-même le changement, sans approbation. Le demandeur est informé quand il est planifié, démarré et terminé ; la demande ne peut être traitée qu’une fois le changement terminé. 5. **Élément de configuration** Un changement terminé met les éléments cibles en service (ou les retire) ; la découverte confirme le nouvel état. ### Vulnérabilités issues des scanners Tenable / Nessus → CMDB → gestion des correctifs 1. **Scan** CentOps récupère lui-même les vulnérabilités de Tenable Vulnerability Management via l’API d’export (au premier passage les vulnérabilités ouvertes, ensuite seulement les changements, y compris les corrigées). Les résultats de Nessus et Tenable Security Center sont chargés sous forme de fichier .nessus. Les vulnérabilités avec CVE passent dans la gestion des correctifs. 2. **Rapprochement avec la CMDB** Un équipement scanné est associé dans cet ordre : décision enregistrée → FQDN (nom d’hôte + domaine de l’OS) → adresse MAC → nom court + domaine → IP, cette dernière uniquement pour les équipements réseau. Seule une correspondance univoque sans contradiction est automatique ; un autre élément selon un autre attribut, un OS différent, un autre domaine ou un élément retiré signifient un conflit ou une revue. 3. **Revue** Vous confirmez un équipement en revue, l’associez à un autre élément ou l’excluez ; la décision s’applique aussi aux scans suivants. Les équipements non associés sont vus par le scanner sur le réseau mais inconnus de la CMDB. 4. **Gestion des correctifs** Les vulnérabilités des équipements associés reçoivent une échéance de remédiation selon la politique (KEV, CVSS) et entrent dans le plan de correctifs. Une vulnérabilité que le scanner ne signale plus est clôturée comme corrigée. ### Configuration issue des sources Comment la CMDB est alimentée et maintenue 1. **Découverte et supervision** La découverte depuis vCenter, HMC, OpenShift, les clouds et la supervision (Dynatrace) crée et met à jour les éléments et les relations. Les modifications manuelles de l’emplacement des VM et des partitions ne sont pas autorisées – la source fait foi. 2. **Élément sans responsable** Les nouveaux éléments sans équipe responsable issus d’une même exécution d’une source sont regroupés dans un seul changement. 3. **Changement « Ajouter le responsable »** Un changement standard sans approbation attribué au gestionnaire de configuration : trouver le responsable, ajouter l’équipe et le service, vérifier le classement et clôturer. Vous le trouverez dans Mon travail. 4. **Élément complet** Un élément avec un responsable est pris en compte dans l’impact des incidents et des changements, dans les coûts et dans le contrôle de la qualité des données. ## Cycles de vie des enregistrements ### Incidents Un incident va du signalement à la clôture en passant par l’attribution, le traitement et la résolution. La mise en attente arrête le temps SLA. Nouveau→Attribué→En cours→Résolu→Clos En attente · suspend le délai SLAétat secondaire · En coursAttente fournisseurétat secondaire · En coursAnnuléétat final Transitions (16) - Nouveau → Attribué · Attribuer - Nouveau → En cours · Prendre en charge et traiter - Attribué → En cours · Prendre en charge et traiter - En attente → En cours · Reprendre - Attente fournisseur → En cours · Le fournisseur a répondu - Attribué → Résolu · Résoudre - En cours → Résolu · Résoudre - En attente → Résolu · Résoudre - Attente fournisseur → Résolu · Résoudre - En cours → En attente · Mettre en attente - En cours → Attente fournisseur · Attente fournisseur - En cours → Attribué · Renvoyer dans la file - Résolu → Clos · Clore - Résolu → En cours · Rouvrir - Nouveau → Annulé · Annuler - Attribué → Annulé · Annuler ### Demandes Une demande est soumise, approuvée selon le catalogue, traitée et clôturée par le demandeur. Soumise→En attente d’approbation→En cours→Traitée→Clos Approuvéeétat secondaire · En attente d’approbationRefuséeétat finalAnnuléétat final Transitions (10) - En attente d’approbation → En cours · Approuver - En attente d’approbation → Refusée · Refuser - Approuvée → En cours · Prendre en charge - En cours → Traitée · Traitée - Traitée → Clos · Clore - Traitée → En cours · Renvoyer au traitement - En attente d’approbation → Annulé · Annuler la demande - Soumise → Annulé · Annuler la demande - Approuvée → Annulé · Annuler la demande - En cours → Annulé · Annuler la demande ### Problèmes Le problème est analysé, la cause devient une erreur connue avec un contournement et la correction est réalisée par un changement – après sa réussite, le problème passe de lui-même à Résolu. Nouveau→Analyse des causes→Résolu→Clos Erreur connueétat secondaire · Analyse des causesAnnuléétat final Transitions (10) - Nouveau → Analyse des causes · Démarrer l’analyse - Analyse des causes → Erreur connue · Publier l’erreur connue - Analyse des causes → Résolu · Résoudre - Erreur connue → Résolu · Résoudre - Erreur connue → Analyse des causes · Retour à l’analyse - Résolu → Clos · Clore - Résolu → Analyse des causes · Rouvrir - Nouveau → Annulé · Annuler - Analyse des causes → Annulé · Annuler - Erreur connue → Annulé · Annuler ### Changements Un changement est rédigé, soumis à approbation, planifié dans une fenêtre de maintenance, réalisé et évalué. Seule l’application le fait passer dans les états d’approbation. Brouillon→En attente d’approbation→Approuvée→En cours→Traitée Échouéétat secondaire · En coursRefuséeétat finalAnnuléétat final Transitions (7) - Approuvée → En cours · Démarrer les travaux - En cours → Traitée · Traitée - En cours → Échoué · Échoué - Brouillon → Annulé · Annuler le changement - En attente d’approbation → Annulé · Annuler le changement - Refusée → Annulé · Annuler le changement - Approuvée → Annulé · Annuler le changement ### Éléments de configuration Un élément de configuration est planifié, en service, en maintenance (pendant un changement) ou retiré. Pour les classes contrôlées, seul un changement peut modifier l’état. Planifié→En service Maintenanceétat secondaire · En serviceRetiréétat final Transitions (7) - Planifié → En service · Mettre en service - En service → Maintenance · Maintenance - Maintenance → En service · Retour en service - Retiré → Planifié · Restaurer (replanifier) - Planifié → Retiré · Mettre au rebut - En service → Retiré · Mettre au rebut - Maintenance → Retiré · Mettre au rebut ### Artefacts d’architecture d’entreprise Un artefact d’architecture d’entreprise passe par le brouillon, l’approbation et la validité jusqu’au retrait. Brouillon→Approuvée→En construction→En service→En retrait progressif Mis au rebutétat finalRefuséeétat final Transitions (10) - Brouillon → Approuvée · Approuver - Approuvée → Brouillon · Retour au brouillon - Approuvée → En construction · Démarrer la construction - Approuvée → En service · Mettre en service - En construction → En service · Mettre en service - En service → En retrait progressif · Démarrer le retrait progressif - En retrait progressif → En service · Annuler le retrait progressif - En retrait progressif → Mis au rebut · Mettre au rebut - Refusée → Brouillon · Proposer à nouveau - Brouillon → Refusée · Refuser La carte des processus et le modèle CMDB sont générés à partir de l’état actuel de l’application · mis à jour 30 octobre 2026