Je suis Head of IT dans une société financière en Suisse. Multi-sites, switches Cisco, firewalls Palo Alto, data center, systèmes de trading critiques, téléphonie, le quotidien d'une infra on-prem dans un environnement réglementé.

Depuis début 2026, j'utilise Claude AI (Anthropic) comme co-pilote pour gérer cette infrastructure. Pas un chatbot à qui je pose des questions. Un agent qui se connecte en SSH à mes équipements, lit les configs, audite, documente.

Voici ce que j'ai appris en 3 mois. Les résultats, les limites, et pourquoi je pense que chaque IT manager devrait s'y intéresser maintenant.

Le contexte : une petite équipe face à une infra qui ne dort jamais

Si vous gérez une infrastructure IT avec une équipe réduite, vous connaissez la réalité :

  • Des dizaines d'équipements réseau répartis sur plusieurs sites
  • Des firewalls, des VPNs, du stockage, de la virtualisation
  • Des systèmes critiques qui ne tolèrent pas de downtime
  • Et une liste de tâches qui grandit plus vite que vous ne pouvez la traiter
La documentation prend du retard. Les audits sont repoussés. Les risques s'accumulent en silence. Pas par incompétence, par manque de temps.

C'est là que l'IA est entrée dans mes opérations.

Le déclencheur : "Et si l'IA pouvait lire mes configs ?"

J'ai commencé par utiliser Claude Code (le CLI d'Anthropic) pour documenter du code. Puis j'ai réalisé que l'agent pouvait se connecter en SSH, lire des running configs, et les analyser.

J'ai créé un utilisateur dédié en lecture seule sur tous mes équipements :

  • Switches Cisco (NX-OS, IOS, IOS-XE) : show commands uniquement
  • Firewalls Palo Alto (Panorama) : role superreader
  • Stockage, serveurs : accès en lecture aux CLIs

Pas d'accès en écriture. Pas de configure terminal. Pas de modification possible. Lecture seule, audit seul.

Et là, tout a changé.

Résultat n°1 : Audit complet du parc switches, des dizaines de findings en une journée

Le premier vrai test a été un audit de sécurité sur l'ensemble de mes switches.

L'IA s'est connectée en SSH à chaque équipement, a récupéré la running config, et a analysé selon une grille standardisée :

  • Chiffrement des mots de passe
  • ACLs sur les lignes d'administration
  • Protocoles non sécurisés actifs (HTTP server, Telnet, CDP)
  • Spanning Tree protection (BPDU Guard, Root Guard)
  • Ports inutilisés ouverts
  • NTP, logging, bannières de connexion
  • Firmware et CVE connues
Résultat : plus d'une centaine de findings. Plusieurs critiques. En temps normal, cet audit m'aurait pris 2 à 3 semaines de travail fractionné. Avec l'IA, c'était bouclé en une journée, avec un rapport structuré par équipement, par sévérité, avec recommandations.

Les findings critiques étaient des choses que je savais quelque part dans ma tête, mais que je n'avais jamais formalisées :

  • Un switch avec le serveur HTTP encore actif
  • Des lignes d'administration sans ACL sur un site distant
  • Des firmwares avec des CVE connues non corrigées

Le rapport m'a forcé à les traiter. Documenter, c'est rendre visible.

Résultat n°2 : Documentation complète de l'infra, de zéro à un repo structuré

Avant l'IA, ma documentation était dispersée : des notes ici, des emails là, des configs sauvegardées manuellement, des schémas dans ma tête.

En quelques mois, j'ai constitué un repo Git unique avec une documentation structurée et générée depuis les configs réelles :

  • Inventaire complet : chaque switch, chaque port, chaque VLAN
  • Topologie réseau : schémas WAN en ASCII art
  • Analyse par équipement : documentation détaillée de chaque config (core, distribution, edge, DMZ)
  • Sécurité : tunnels VPN inventoriés, règles firewall documentées, politique d'accès
  • Par site : chaque bureau distant a sa propre section

Chaque fichier a été généré par l'IA après lecture directe de la config en production, puis validé par moi. Ce n'est pas de la documentation théorique, c'est le reflet exact de ce qui tourne en prod.

Quand un fournisseur pose une question, quand un auditeur demande un inventaire, quand je dois justifier un budget, tout est là, à jour, en Markdown, versionné dans Git.

Résultat n°3 : Audit stockage, diviser les findings par 3

Mon système de stockage (baie SAN, HA, iSCSI + CIFS) n'avait jamais été audité en profondeur depuis sa mise en service.

L'IA a analysé la configuration complète et a produit un rapport avec des dizaines de findings :

  • Configuration haute disponibilité incomplète
  • Alertes SNMP non routées
  • Volumes sans politique de snapshot
  • Comptes de service avec des droits excessifs

Après correction des points critiques, un second audit a divisé le nombre de findings par 3. Tous les restants : informatifs ou faible priorité.

Sans l'IA, cet audit n'aurait probablement jamais été fait. Pas par négligence, par manque de temps.

Résultat n°4 : Migration du monitoring vers une stack open source

Le monitoring est le domaine où l'IA a eu le plus d'impact structurel.

J'avais déjà une stack de monitoring complète, mais propriétaire. Le problème avec les solutions propriétaires, c'est que l'IA ne peut pas vraiment travailler avec : APIs fermées, documentation limitée, formats opaques. L'agent bute sur des interfaces qu'il ne peut ni lire ni automatiser.

Ça tombait bien. Je suis un expert des solutions open source depuis des années, et je cherchais une raison de migrer. L'IA m'a donné l'accélérateur qu'il me manquait.

En quelques semaines, j'ai déployé une stack 100% open source avec l'aide de l'IA :

  • Prometheus : collecte de métriques (ICMP, SNMP switches/firewalls/stockage)
  • Grafana : dashboards réseau, sécurité, stockage, compute
  • Loki : agrégation de logs centralisés
  • Wazuh SIEM : détection d'intrusion et compliance
  • Alertes : latence, disques, CPU, tunnels VPN down, certificats expirants
La différence avec l'ancienne stack : tout est en fichiers texte, tout est versionnable dans Git, tout est automatisable. L'IA peut lire une config Prometheus, proposer une nouvelle alerte, générer un dashboard Grafana en JSON, corriger une règle Wazuh. Avec une solution propriétaire, rien de tout ça n'est possible.

Chaque composant a été installé, configuré, testé, documenté. Chaque nouvelle machine ajoutée à l'infrastructure suit maintenant une checklist obligatoire : hardening, fail2ban, agent SIEM, collecte de logs, métriques, dashboard.

Une machine non monitorée est une machine invisible. L'IA m'a aidé à systématiser ce principe, et l'open source lui a donné les moyens de le faire.

Ce que l'IA ne peut PAS faire

Après 3 mois d'utilisation intensive, voici les limites réelles. Et elles sont importantes.

Elle ne prend pas de décisions business

L'IA peut me dire qu'un firmware a des CVE. Elle ne peut pas décider si le risque de mise à jour en production (downtime sur des systèmes critiques) est acceptable un mardi à 14h. C'est mon job.

Elle ne remplace pas l'expérience

Quand elle analyse une config et signale un "problème", il faut du contexte humain pour savoir si c'est un vrai problème ou un choix architectural volontaire. Désactiver certaines fonctionnalités de sécurité avancées peut être un choix délibéré, pas un oubli. L'IA ne peut pas savoir ça sans qu'on le lui dise.

Elle ne gère pas les relations humaines

Négocier avec un fournisseur, convaincre une direction d'investir dans l'infrastructure, gérer une équipe sous pression, ça reste 100% humain.

Elle peut se tromper

Elle peut mal interpréter une config, confondre un artefact legacy avec un problème actif, ou proposer une commande qui ne fonctionne pas sur une version spécifique d'un OS réseau. La relecture humaine est non négociable.

Elle a besoin de guardrails

J'ai configuré des accès en lecture seule partout. Pas d'écriture, pas de modification. Si l'IA pouvait exécuter des commandes de configuration sur un switch en production, le risque serait inacceptable. La confiance se construit incrémentalement.

Le vrai changement : passer de réactif à proactif

Le plus grand impact de l'IA dans mes opérations n'est pas la vitesse. C'est le changement de posture.

Avant, je passais la majorité de mon temps en mode réactif : incidents, demandes, urgences. La documentation, les audits, l'optimisation, tout ça était perpétuellement "pour plus tard".

Maintenant, avec un agent IA qui peut lire, analyser et documenter en parallèle de mon travail quotidien, j'arrive enfin à faire ce travail de fond :

  • Audits réguliers au lieu d'audits "quand j'ai le temps" (jamais)
  • Documentation à jour au lieu de notes éparses
  • Monitoring proactif au lieu de découvrir les problèmes quand ça tombe
  • Décisions informées au lieu d'intuitions non documentées

Pour une petite équipe IT qui gère une infrastructure multi-sites dans un environnement exigeant, c'est un multiplicateur de force.

Comment commencer (guide pratique)

Si vous êtes IT manager, sysadmin, ou ingénieur infra et que vous voulez explorer cette approche, voici la méthode que je recommande :

1. Commencez par la lecture seule

Créez un utilisateur dédié avec des droits minimaux sur vos équipements. show commands uniquement sur les switches. Role read-only sur vos firewalls. SNMP read-only. Construisez la confiance avant d'élargir les accès.

2. Commencez par la documentation

C'est le cas d'usage le plus safe et le plus immédiatement utile. Faites analyser vos running configs et générez de la documentation structurée. Vous allez découvrir des choses que vous aviez oubliées.

3. Passez aux audits

Une fois la documentation en place, utilisez l'IA pour auditer systématiquement : sécurité, compliance, best practices constructeur. Formalisez ce que vous savez intuitivement.

4. Déployez du monitoring

Utilisez l'IA pour déployer et configurer une stack de monitoring. Prometheus, Grafana, Wazuh, les outils sont open source et matures. L'IA accélère énormément la phase de configuration et de tuning des alertes.

5. Gardez le contrôle

L'IA est un outil, pas un collègue autonome. Relisez tout. Validez tout. Versionnez tout dans Git. Si vous ne comprenez pas ce que l'IA propose, ne l'appliquez pas.

Les outils que j'utilise

Pour ceux qui veulent reproduire cette approche :

  • Claude Code (Anthropic) : le CLI qui permet à l'IA de se connecter en SSH, lire des fichiers, exécuter des commandes. C'est le coeur du setup.
  • Git (Gitea self-hosted) : tout est versionné. La documentation, les configs rédigées, les rapports d'audit.
  • Prometheus + Grafana + Loki : monitoring open source, déployé sur des conteneurs Linux.
  • Wazuh : SIEM open source pour la détection et la compliance.

Le tout tourne sur de l'infrastructure self-hosted. Pas de données dans le cloud, pas de dépendance SaaS pour les opérations critiques. C'est un choix.

Conclusion

En 3 mois, l'IA m'a permis de :

  • Auditer l'ensemble de mon parc réseau et découvrir des findings critiques invisibles
  • Documenter toute l'infrastructure depuis les configs réelles, dans un repo Git structuré
  • Déployer une stack de monitoring complète (métriques, logs, SIEM, alertes)
  • Auditer mon stockage et diviser les findings par 3
  • Systématiser la sécurité avec des checklists obligatoires pour chaque nouvelle machine

Tout ça en continuant à gérer le quotidien d'une infrastructure multi-sites exigeante.

L'IA ne remplace pas l'IT manager. Elle lui rend le temps de faire son vrai travail : anticiper, structurer, sécuriser.

Si vous attendez que l'IA soit parfaite pour commencer, vous attendrez trop longtemps. Commencez petit, en lecture seule, sur un cas d'usage concret. Les résultats parlent d'eux-mêmes.