Réconcilier AD, EDR et inventaire : un outil construit avec l'IA

Je n’ai quasiment jamais vu un parc où tout le monde était d’accord sur le nombre de postes. Les achats en comptent un certain nombre, l’Active Directory un autre, la console de l’EDR un troisième, Intune ou SCCM un quatrième, et l’inventaire, quand il existe, ajoute sa propre version. Chacun a raison de son point de vue. Le problème commence quand on se demande lequel croire au moment où il faut savoir si un poste est protégé.

Cet article décrit la méthode que j’applique pour remettre ces sources d’accord, et surtout la façon dont j’utilise l’IA pour y arriver : pour écrire rapidement l’outil de réconciliation, qui ensuite tourne seul, sans IA, chaque semaine.

Pourquoi les sources du parc ne sont jamais alignées

Il y a toujours une bonne et une mauvaise raison à un écart. Les bonnes : un poste en stock pas encore déployé, un portable en réparation, un PC de remplacement qui cohabite quelques jours avec l’ancien. Les mauvaises : un compte d’ordinateur jamais nettoyé dans l’AD, un poste sorti du parc mais toujours compté dans la licence EDR, une machine réinstallée sous un autre nom, un agent qui a cessé de remonter sans que personne ne s’en aperçoive.

Pris un par un, ces écarts paraissent anodins. Ensemble, ils dessinent une zone grise où se cachent les postes réellement à risque. Et cette zone grise ne se voit dans aucune console, parce que chaque outil ne connaît que ce qu’il gère.

Le cas qui a tout déclenché : un agent EDR disparu après une mise à jour

C’est en croisant l’export de la console SentinelOne avec l’AD qu’on a mis le doigt sur un problème qu’aucun des deux outils ne signalait. Lors de certaines montées de version de l’agent, la désinstallation de l’ancienne version se faisait, mais la nouvelle ne s’installait pas dans la foulée. Le poste disparaissait simplement de la console EDR. Pas d’alerte, puisque pour SentinelOne la machine n’existait plus. Côté AD, en revanche, le compte d’ordinateur était bien vivant et se connectait tous les jours.

Résultat : des postes utilisés normalement, sans aucune protection, et invisibles pour qui ne regardait que la console de sécurité. Seul le croisement des deux sources pouvait les faire apparaître. C’est exactement le genre d’écart qu’un outil de réconciliation doit remonter sans qu’on ait à le chercher.

Les sources à croiser

Le périmètre dépend de chaque environnement, mais on retrouve presque toujours les mêmes :

• Active Directory : Get-ADComputer avec lastLogonTimestamp, OperatingSystem et Enabled. C’est la référence de ce qui s’authentifie réellement.
• EDR ou antivirus : export CSV de la console ou appel à l’API, avec la date de dernière remontée et la version de l’agent.
• Gestion des postes : Intune via Microsoft Graph (/deviceManagement/managedDevices), SCCM ou l’outil en place, qui fournissent souvent le numéro de série.
• Inventaire ou CMDB : GLPI, un tableur, ou l’export de l’outil de ticketing.
• Achats : la liste des machines facturées, avec leur numéro de série. C’est la source la plus souvent oubliée, et pourtant la seule qui dit ce qui devrait exister.

Choisir la clé de rapprochement

C’est là que la plupart des tentatives échouent. Le nom de machine paraît évident, mais il change à chaque réinstallation et ne s’écrit pas pareil partout : en majuscules dans l’AD, avec le suffixe DNS dans l’EDR, tronqué à 15 caractères ailleurs. Le numéro de série est plus stable, mais l’AD ne le connaît pas.

En pratique, je rapproche en deux passes. D’abord sur le numéro de série entre les sources qui le portent (EDR, Intune, achats). Ensuite sur le nom normalisé pour raccrocher l’AD : passage en majuscules, suppression du suffixe de domaine, troncature à 15 caractères. Les postes qui ne se raccrochent à rien dans aucune des deux passes forment déjà une première liste à examiner.

function Format-NomPoste([string]$Nom) {
    if (-not $Nom) { return $null }
    $court = ($Nom -split '\.')[0].Trim().ToUpperInvariant()
    $court.Substring(0, [Math]::Min(15, $court.Length))
}

$ad  = Get-ADComputer -Filter 'Enabled -eq $true' -Properties lastLogonTimestamp |
       Select-Object @{n='Cle';e={Format-NomPoste $_.Name}},
                     @{n='DerniereConnexion';e={[datetime]::FromFileTime($_.lastLogonTimestamp)}}
$edr = Import-Csv .\export-edr.csv |
       Select-Object @{n='Cle';e={Format-NomPoste $_.'Endpoint Name'}}, 'Last Active'

$sansEdr = $ad | Where-Object {
    $_.DerniereConnexion -gt (Get-Date).AddDays(-30) -and $_.Cle -notin $edr.Cle
}

Cet extrait ne fait qu’une chose : lister les postes actifs dans l’AD depuis 30 jours et absents de l’EDR. C’est la requête qui aurait trouvé les agents SentinelOne disparus. L’outil complet fait le même exercice dans tous les sens, pour chaque paire de sources.

Ce que l’IA apporte, et ce qu’elle n’apporte pas

Je pourrais demander à l’IA de croiser les exports à chaque fois. Ce serait une erreur. Le résultat changerait d’une exécution à l’autre, il faudrait lui renvoyer des données potentiellement sensibles chaque semaine, et personne d’autre que moi ne saurait le reproduire.

Je m’en sers donc pour ce qu’elle fait bien : écrire vite un outil propre. Je lui décris les sources, le format réel des exports, la clé de rapprochement et le rapport attendu. Elle produit un premier script en quelques minutes. Ensuite vient le vrai travail : le relire, le tester sur les données du client, corriger les cas qu’elle n’avait pas vus (les noms avec tiret, les machines virtuelles qui n’ont pas de numéro de série, les comptes AD désactivés mais pas supprimés). Deux ou trois itérations suffisent généralement.

Au final, le client récupère un script PowerShell ou Python lisible, versionné, qu’il peut modifier sans moi. L’IA a servi à aller vite au moment de la construction. Elle n’intervient plus du tout ensuite.

Le rapport : des listes, pas un tableau de bord

Le livrable n’a pas besoin d’être joli. Il doit être actionnable. Pour chaque source, la liste des postes absents, triée par risque :

1. postes actifs dans l’AD mais inconnus de l’EDR : non protégés, priorité absolue ;
2. postes dans l’EDR qui ne remontent plus depuis plus de 15 jours : agent cassé ou machine sortie du parc ;
3. comptes AD sans connexion depuis 90 jours : à désactiver, puis supprimer ;
4. numéros de série achetés introuvables partout : en stock, perdus ou volés ;
5. postes gérés par Intune ou SCCM mais absents de l’inventaire : la CMDB à mettre à jour.

Chaque ligne peut ouvrir un ticket de remédiation. Le premier passage est toujours un peu douloureux, la liste est longue. Les suivants ne remontent plus que les nouveaux écarts de la semaine, et c’est là que l’outil devient vraiment utile.

Planifier et ne plus y penser

Une fois validé, le script part en tâche planifiée, une fois par semaine. Il dépose son rapport dans un partage ou l’envoie par mail, et alerte seulement si la liste prioritaire n’est pas vide. Un contrôle de type healthcheck vérifie qu’il a bien tourné : un outil de réconciliation qui s’arrête en silence recrée exactement le problème qu’il devait résoudre.

Les limites à garder en tête

La réconciliation ne vaut que ce que valent les exports. Un champ mal renseigné dans l’outil d’achats, une API EDR qui pagine mal, et des postes disparaissent du rapport sans raison. Il faut donc contrôler les volumes à chaque exécution : si une source perd soudainement 30 % de ses lignes, c’est l’export qui est cassé, pas le parc.

Côté données, les exports contiennent des noms de machines et parfois d’utilisateurs. Quand j’utilise l’IA pour construire l’outil, je lui donne des échantillons anonymisés, jamais l’export réel. Le script, lui, tourne chez le client, sur ses données, sans rien envoyer à l’extérieur.

Cette démarche fait partie de ma façon d’utiliser l’IA appliquée à l’infrastructure : construire vite des outils durables plutôt que de déléguer l’analyse. Si votre parc raconte plusieurs histoires selon la console qu’on ouvre, parlons-en.