Détecter les incohérences — CrossRiver
Plusieurs sources décrivent les mêmes serveurs, et elles ne sont pas toujours d'accord : un scanner voit RHEL 8 là où la gestion de configuration voit RHEL 9, un serveur figure dans la CMDB mais n'a jamais été scanné, une CVE « corrigée » est toujours remontée. CrossRiver fait le recoupement à votre place et ne vous présente que les désaccords réels.
Page : Analyse → CrossRiver (/crossriver/).
Détection déterministe, interprétation assistée
La détection suit des règles explicites : mêmes données, mêmes incohérences. L'IA locale (optionnelle) classe chaque incohérence, explique sa cause probable et suggère une résolution — mais c'est toujours un humain qui valide. Sans IA, la détection fonctionne à l'identique, sans le tri par cause.
Les familles d'incohérences
| Famille | Exemple |
|---|---|
| Valeur | Le scanner voit RHEL 8, la gestion de configuration RHEL 9 |
| Présence | Un serveur présent dans l'annuaire, absent de l'inventaire |
| État | Une CVE marquée corrigée côté patch, toujours remontée par le scanner |
| Temporelle | Même fait, mais une source date d'avant la dernière campagne de patch |
| Identité / nommage | Le même serveur sous un nom court, un FQDN et une IP différents |
| Couverture | Un serveur connu d'une source, absent d'une autre où il est attendu |
| Complétude | Un serveur actif sans équipe, application, responsable ou environnement / zone d'exposition |
| Zombie | Un serveur de l'inventaire qu'aucune source n'a vu depuis plus de 30 jours |
Les catégories
Chaque ligne du tableau porte une catégorie. Voici ce que chacune veut dire et quoi faire.
| Catégorie | Ce que ça signifie | Que faire |
|---|---|---|
| Écart d'OS | Deux sources donnent un système différent pour le même serveur (par exemple Windows Server 2019 chez l'un, 2022 chez l'autre). Les noms sont comparés après normalisation : « Microsoft Windows Server 2019 Standard » et « Windows Server 2019 » ne sont pas un écart. | Vérifier lequel est exact ; corriger la source périmée ou le rapprochement du serveur. |
| Version d'OS différente | Même système, mais la version ou le numéro de build diverge (10.0.17763 contre 10.0.20348). Une source qui ne donne que le cycle (« 8 » contre « 8.8 ») n'est pas un écart. | Souvent une machine mise à jour que l'une des sources n'a pas relue ; relancer la synchronisation de la source en retard. |
| IP différente entre sources | Une source donne une adresse sans rapport avec ce que disent les autres. Un serveur à plusieurs adresses n'est jamais signalé dès qu'une adresse est commune. | Adresse changée (DHCP, migration) ou enregistrement DNS périmé : corriger la source fautive. |
| Absent de … (GLPI, SUSE Manager, Rapid7…) | Le serveur est dans l'inventaire mais une source qui devrait le voir ne le connaît pas. | Ajouter le serveur à la source, ou exclure la source de la vérification si elle ne concerne qu'une partie du parc. |
| Inconnu de l'inventaire : … | Une source connaît un hôte qui n'est rattaché à aucun serveur de l'inventaire. Les appareils Entra / Intune sont écartés : ce sont des postes, exclus de l'inventaire par choix. | Rapprocher l'hôte d'un serveur existant, ou le créer s'il manquait. |
| Équipe / Application / Responsable manquant(e) | Un serveur actif n'a pas de rattachement. Sévérité basse. | Renseigner la fiche du serveur : ces champs servent au périmètre « mes serveurs » et aux filtres des tableaux de bord. |
| Qualification manquante | L'environnement ou la zone d'exposition du serveur n'est pas renseigné. | Les renseigner sur la fiche du serveur (ils entrent dans le score de risque). |
| Serveur zombie | Aucune source n'a vu ce serveur depuis plus de 30 jours (un serveur créé depuis moins de 30 jours ou saisi à la main n'est jamais signalé). Les zombies ne sont pas comptés dans les données manquantes. | Vérifier s'il a été arrêté : le retirer de l'inventaire, ou réparer la source qui ne le voit plus. |
| IP partagée entre serveurs | Plusieurs serveurs de l'inventaire déclarent la même adresse. | Doublon à fusionner ou adresse erronée. |
| Source en retard | Un connecteur n'a pas synchronisé depuis plus longtemps que ses pairs. | Vérifier le connecteur. |
| CVE patchée mais revue par un scan | Une CVE marquée corrigée a été revue par un scan après coup. | Vérifier que le correctif est bien appliqué. |
| Référence vers un serveur absent | Un compte ou un chemin d'administration pointe un serveur qui n'existe plus. | Nettoyer la source qui référence ce serveur. |
Dans la configuration de CrossRiver, chaque famille se coche séparément. Les familles completeness et zombie sont activées sur une installation existante à la mise à jour, une seule fois : ce que vous décochez ensuite reste décoché.
Couverture par source
En haut de page, une carte par source détectée dans votre parc (GLPI, vCenter, Rapid7…) donne le nombre de serveurs absents de cette source — ou « OK » si aucun ne manque. Un clic sur une carte ouvre la liste filtrée sur ces serveurs.
Les sources sont détectées automatiquement : dès qu'une source a été vue au moins une fois dans le parc, elle devient une vérification de couverture, sans configuration.
Exclure une source non pertinente
Une source qui ne concerne qu'une partie du parc (sauvegarde des seules VM, WSUS pour les seuls serveurs Windows) signalerait à tort tous les autres serveurs comme « manquants ». Ajoutez-la à la liste d'exclusion dans la configuration de CrossRiver (bouton ⚙ Configuration de la page).
Traiter une incohérence
Chaque ligne de la liste porte une catégorie en clair : « Écart d'OS », « Absent de GLPI », « Absent de SUSE Manager », « IP partagée entre serveurs », « Source en retard »… Au-dessus du tableau, une puce par catégorie donne le nombre de lignes concernées : un clic sur une puce ne garde que cette catégorie, « Toutes » les remet. Les puces tiennent compte des autres filtres (statut, sévérité…), donc leurs nombres changent quand vous filtrez.
La liste se trie et se filtre aussi par entité, catégorie, sévérité, statut et date de dernière vue. Un clic sur une ligne ouvre le panneau de détail (la famille technique de l'incohérence y figure) :
- les valeurs en désaccord, source par source ;
- si l'IA est active : la classification (vrai conflit, décalage de scan, nommage, lacune de couverture), la cause probable et la résolution suggérée ;
- les actions de résolution.
| Action | Statut obtenu | Quand l'utiliser |
|---|---|---|
| ✓ Résoudre | Résolu | Le désaccord est corrigé à la source |
| Marquer bénin | Bénin | Désaccord attendu, sans conséquence (ex. convention de nommage) |
| Escalader | Escaladé | Nécessite une action d'une autre équipe |
| ↺ Rouvrir | Ouvert | Revenir sur une décision |
Les mêmes actions s'appliquent en groupe aux incohérences cochées dans la liste.
Généraliser une décision
Cocher Généraliser en décision (avec une justification facultative) enregistre la résolution dans la mémoire des décisions d'InfraRiver (« ce conflit nom court / FQDN sur ce domaine est notre convention, c'est bénin »). Lors des détections suivantes, l'IA reçoit ce précédent — comme une question (« cette décision, validée par X le JJ/MM, s'applique-t-elle ici ? »), jamais comme une vérité appliquée en silence.
C'est ainsi que CrossRiver « apprend » votre environnement, sans apprentissage automatique opaque : chaque décision est lisible, attribuée, révocable et exportable pour un audit.
Lancer une analyse
La détection tourne selon la planification du connecteur. Deux boutons permettent de la relancer à la demande :
- ↻ Lancer une passe de détection ;
- 🧠 Classifier avec l'IA — passe de classification séparée, plus lente (un appel au modèle local par incohérence) ; visible seulement si l'IA est activée.