Comment ça marche
Totenvis est une seule installation qui connaît un parc informatique, le surveille, agit sur lui et prouve sa conformité, par elle-même. Un agent sur appareil et un pack de conformité l'étendent davantage. Les dix parties ci-dessous sont toutes construites et fonctionnent aujourd'hui. Cette page est tenue à jour avec la branche main du dépôt du produit — rien ci-dessous ne revendique plus que ce qui est réellement livré.
La plateforme
Pointez Totenvis vers un réseau et, par lui-même et sans rien ajouter, il trouve chaque actif accessible, surveille ce qui s'y passe, transforme ce qui ne va pas en un changement qu'un opérateur approuve, et prouve le résultat. Un appareil que rien ne peut atteindre directement se signale plutôt par l'agent, et l'installation s'enregistre auprès du portail de compte pour garder sa licence à jour — tout le reste ci-dessous fonctionne sans l'un ni l'autre.
Découverte
Totenvis balaie les sous-réseaux ciblés par des sondes ICMP et TCP, récolte les tables ARP, et parcourt le SNMP là où un identifiant en lecture seule est disponible — y compris les tables de voisinage LLDP et CDP, afin que les liens appareil à appareil apparaissent automatiquement. Chaque actif est stocké avec son IP, son adresse MAC, son nom d'hôte et ses dates de première et dernière observation. Quand la découverte est bloquée — un appareil qui ne répond pas, un identifiant manquant — Totenvis indique exactement où et propose ce qui la débloquerait.
Topologie
Une carte interactive, à disposition dynamique, est construite à partir de ce que la découverte trouve : actifs, sous-réseaux et liens entre eux. Zoomez, déplacez-vous, filtrez par site, VLAN ou type d'appareil, et ouvrez un panneau de détail pour n'importe quel élément de la carte.
Remédiation
Les lacunes de découverte se transforment en propositions avec preuves jointes, et fermer la boucle par une action sur un appareil est opérationnel : approuver une proposition crée un dossier de changement plutôt que de toucher l'appareil directement, et le pilote s'exécute quand la fenêtre planifiée de ce changement s'ouvre, le résultat étant vérifié au balayage suivant et consigné dans le journal d'audit. Le pilote actuel couvre une seule catégorie de correction — réactiver l'accès SNMP sur les appareils gérés par Meraki, la première vraie écriture du produit sur un appareil ; d'autres types d'appareils et de corrections restent sur la feuille de route, et la remédiation sur les appareils couverts par l'agent est prévue pour passer par l'extension agent ci-dessous.
Dossiers de changement
Approuver une proposition crée un changement, pas une action immédiate : l'onglet Propositions ne garde qu'Approuver et Rejeter, et le changement porte sa propre évaluation, son approbation et sa fenêtre planifiée. Un planificateur exécute le pilote quand cette fenêtre s'ouvre, ou un opérateur peut l'exécuter plus tôt depuis l'onglet Changements, qui liste chaque changement avec son état, sa fenêtre, son approbateur et son résultat. Le dossier vit dans Totenvis aujourd'hui, avec un connecteur ServiceNow pour faire passer le même changement par l'outil ITSM que vous utilisez déjà — construit, mais pas encore vérifié face à une instance réelle.
Incidents
Une proposition de découverte bloquante, un actif qui disparaît après son délai de grâce, ou un contrôleur qui échoue à son contrôle de santé peuvent chacun ouvrir un incident par la même frontière de dossier qu'un changement, et le refermer dès que la condition se dissipe. Les règles sont configurables par l'opérateur et désactivées par défaut, afin que le premier balayage d'une nouvelle installation n'inonde jamais une file de tickets.
Observabilité
Les mesures dans le temps arrivent en OpenTelemetry, depuis vos propres collecteurs et depuis l'agent, et un collecteur de flux lit le NetFlow directement depuis les exportateurs que votre réseau possède déjà — si bien que le trafic entre deux actifs se tient à côté du dossier de ce que sont ces actifs. La page d'un actif trace ses propres mesures sur la dernière heure ou journée ; la carte de topologie superpose l'utilisation des liens en direct sur chaque interface qu'elle peut mesurer ; et un hôte que rien n'a balayé apparaît sur la carte dès qu'il commence à exporter de la télémétrie, marqué comme trouvé de cette façon plutôt que par un balayage.
Comptes et rôles
Chaque installation démarre avec un seul utilisateur, un administrateur. Depuis un onglet Comptes, cet administrateur peut créer des comptes supplémentaires en opérateur ou visualiseur, changer le rôle de n'importe quel compte, et désactiver ou réactiver un utilisateur sans supprimer son dossier. Une protection empêche de retirer les droits d'administrateur au dernier administrateur restant, ou de le désactiver, afin qu'une installation ne puisse jamais être verrouillée hors de ses propres comptes. Il n'y a pas d'inscription en libre-service — un administrateur crée chaque compte.
Assistance
Un onglet Assistance permet à un opérateur de poser une question avec le contexte joint — l'écran, l'état de préparation de cette installation, la version — acheminée selon un réglage vers le fournisseur (clients gérés, via le flux d'inscription), le service d'assistance propre du client, ou une boîte aux lettres ; rien ne quitte l'installation avant qu'une voie ne soit définie. Un assistant IA, ancré dans la documentation propre du produit et l'état de cette installation, répond d'abord et passe la main à une personne selon la voie configurée, avec la transcription. L'agent sur l'appareil d'un utilisateur final propose la même première réponse avec le contexte propre de cet appareil ; demander une personne notifie immédiatement la voie, et quelqu'un sur l'installation peut répondre directement dans le chat depuis l'onglet Assistance — une transcription complète ne suit par la voie que si personne ne répond à temps. La voie boîte aux lettres est vérifiée sur le terrain de bout en bout, pour une demande soulevée comme pour un chat en direct d'un appareil, atteignant une adresse réelle sur l'installation du propriétaire ; les voies fournisseur et service d'assistance sont couvertes par les propres tests de leurs expéditeurs, pas encore un point réel.
Extensions
Deux éléments étendent la plateforme au-delà de ce qu'elle fait seule aujourd'hui. Les deux sont construits.
Agent sur appareil
Là où ouvrir un port n'est pas une option, un petit agent Totenvis s'exécute plutôt sur l'appareil — Windows, macOS ou Linux — et ne se connecte que vers l'extérieur. Il s'inscrit avec un jeton à usage unique, s'installe comme un service, et rapporte ce qu'est l'appareil et ce qu'il exécute. L'agent vient de votre propre installation Totenvis, pas d'un téléchargement public — Linux sous forme de commande d'installation silencieuse en une ligne ou de paquets .deb/.rpm, Windows sous forme d'assistant interactif qui demande l'adresse et le jeton d'inscription, vérifié sur le terrain en s'installant et en s'inscrivant sur un vrai PC Windows. Il porte aussi le chat en direct nommé sous Assistance ci-dessus. La remédiation sur les appareils couverts par l'agent est prévue, pas encore construite.
Pack de conformité
Le moteur d'évaluation recueille un instantané réel de l'installation — inventaire des actifs, coffre des identifiants, journal d'audit, dossiers de changement, rôles, couverture de l'agent — et le vérifie face à DORA, ISO 27001 et ITIL, 281 contrôles en tout, selon une planification quotidienne ou à la demande. Un contrôle en échec crée une proposition via le même moteur que tout autre constat, si bien que combler une lacune est un acte gouverné avec sa propre preuve, et un onglet Conformité affiche le verdict et l'historique de chaque contrôle avec un rapport Markdown ou PDF et un lot de preuves à exporter pour un auditeur. Aucun référentiel n'est évalué avant qu'un opérateur n'installe un pack. Totenvis évalue et prouve ; il ne certifie pas.