Gérer un parc de clients infogérés, c'est un équilibre permanent entre réactivité et charge opérationnelle. L'intelligence artificielle change la donne à condition de savoir où la placer dans le processus.
Chaque site hébergé génère des logs : accès, erreurs, tentatives d'intrusion, pics de trafic. Multipliez ça par des dizaines de clients répartis sur plusieurs pays francophones et sur plusieurs infrastructures d'hébergement différentes et vous obtenez un volume de données qu'aucune équipe humaine ne peut lire ligne par ligne chaque jour.
Chez CYRITECH, une partie de notre parc client est hébergée chez des prestataires comme LWS, qui exposent leurs logs (accès, erreurs, API) via cPanel et une API dédiée. La donnée brute est disponible — mais la donnée brute n'est pas une information exploitable. C'est là que l'intelligence artificielle change la donne.
Ce constat ne concerne pas que l'hébergement web classique. Il s'étend à tout ce que notre unité ITSEC surveille au quotidien : accès aux applications métier, comportements réseau, journaux d'authentification. Le volume de bruit à filtrer est le même partout.
Avant, la routine ressemblait à ceci :
Ce processus fonctionne… jusqu'à ce que le nombre de clients dépasse ce qu'une personne peut raisonnablement surveiller. Le risque n'est pas seulement la perte de temps : c'est l'incident qui passe inaperçu jusqu'à ce que le client appelle, en colère, parce que son site est down depuis deux heures. Et plus grave encore : c'est le signal faible de sécurité — une tentative d'intrusion lente et discrète qui se noie dans le volume et n'est jamais détecté à temps.
Nous avons construit un pipeline qui vient s'intercaler entre les logs bruts et nos équipes techniques :
Les logs d'accès et d'erreurs sont récupérés régulièrement depuis les comptes de chaque client, sans intervention manuelle.
Un modèle passe les logs au crible pour distinguer le signal du bruit : erreurs serveur (5xx), comportements de bots agressifs, tentatives d'intrusion, chutes de performance, pics de trafic anormaux. Le trafic normal et les 404 mineurs sont filtrés et ne remontent jamais à un humain.
Toutes les anomalies ne se valent pas. Un ralentissement mineur chez un client standard n'a pas le même poids qu'une chute de disponibilité chez un client sous SLA renforcé.
Le ticket arrive déjà structuré dans notre portail Dolibarr : contexte, extrait de logs pertinent, hypothèse de cause probable. Le technicien valide et agit.
Les rapports mensuels d'infogérance incidents, disponibilité, actions correctives sont générés à partir des données déjà analysées.
LWS sert d'exemple concret dans cet article, mais le principe n'est pas propre à un hébergeur en particulier. Le portefeuille infogéré de CYRITECH couvre des environnements variés hébergement mutualisé, VPS, infrastructures dédiées chacun avec son propre format de logs et son propre niveau d'exposition aux API.
Chaque hébergeur structure ses logs différemment. La première étape technique consiste à ramener ces formats hétérogènes vers un schéma commun avant analyse.
Quel que soit l'hébergeur d'origine, les anomalies remontent au même endroit : le portail Dolibarr, avec la même logique de priorisation.
Le CEO ou le référent ITSEC obtient une vue d'ensemble du portefeuille infogéré, indépendamment de la diversité des infrastructures sous-jacentes.
L'onboarding d'un nouveau client quel que soit son hébergeur suit le même schéma d'intégration, sans réinventer le pipeline à chaque fois.
Le gain de temps est une chose. Le gain en couverture de sécurité en est une autre, tout aussi importante pour une unité ITSEC :
Le gain de temps ne se mesure pas en « lire les logs plus vite ». Il se mesure ailleurs :
Sur la base d'un client infogéré type (parc moyen, ≈4 incidents/mois) :
| Tâche | Avant IA | Après IA | Gain / mois |
|---|---|---|---|
| Surveillance quotidienne des logs | 15 min/jour → 5,5 h/mois | 5 min/jour (digest trié) → 1,8 h/mois | ~3,7 h |
| Triage & rédaction ticket | 20 min/incident → 1,3 h/mois | 10 min/incident (ticket pré-rédigé) → 0,7 h/mois | ~0,6 h |
| Reporting mensuel client | 90 min/mois | 15 min/mois (relecture du rapport auto-généré) | ~1,25 h |
| Total | ~8,3 h/mois/client | ~2,7 h/mois/client | ~5,6 h (≈ 68 %) |
Sur un portefeuille de 30 clients infogérés, ça représente environ 168 heures/mois récupérées à l'échelle du portefeuille l'équivalent d'un temps plein technique libéré chaque mois.
Voici comment les logs circulent jusqu'à l'action, avec la bifurcation critique/normal qui explique l'essentiel du gain de temps ci-dessus :
C'est la branche « trafic normal » qui économise le plus de temps : le technicien ne la voit jamais passer.
Un client e-commerce infogéré subit un afflux inhabituel de requêtes sur sa page de connexion, réparties sur trois jours à raison de quelques tentatives par heure trop discret pour déclencher une alerte de disponibilité classique, trop irrégulier pour être repéré lors d'un contrôle visuel quotidien.
L'analyse IA identifie le pattern (adresses IP variées, même chemin ciblé, cadence anormale pour ce client) dès le deuxième jour, génère un ticket Dolibarr avec l'extrait de logs concerné et une hypothèse de tentative de credential stuffing, et alerte le référent ITSEC. La mise en place d'un blocage ciblé intervient avant tout incident visible côté client.
Sans ce filtrage, ce type de signal aurait probablement été noyé dans le volume jusqu'à la revue mensuelle voire jamais détecté.
Pour une entreprise de cybersécurité et de cloud souverain comme CYRITECH, la vitesse de détection et de réponse n'est pas un confort opérationnel : c'est un argument commercial. Un client qui sait que ses logs sont surveillés en continu par un système capable de détecter une anomalie avant lui a une confiance différente dans son prestataire.
Et sur le plan interne, chaque heure que l'IA récupère sur la lecture de logs est une heure réinvestie sur des sujets à plus forte valeur : accompagnement client, déploiements Dolibarr, conformité fiscale, ou développement de nouveaux modules.
Ce pipeline continue d'évoluer. Les prochaines étapes chez CYRITECH : affiner la détection des bots IA (GPTBot, PerplexityBot et consorts) dans les logs, étendre la normalisation multi-hébergeurs à l'ensemble du parc, et pousser l'automatisation encore plus loin sur la corrélation inter-clients repérer, par exemple, si une même IP malveillante frappe plusieurs comptes hébergés simultanément, quel que soit leur hébergeur.
L'infogérance ne consiste plus à surveiller des logs. Elle consiste à surveiller ce que l'IA a déjà trié pour vous.
Vous gérez un parc de sites ou d'applications et voulez évaluer votre exposition réelle ?
Découvrir CYRITECH ITSEC Business UnitCYRITECH accompagne les entreprises tant en Afrique qu'enb europe dans leur transformation digitale, la cybersécurité et le cloud souverain. CYRITECH ITSEC Business Unit