Bonjour à la communauté,

En tant que technicien réseau / infrastructure, je travaille depuis plusieurs mois sur un prototype d'outil matériel pensé pour les interventions terrain, les audits d'entrée chez de nouveaux clients et les visites de maintenance : le projet **AZZDING**.

### Le constat de départ :
Quand on intervient sur un site PME / collectivité sans documentation :
1. On n'a pas toujours la possibilité d'installer des agents lourds (RMM) sur tous les postes dès le premier jour.
2. Beaucoup de clients refusent (ou la politique de sécurité interdit) d'envoyer la cartographie et les données réseau sur un Cloud tiers américain.
3. Les outils gratuits (AngryIP, etc.) donnent une liste brute d'adresses IP mais n'ont aucune mémoire métier d'une visite à l'autre (ex: savoir si le NAS de sauvegarde ou la caméra IP présente le mois dernier a disparu).

### Ce que fait le prototype :
C'est un boîtier physique autonome (sur base mini-PC HP ProDesk / Linux) qu'on branche simplement en RJ45 sur le réseau local :
- **Scan passif / découverte sans agent** : cartographie des hôtes, baux, latence, ports et services ouverts.
- **Qualification métier** : possibilité d'associer un rôle réel aux équipements (ex: "NAS Sauvegardes Compta", "Passerelle Fibre").
- **Mémoire par client & différentiel** : compare le scan du jour avec la référence validée du client pour alerter immédiatement sur les équipements critiques disparus, ajoutés ou modifiés.
- **Rapport Dirigeant PDF** : génération en 1 clic d'un rapport exécutif clair avec score de santé pour valoriser l'intervention auprès du client final.
- **IA embarquée 100% locale** : un modèle LLaMA 3.2 (via Ollama en local) tourne directement sur la machine pour analyser les tendances d'obsolescence et proposer des préconisations, sans aucune connexion Internet requise.

### Stack technique sous le capot :
- OS : Linux Mint / Docker Compose (5 conteneurs isolés)
- Backend : FastAPI (Python) + PostgreSQL (pgvector)
- Frontend : React + Vite + Nginx
- Scanner : moteur Python utilisant Nmap via subprocess & parsing XML
- IA : Ollama local (aucun appel API externe)

---

### 🎥 Démonstration vidéo (6 min en conditions réelles) :
J'ai filmé le fonctionnement complet du prototype sur un réseau de test :
👉 **Lien de la vidéo :**

*(Démonstration chapitrée, n'hésitez pas à sauter directement aux passages qui vous parlent).*

---

### Mes questions pour vous :
Je suis actuellement en **phase de validation terrain du concept** (strictement aucune vente ni commercialisation à ce stade, je cherche à confronter l'outil à vos réalités de terrain) :

1. Est-ce qu'un tel boîtier autonome vous ferait gagner du temps lors d'un premier audit chez un prospect ou d'un contrôle trimestriel ?
2. Quelle fonctionnalité essentielle manque selon vous pour que ce soit réellement utile au quotidien (SNMP, scan Wi-Fi, détection de failles spécifiques...) ?
3. Que pensez-vous du positionnement 100% local / sans cloud face aux solutions SaaS du marché ?

Merci d'avance pour vos retours et vos critiques constructives (même les plus dures, c'est ce qui m'aidera à progresser) !

    Merci beaucoup pour ton retour et pour cette question qui tape en plein dans le mille !

    Tu as parfaitement cerné le sujet : la cible principale n'est pas la DSI d'une grande entreprise qui dispose déjà d'un Active Directory complet, d'un inventaire centralisé et d'outils de supervision en place.

    La valise s'adresse précisément à ceux qui interviennent sur des parcs qu'ils n'administrent pas au quotidien ou dont la documentation est inexistante :

        Les prestataires informatiques / MSP en phase d'audit d'entrée (Avant-vente / Onboarding) :
        Quand un technicien arrive chez un nouveau prospect ou client PME (10 à 50 postes), il ne peut pas installer d'agents logiciels partout sans contrat ni identifiants. La valise permet en 5 minutes de cartographier le parc, repérer les équipements critiques et générer un rapport PDF propre pour justifier les préconisations.

        Les visites de maintenance récurrentes chez les PME / TPE / Mairies :
        Pour les petits clients qui n'ont pas de contrat de télésurveillance 24/7, le prestataire passe une fois par mois ou par trimestre. La valise garde la « mémoire » de chaque client et lui dit immédiatement : « Attention, le NAS de sauvegarde ou la caméra IP présente lors de ta visite du 10 juillet ne répond plus aujourd'hui ».

        Les environnements fermés ou sensibles (Zéro Cloud) :
        Les sites industriels, cabinets médicaux, notaires ou collectivités qui refusent (ou dont les règles interdisent) d'envoyer la cartographie de leur réseau vers un Cloud tiers. Tout reste confiné dans le boîtier.

    Est-ce que ce type de cas d'usage te paraît cohérent avec ce que tu observes sur le terrain ? Selon toi, y a-t-il d'autres profils d'intervenants auxquels cela pourrait servir ?

    C'est une excellente observation, et c'est exactement la réalité du terrain : la grande majorité des TPE/artisans/professions libérales fonctionnent au « coup par coup » (dépannage sur sollicitation quand un problème survient).

    Et paradoxalement, c'est souvent dans ce mode « pompier » que le technicien perd le plus de temps :

        Il arrive sur un site qu'il n'a pas vu depuis 6 mois ou un an.
        Le client lui dit juste "Internet est lent" ou "On ne trouve plus le dossier partagé".
        Le technicien n'a aucune doc sous la main.

    En branchant la valise, en 2 minutes il voit immédiatement l'état du réseau, les IP actives, et si un équipement clé (box, routeur, NAS) a changé d'adresse ou ne répond plus.

    Tu as totalement raison sur le côté marché de niche : l'idée est justement de rester sur un outil très ciblé pour les indépendants et petites structures d'infogérance, sans chercher à concurrencer les usines à gaz du marché.

    Tu évoques la possibilité d'autres usages : qu'est-ce qui te viendrait spontanément à l'esprit ? (De l'audit de câblage/baie, de l'événementiel, de la domotique/IoT, des collectivités, du diagnostic de bornes Wi-Fi... ?)

    Ton regard m'intéresse beaucoup !

Salut et un immense merci pour ce retour cash et sans filtre ! C'est exactement le genre de regard terrain dont j'ai besoin.

Ton point de vue de FAI gérant les abus apporte une vraie plus-value : tu vois passer quotidiennement les conséquences réelles (Exchange non patché, Fortigate/Mikrotik avec failles VPN connues, machines zombies).

Tu touches du doigt le dilemme central de ce projet :

    La règle d'or actuelle (Zéro casse en production) :
    L'outil est pensé pour des techniciens de maintenance généralistes qui interviennent en journée chez des PME (souvent sans contrat de pentest formalisé et sur des réseaux fragiles). L'empoisonnement ARP / MITM ou l'exploitation active d'une vulnérabilité comporte un risque réel de faire tomber la téléphonie VoIP, de saturer de vieux switchs ou de planter des équipements industriels/médicaux. La règle a donc été : observer passivement et analyser, sans jamais perturber la production.

    Là où tu as 100% raison (Aller plus loin dans l'audit de vulnérabilités) :
    Pour que le technicien apporte une valeur décisive au dirigeant, la valise ne doit pas juste dire « qui est là », mais « quelles sont les portes grandes ouvertes ».

C'est clairement l'évolution logique du produit sur le volet audit :

    Scanner les versions/bannières des routeurs & firewalls pour alerter sur les CVE critiques connues (ex: firmware Mikrotik/Fortinet obsolète).

    Détecter les partages SMB/NFS ouverts à tout vent sans authentification.

    Vérifier les protocoles dangereux actifs (SMBv1, Telnet, HTTP en clair sur des interfaces d'administration).

    Tester les mots de passe constructeurs par défaut (admin/admin) sur les caméras, imprimantes et switchs.

    L'approche « Score avant / après » :
    Ton idée de valorisation est excellente : permettre au prestataire de montrer un score de risque avant intervention, corriger les failles (fermer les ports, patcher le routeur), et sortir un rapport PDF d'intégrité validant que le réseau est assaini.

En tant que gestionnaire Abuse, si tu devais isoler les 3 vérifications non-destructives indispensables que tu rêverais de voir automatisées sur un boîtier d'audit PME, ce serait lesquelles en priorité ?

Merci encore pour cette franchise qui fait avancer le projet !

C'est une remarque absolument brillante, et tu mets le doigt sur ce qui est sans doute le plus gros angle mort de sécurité des PME aujourd'hui.

Dans l'esprit de 90 % des petites structures (et même de beaucoup de techniciens), le NAT IPv4 fait office de bouclier par défaut (« on est en 192.168.x.x, donc personne ne peut nous joindre de l'extérieur »).

Mais avec l'IPv6 :

    Par le jeu du SLAAC / DHCPv6, le moindre équipement (du PC compta à la caméra de surveillance en passant par la régulation des groupes froids) se voit attribuer une adresse IPv6 publique mondiale.
    Si le pare-feu IPv6 de la box/passerelle est mal configuré (ou inexistant/désactivé par défaut chez certains opérateurs), l'équipement devient directement attaquable depuis n'importe où sur Internet, sans qu'aucun port n'ait été ouvert manuellement. L'exemple de l'attaque sur les supermarchés que tu cites illustre dramatiquement ce risque.

Intégrer un module de Diagnostic & Fuite IPv6 dans la valise fait un sens énorme et reste parfaitement dans la philosophie de l'outil (100 % passif et non destructif) :

    Détection des annonces de routeur (Router Advertisements) : écouter si le réseau local distribue du SLAAC IPv6 à l'insu de l'administrateur.
    Cartographie des adresses IPv6 publiques (GUA) : lister les hôtes disposant d'une IPv6 publique active vs Link-Local (fe80:.
    Test d'étanchéité du pare-feu IPv6 : vérifier si la passerelle bloque bien le trafic entrant non sollicité.
    Alerte dans le rapport PDF : donner au prestataire un indicateur clair : « IPv6 actif et non filtré : X équipements exposés sur le WAN ».

C'est typiquement le genre d'alerte à haute valeur ajoutée qu'un chef d'entreprise ou un prestataire ne verrait jamais avec un simple scanner IPv4 standard.

Merci beaucoup pour cette piste concrète et ces exemples parlants (le coup du Starlink en avion est excellent) !

Merci pour ce retour très concret, c'est exactement le type d'avis que je cherche.

Tu as raison sur le point juridique et OT. Je précise : je suis en phase de validation, sans commercialisation. Je ne vise pas aujourd'hui les réseaux industriels, automates ou environnements critiques. Ma cible de travail est le réseau bureautique TPE/PME peu documenté, sur autorisation, en lecture seule.

Mon passage sur les environnements "zéro cloud" était trop large. Le fait de ne pas envoyer vers un cloud tiers ne règle ni la preuve de non-copie, ni le chiffrement, ni la traçabilité, ni le risque d'impact d'un scan. Je ne veux pas survendre ce point.

Sur la méthodologie, c'est noté comme chantier obligatoire avant toute utilisation élargie : documenter exactement ce qui est émis, vers quelles IP, avec quels protocoles, avec quelle intensité, et prévoir un mode prudent : périmètre limité, pas de routage au-delà du segment direct, options réduites type ICMP uniquement, débit limité, fonctions désactivables. Et surtout : pas de test d'intrusion automatique caché.

Ton chiffre des 95% d'outils légitimes mal configurés qui déclenchent des alertes me parle beaucoup. Pour éviter ça, AZZDING devra être identifiable, prévisible et documenté, pas "un scan de plus non expliqué".

Si tu devais me donner une seule exigence minimale pour qu'un tel boîtier soit acceptable côté exploitation cyber, ce serait quoi en priorité : autorisation écrite standardisée, journal technique complet, mode scan à intensité réglable, ou garantie de maîtrise des données ?