DEV Community

Cover image for Maigret : Scanner OSINT Indestructible - Découvrez Tout
Antoine Laurent
Antoine Laurent

Posted on • Originally published at apidog.com

Maigret : Scanner OSINT Indestructible - Découvrez Tout

La plupart des outils OSINT vieillissent vite : les sites déplacent leurs points d’accès, les captchas changent, les pages de profil sont redesignées, et les signatures cassent. Maigret fait exception : l’outil fonctionne depuis des années, prend en charge plus de 3 000 sites, fournit un package Python, un bot Telegram et une interface web, et montre surtout comment construire un scanner robuste face à la dérive du web.

Essayez Apidog aujourd’hui

Ce guide s’adresse aux ingénieurs. L’objectif n’est pas d’expliquer comment cibler des personnes, mais de décortiquer les choix d’architecture de Maigret : base de signatures, détection multi-signal, recherche récursive, gestion de dérive et post-traitement IA. Ces mêmes patterns s’appliquent directement aux tests d’API que vous écrivez avec Apidog.

Si vous ne l’avez pas encore lu, notre article sur le test d’API sans Postman en 2026 couvre des idées proches : assertions, contrats et détection de dérive.

TL;DR

  • Maigret collecte des informations publiques à partir d’un nom d’utilisateur en vérifiant plus de 3 000 sites.
  • Sa robustesse vient d’une base de signatures versionnée, mise à jour automatiquement.
  • Il ne se limite pas aux codes HTTP : il combine chaînes de présence, chaînes d’absence, en-têtes, règles d’extraction et gestion des cas inconnus.
  • Les usages légitimes incluent l’OSINT journalistique, la récupération de comptes personnels, les audits de sécurité autorisés, la recherche de personnes disparues avec cadre légal et la surveillance d’abus de marque.
  • L’utiliser sur des individus sans consentement peut relever du harcèlement ou du stalking selon les juridictions.
  • Les mêmes modèles d’ingénierie s’appliquent aux tests d’API : signatures, fixtures, assertions multi-signaux, relecture planifiée et alertes de dérive dans Apidog.

Ce que Maigret est — et n’est pas

Maigret est un outil Python sous licence MIT, maintenu par soxoj. Son principe : fournir un nom d’utilisateur, puis vérifier son existence sur une grande base de sites publics.

Installation minimale :

pip install maigret
maigret username
Enter fullscreen mode Exit fullscreen mode

Pour scanner l’ensemble de la base plutôt que le sous-ensemble par défaut :

maigret username -a
Enter fullscreen mode Exit fullscreen mode

image

Trois points sont importants.

1. Maigret lit uniquement des données publiques

Pas de connexion, pas de vol d’identifiants, pas de clé API privée. Si un profil est visible publiquement, Maigret peut tenter de le lire. Si le site bloque l’accès anonyme ou renvoie une page ambiguë, le résultat peut être not found, unknown ou signalé comme capturé par un captcha.

2. Il est utilisé dans des contextes légitimes

Exemples :

  • journalistes d’investigation ;
  • équipes de protection de marque ;
  • équipes de sécurité avec autorisation écrite ;
  • bénévoles travaillant avec des familles ou autorités dans des dossiers de personnes disparues ;
  • audits de surface d’attaque publique.

3. Il peut être mal utilisé

Comme tout outil OSINT, Maigret peut franchir des limites éthiques et légales s’il est utilisé sur des personnes privées sans consentement. Les lois sur le harcèlement et le stalking existent dans l’UE, aux États-Unis, au Royaume-Uni et dans de nombreuses autres juridictions.

Le reste de cet article se concentre donc sur l’ingénierie et les modèles réutilisables pour le test d’API.

La base de signatures de sites

La meilleure idée de Maigret est sa base de signatures. Chaque site est décrit comme une entrée de données, généralement en JSON, avec les informations nécessaires pour répondre à plusieurs questions :

  • Quelle URL construire pour ce nom d’utilisateur ?
  • Comment reconnaître une page “utilisateur trouvé” ?
  • Comment reconnaître une page “utilisateur introuvable” ?
  • Quels champs publics peut-on extraire ?
  • Le site impose-t-il des en-têtes spécifiques ?
  • Le site utilise-t-il des limites de débit ou des captchas ?
  • À quelle catégorie ou région appartient-il ?

Un scanner naïf ferait ceci :

import requests

username = "example"
url = f"https://example.com/{username}"

response = requests.get(url)

if response.status_code == 200:
    print("trouvé")
elif response.status_code == 404:
    print("non trouvé")
else:
    print("inconnu")
Enter fullscreen mode Exit fullscreen mode

Ce modèle échoue sur beaucoup de sites réels, car de nombreux services renvoient 200 OK même pour une page “utilisateur introuvable”.

Maigret utilise plutôt une logique de signature :

{
  "name": "ExampleSite",
  "urlMain": "https://example.com",
  "url": "https://example.com/{username}",
  "presenseStrs": ["Profile", "@{username}"],
  "absenceStrs": ["User not found", "This account does not exist"],
  "headers": {
    "User-Agent": "Mozilla/5.0"
  },
  "tags": ["social", "us"]
}
Enter fullscreen mode Exit fullscreen mode

Le principe est simple :

  • si les chaînes de présence sont trouvées et les chaînes d’absence absentes, le compte est probablement trouvé ;
  • si les chaînes d’absence sont trouvées, le compte est probablement absent ;
  • si les signaux se contredisent, le résultat reste inconnu.

C’est exactement le modèle que vous voulez dans une suite de tests d’API.

Au lieu de tester seulement :

pm.test("status is 200", function () {
  pm.response.to.have.status(200);
});
Enter fullscreen mode Exit fullscreen mode

vous devez vérifier plusieurs signaux :

pm.test("réponse utilisateur valide", function () {
  pm.response.to.have.status(200);

  const body = pm.response.json();

  pm.expect(body).to.have.property("id");
  pm.expect(body).to.have.property("email");
  pm.expect(body.status).to.eql("active");
  pm.expect(body).to.not.have.property("error");
});
Enter fullscreen mode Exit fullscreen mode

Avec Apidog, ce modèle devient une suite d’assertions versionnée sur chaque endpoint : statut, corps, schéma, en-têtes et valeurs attendues.

Nous avons détaillé cette approche dans le guide sur le développement d’API contract-first et dans le guide de test de serveur MCP.

Comment Maigret distingue “trouvé” et “non trouvé”

La difficulté principale n’est pas d’envoyer une requête HTTP. C’est d’interpréter correctement la réponse.

Un site peut répondre :

  • 404 Not Found pour un utilisateur absent ;
  • 200 OK avec un message “User not found” ;
  • 200 OK avec une page d’accueil ;
  • 302 Redirect vers une page de login ;
  • 403 Forbidden si l’IP est bloquée ;
  • 200 OK avec un captcha ;
  • 429 Too Many Requests si le débit est trop élevé.

Maigret encode donc la décision dans des règles déclaratives.

Exemple de logique simplifiée :

def classify_response(html, presence_strings, absence_strings):
    has_presence = all(s in html for s in presence_strings)
    has_absence = any(s in html for s in absence_strings)

    if has_presence and not has_absence:
        return "found"

    if has_absence:
        return "not_found"

    return "unknown"
Enter fullscreen mode Exit fullscreen mode

Cette approche est plus fiable qu’un simple test de statut.

Pour vos APIs, appliquez le même principe :

const response = await fetch("https://api.example.com/users/123");
const body = await response.json();

if (
  response.status === 200 &&
  body.id &&
  body.email &&
  body.accountStatus === "active" &&
  !body.error
) {
  console.log("contrat valide");
} else {
  console.log("contrat cassé ou réponse ambiguë");
}
Enter fullscreen mode Exit fullscreen mode

Dans Apidog, traduisez cette logique en assertions :

  • code HTTP attendu ;
  • schéma JSON attendu ;
  • champs obligatoires ;
  • valeurs interdites ;
  • format des erreurs ;
  • en-têtes de cache, auth ou rate limit.

Recherche récursive et extraction d’informations

Quand Maigret trouve un compte, il ne s’arrête pas à “existe / n’existe pas”.

Il peut extraire des informations publiques exposées par le profil :

  • autres pseudos ;
  • nom affiché ;
  • liens externes ;
  • emails publics ;
  • numéros publics ;
  • métadonnées de profil ;
  • comptes liés.

Ensuite, ces nouveaux identifiants peuvent alimenter une recherche récursive.

Le pattern général ressemble à ceci :

queue = ["username_initial"]
visited = set()

while queue:
    identifier = queue.pop()

    if identifier in visited:
        continue

    visited.add(identifier)

    results = search_public_profiles(identifier)

    for profile in results:
        new_identifiers = extract_identifiers(profile)
        queue.extend(new_identifiers)
Enter fullscreen mode Exit fullscreen mode

Pour l’OSINT, cela permet de passer d’un compte isolé à une cartographie de profils publics liés.

Pour les tests d’API, le même principe sert à découvrir les chemins manquants :

  1. Tester un endpoint.
  2. Observer les champs retournés.
  3. Identifier les IDs, liens ou ressources liées.
  4. Ajouter des tests pour ces ressources.
  5. Répéter.

Exemple :

{
  "id": "ord_123",
  "customerId": "cus_456",
  "paymentId": "pay_789",
  "shipmentId": "shp_001"
}
Enter fullscreen mode Exit fullscreen mode

Si votre test ne couvre que /orders/{id}, il manque probablement :

GET /customers/cus_456
GET /payments/pay_789
GET /shipments/shp_001
Enter fullscreen mode Exit fullscreen mode

Une suite de test robuste doit suivre ces relations et vérifier les contrats associés.

Captchas, limites de débit et réponses bloquées

Maigret ne “casse” pas les captchas. Il détecte les cas où l’automatisation n’est plus fiable et marque le résultat comme ambigu ou bloqué.

Ses stratégies incluent notamment :

  • rotation d’User-Agent ;
  • respect des en-têtes de retry ;
  • tentative sur domaine mobile ou simplifié ;
  • routage via Tor ou I2P lorsque le site le permet ;
  • détection des pages captcha.

Mais le README est clair : si un site applique une anti-automatisation agressive, Maigret n’essaie pas de forcer le passage.

Pour les APIs, adoptez la même posture.

Un exécuteur de tests doit savoir gérer :

HTTP/1.1 429 Too Many Requests
Retry-After: 60
Enter fullscreen mode Exit fullscreen mode

Exemple de backoff simple :

async function requestWithRetry(url, maxRetries = 3) {
  for (let attempt = 0; attempt <= maxRetries; attempt++) {
    const response = await fetch(url);

    if (response.status !== 429) {
      return response;
    }

    const retryAfter = Number(response.headers.get("Retry-After") || 1);
    await new Promise(resolve => setTimeout(resolve, retryAfter * 1000));
  }

  throw new Error("Rate limit persistant après plusieurs tentatives");
}
Enter fullscreen mode Exit fullscreen mode

Bonnes pratiques :

  • ne pas ignorer les 429 ;
  • ne pas lancer des tests parallèles sans limite ;
  • isoler les environnements de test ;
  • utiliser des quotas dédiés ;
  • documenter les limites attendues dans vos contrats d’API.

Le problème de la dérive des signatures

Une base de 3 000 sites n’est utile que si elle reste à jour.

Les sites changent :

  • structure HTML ;
  • URL de profil ;
  • messages d’erreur ;
  • mécanismes anti-bot ;
  • redirections ;
  • marques et domaines après acquisition.

Une signature obsolète crée deux risques :

  • faux négatif : un compte existe mais n’est pas détecté ;
  • faux positif : un compte est signalé alors qu’il n’existe pas.

Maigret limite ce problème avec plusieurs mécanismes :

  • mise à jour automatique depuis le dépôt GitHub central toutes les 24 heures ;
  • contributions communautaires via issues et pull requests ;
  • option --update pour forcer une mise à jour ;
  • harnais de test validant les signatures contre des comptes connus et consentants.

Commande utile avant une investigation sérieuse :

maigret --update
maigret username -a
Enter fullscreen mode Exit fullscreen mode

Le point important pour les ingénieurs : Maigret conserve des exemples de comptes valides pour tester que les signatures fonctionnent encore.

C’est le même modèle qu’une fixture d’API.

Exemple de fixture :

{
  "request": {
    "method": "GET",
    "url": "/users/usr_123"
  },
  "expected": {
    "status": 200,
    "body": {
      "id": "usr_123",
      "role": "admin",
      "active": true
    }
  }
}
Enter fullscreen mode Exit fullscreen mode

Vous pouvez ensuite rejouer régulièrement cette fixture :

npm run api:test:regression
Enter fullscreen mode Exit fullscreen mode

Et détecter les changements :

 {
   "id": "usr_123",
-  "role": "admin",
+  "userRole": "admin",
   "active": true
 }
Enter fullscreen mode Exit fullscreen mode

Dans Apidog, ce workflow se traduit par :

  1. définir le contrat de l’endpoint ;
  2. enregistrer une réponse valide ;
  3. ajouter des assertions ;
  4. planifier l’exécution ;
  5. comparer les résultats ;
  6. alerter en cas de dérive.

Notre guide API DeepSeek V4 montre l’approche manuelle sur un fournisseur spécifique.

Le mode résumé IA optionnel

Maigret fournit un drapeau --ai qui transforme les résultats bruts en résumé lisible à l’aide d’un endpoint LLM compatible OpenAI. L’utilisateur fournit sa clé API ; Maigret structure l’appel.

Exemple :

maigret username -a --ai
Enter fullscreen mode Exit fullscreen mode

Le point d’architecture est important : le LLM ne décide pas si un compte correspond. Cette décision reste déterministe et basée sur les signatures.

Le LLM intervient seulement après :

  1. collecte ;
  2. classification ;
  3. extraction ;
  4. génération d’un rapport ;
  5. résumé.

C’est la bonne façon d’utiliser un LLM dans une chaîne de test.

Pour les APIs, gardez cette séparation :

  • assertions déterministes pour décider succès / échec ;
  • LLM pour résumer les résultats, pas pour juger la validité.

Mauvais modèle :

LLM → décide si l’API fonctionne
Enter fullscreen mode Exit fullscreen mode

Meilleur modèle :

Assertions déterministes → rapport structuré → résumé LLM
Enter fullscreen mode Exit fullscreen mode

Avec Apidog, vous pouvez garder les validations dans les tests, puis générer un résumé exploitable pour Slack, GitHub ou votre outil de reporting.

Notre article sur l’utilisation de l’ordinateur vs APIs structurées explique pourquoi la couche structurée doit rester la source de vérité.

Cas d’utilisation légitimes

Voici les contextes où l’utilisation de Maigret est généralement défendable, sous réserve du droit local et du cadre d’autorisation.

Récupération de comptes personnels

Vous pouvez scanner un ancien pseudonyme que vous avez utilisé pour retrouver des comptes oubliés.

Utile avant :

  • suppression d’empreinte numérique ;
  • audit de confidentialité ;
  • rotation d’identifiants ;
  • fermeture d’anciens comptes.

Surveillance d’abus de marque

Une entreprise peut vérifier si des comptes imitent :

  • son nom ;
  • ses produits ;
  • ses dirigeants ;
  • ses domaines ;
  • ses campagnes.

Cela aide les équipes sécurité, juridique et trust & safety à détecter l’usurpation.

Personnes disparues

Des organisations de recherche ou des bénévoles peuvent l’utiliser avec le consentement de la famille et en coordination avec les autorités. L’usage doit rester encadré : agir seul peut nuire à une enquête.

Red-team autorisée

Dans un engagement signé, Maigret peut aider à cartographier la surface d’attaque publique :

  • comptes exposés ;
  • pseudonymes liés à l’organisation ;
  • anciennes présences publiques ;
  • indices d’exposition externe.

Le contrat définit le périmètre. L’outil ne remplace pas l’autorisation.

Journalisme d’investigation

Les journalistes peuvent utiliser des outils OSINT dans des enquêtes sur la fraude, la corruption, la criminalité organisée ou des personnalités publiques, avec revue éditoriale et juridique.

Ce qui n’entre pas dans ces cas :

  • surveiller un ex-partenaire ;
  • rechercher un inconnu par curiosité ;
  • constituer une base de données sur des personnes sans consentement ;
  • harceler une personne à partir de ses traces publiques.

Modèles de Maigret à appliquer aux tests d’API

Voici les patterns directement transférables.

1. Décrire les comportements comme des données

Maigret ne code pas chaque site en dur. Il déclare les signatures.

Faites pareil pour vos APIs :

endpoint: GET /users/{id}
expected:
  status: 200
  requiredFields:
    - id
    - email
    - role
  forbiddenFields:
    - password
    - passwordHash
headers:
  required:
    - content-type
Enter fullscreen mode Exit fullscreen mode

Résultat : vous pouvez versionner, relire, comparer et mettre à jour les contrats sans réécrire tout le test runner.

2. Utiliser des assertions multi-signaux

Un statut 200 ne suffit pas.

Vérifiez au minimum :

  • statut HTTP ;
  • schéma JSON ;
  • champs obligatoires ;
  • champs interdits ;
  • types ;
  • valeurs métier ;
  • en-têtes ;
  • format d’erreur ;
  • compatibilité ascendante.

Exemple :

pm.test("contrat utilisateur", function () {
  const body = pm.response.json();

  pm.response.to.have.status(200);
  pm.expect(body.id).to.be.a("string");
  pm.expect(body.email).to.match(/^[^\s@]+@[^\s@]+\.[^\s@]+$/);
  pm.expect(body).to.not.have.property("passwordHash");
  pm.expect(pm.response.headers.get("content-type")).to.include("application/json");
});
Enter fullscreen mode Exit fullscreen mode

3. Centraliser et synchroniser les signatures

Maigret met à jour ses signatures depuis un dépôt central.

Pour vos APIs :

  • stockez les contrats dans un workspace partagé ;
  • synchronisez-les avec l’équipe ;
  • versionnez les changements ;
  • reliez-les à la documentation ;
  • exécutez-les dans la CI.

Les projets Apidog prennent en charge ce workflow cloud. Nous l’avons couvert dans Test d’API sans Postman.

image

4. Planifier une détection de dérive

Ne lancez pas vos tests uniquement avant une release.

Ajoutez une exécution périodique :

name: API Drift Detection

on:
  schedule:
    - cron: "0 * * * *"

jobs:
  test-api-contracts:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Run API contract tests
        run: npm run test:api
Enter fullscreen mode Exit fullscreen mode

Objectif : détecter qu’un fournisseur ou un service interne a changé avant que les utilisateurs ne le signalent.

5. Utiliser le LLM comme post-processeur

Le LLM peut résumer :

  • endpoints cassés ;
  • différences détectées ;
  • sévérité ;
  • impact probable ;
  • actions recommandées.

Mais la décision doit rester dans les tests.

Bon :
test déterministe → diff structuré → résumé IA

À éviter :
réponse brute → LLM → verdict
Enter fullscreen mode Exit fullscreen mode

Pièges courants avec Maigret

Si vous testez Maigret en local, surveillez ces erreurs.

Exécuter sans -a et supposer l’exhaustivité

Par défaut, Maigret ne scanne pas forcément toute la base. Pour couvrir la longue traîne :

maigret username -a
Enter fullscreen mode Exit fullscreen mode

Le scan sera plus long, mais plus complet.

Ignorer les tags

Le filtrage par tags permet de cibler une catégorie ou un pays :

maigret username --tags social
maigret username --tags jp
Enter fullscreen mode Exit fullscreen mode

Un utilisateur actif sur des plateformes régionales peut être manqué si vous restez sur un périmètre trop général.

Ne pas mettre à jour la base

Avant un scan important :

maigret --update
Enter fullscreen mode Exit fullscreen mode

Une signature obsolète produit rapidement des faux positifs ou faux négatifs.

Interpréter un blocage Tor comme un signal utilisateur

Certains sites bloquent Tor ou certains proxys. Ce blocage indique une politique du site, pas l’existence ou l’absence d’un compte.

Croire les champs extraits sans vérification

Une page publique peut contenir des informations fausses ou volontairement trompeuses. Traitez les résultats comme des pistes, pas comme des preuves.

Cas d’utilisation réels

Une société de conseil en sécurité utilise Maigret au début de chaque mission red-team autorisée. Le résultat alimente le rapport de cadrage pour montrer au client sa surface d’exposition publique avant les tests actifs.

Un enquêteur en fraude indépendant utilise --ai pour transformer un scan de plusieurs milliers de sites en synthèse courte destinée à des clients non techniques. La collecte reste déterministe ; le LLM ne sert qu’à rendre le rapport lisible.

Une équipe d’ingénierie applique les mêmes principes à 200 microservices : signatures d’endpoints, fixtures connues, relecture planifiée et alertes de dérive. L’implémentation se fait dans Apidog, mais l’architecture suit les leçons de Maigret.

Conclusion

Maigret est intéressant même si vous ne faites jamais d’OSINT. C’est un exemple concret d’outil qui survit à la dérive de milliers de surfaces externes grâce à une architecture déclarative et testable.

À retenir :

  • Maigret vérifie plus de 3 000 sites avec une base de signatures versionnée.
  • La détection multi-signal est plus fiable qu’un simple code HTTP.
  • La dérive est inévitable ; elle doit être détectée par relecture planifiée.
  • Le LLM est utile comme post-processeur, pas comme juge.
  • Les mêmes patterns s’appliquent directement aux tests d’API dans Apidog.

Prochaine étape : prenez un endpoint de votre projet, définissez sa signature attendue, ajoutez des assertions multi-signaux, enregistrez une fixture valide, puis planifiez une relecture régulière. Le jour où un champ sera renommé à 2 h du matin, votre suite le détectera avant vos utilisateurs.

FAQ

Est-ce que Maigret est légal à utiliser ?

Cela dépend de la juridiction, de la cible et du cadre d’autorisation. L’utiliser sur vous-même, sur des comptes que vous possédez, sur une organisation qui vous a donné une autorisation écrite ou dans un cadre journalistique validé est généralement plus défendable.

L’utiliser sur une personne non informée peut enfreindre les lois sur le harcèlement ou le stalking. Vérifiez toujours les règles locales.

Maigret fonctionne-t-il sans Python ?

Le package officiel cible Python 3.10+. L’auteur maintient aussi un bot Telegram pour des recherches occasionnelles et une configuration Cloud Shell pour éviter une installation locale.

Quelle est la précision de l’affirmation “plus de 3 000 sites” ?

La base de sites du dépôt contient plus de 3 000 entrées, mais toutes ne sont pas forcément actives à un instant donné. La mise à jour automatique et les contributions communautaires maintiennent un sous-ensemble fonctionnel. Les tags aident à limiter le scan aux sites pertinents.

À quoi sert le mode IA ?

Le drapeau --ai utilise un LLM compatible OpenAI pour résumer les résultats déterministes dans un rapport lisible. Il ne modifie pas la recherche et ne décide pas des correspondances. Vous devez fournir votre propre clé API.

Puis-je utiliser Maigret en CI ?

Pour des investigations OSINT, ce n’est généralement pas le bon modèle : le travail reste contextuel et interactif.

En revanche, les patterns de Maigret — signatures, fixtures, détection de dérive, relecture planifiée — sont exactement ceux à intégrer dans une CI de tests d’API. Apidog les implémente nativement.

En quoi Maigret diffère-t-il de Sherlock ?

Sherlock est l’outil plus ancien et plus simple. Maigret ajoute l’extraction d’informations, la recherche récursive, la gestion partielle des captchas, le résumé IA et une base de sites plus riche. Les deux sont sous licence MIT.

Où signaler une signature obsolète ?

Le README du dépôt Maigret renvoie vers les issues GitHub et les pull requests. Le modèle habituel est de proposer une PR ciblée pour le site concerné, avec une signature mise à jour et testable.

Top comments (0)