Agent IA pour les opérations IT : tickets internes, accès, monitoring et documentation

Le problème

Les opérations IT internes ne s'arrêtent jamais, mais l'équipe qui les traite si. Une analyse Jitbit portant sur environ 1 000 entreprises, régulièrement citée dans le secteur du support, situait en 2017 le volume moyen géré par un technicien à 21 tickets par jour, avec un temps de résolution moyen de 82 heures. Ce sont des données datées, présentées par leurs propres auteurs comme une base historique plutôt qu'une cible actuelle, à traiter comme un ordre de grandeur et non comme un chiffre à jour.

Sur le temps passé par ticket, Endsight, un prestataire de support managé, avance 63 minutes en moyenne sur ses propres 10 923 utilisateurs suivis pendant 12 mois. C'est une donnée interne à une seule entreprise, non vérifiée par un tiers : à considérer comme un indice, pas comme une norme du secteur.

Le point documenté le plus solide concerne les accès. Une recherche de Wing Security relayée par The Hacker News en 2024 estime que 63 % des entreprises comptent d'anciens salariés qui conservent un accès à des données de l'organisation, et 43 % à des dépôts de code sur GitHub ou GitLab. Chaque demande d'accès ou de révocation qui traîne dans une file de tickets internes est un candidat direct à ce genre de statistique.

Ce délai de traitement a une deuxième conséquence, moins visible que le risque de sécurité : la file de tickets elle-même devient illisible. Quand les demandes urgentes (un accès bloqué qui empêche de travailler) se mélangent aux demandes routinières (une question déjà répondue dix fois dans la base de connaissances), l'équipe IT passe autant de temps à trier qu'à résoudre. Une bonne partie de cette file ne devrait jamais atteindre un humain : c'est exactement le type de tri qu'un agent qui lit la documentation existante peut absorber avant que le ticket n'attende son tour.

Ce que fait l'agent, étape par étape

Un agent IA autonome dédié aux opérations IT tourne en continu, dans son propre environnement isolé, et surveille la file de tickets sans jamais dormir.

Il commence par catégoriser chaque ticket entrant dans Jira : question déjà connue, demande d'accès, incident technique. Pour les demandes déjà documentées, il répond directement en citant la procédure trouvée dans la base Notion de l'équipe. Pour une demande d'accès à un outil ou un dépôt, il ouvre un ticket structuré avec toutes les informations nécessaires à la décision, plutôt que de l'exécuter lui même.

Côté monitoring, l'agent surveille les alertes remontées par Datadog et les corrèle avec les commits ou déploiements récents visibles dans GitHub : une hausse de latence qui suit de près un déploiement n'est pas traitée comme un incident isolé. Quand la corrélation est nette, il ouvre une issue GitHub documentée, avec le contexte utile pour l'équipe technique. Tout ticket resté bloqué, toute alerte critique ou toute demande d'accès en attente déclenche une notification Slack vers l'équipe IT. Chaque action, ticket créé, alerte corrélée, message envoyé, est journalisée dans la timeline de l'agent, avec son statut exact.

Un exemple concret illustre bien la mécanique : un employé ouvre un ticket un vendredi soir pour demander l'accès à un dépôt GitHub précis, dans le cadre d'un projet transverse. L'agent catégorise la demande, vérifie qu'elle est complète (dépôt visé, justification, durée souhaitée), puis prépare un ticket structuré prêt à être validé par un responsable IT dès le lundi matin, plutôt que de laisser la demande dormir dans une file générique jusqu'à ce que quelqu'un la remarque par hasard.

Les intégrations mobilisées

Jira reste la file de référence des tickets internes. L'agent y recherche les demandes (search_issues), consulte le détail (get_issue) et peut créer une nouvelle issue structurée, selon les actions couvertes par son grant.

GitHub sert à corréler une alerte technique avec un changement de code : liste des commits récents (list_commits), détail d'une pull request (get_pull_request), et création d'une issue documentée (create_issue) quand la corrélation est établie.

Datadog fournit le signal brut de supervision, que l'agent consulte sans jamais remplacer l'outil de monitoring lui même. Notion héberge les procédures et runbooks que l'agent consulte avant de répondre à une demande, et Slack porte les notifications à l'équipe IT en temps réel.

Ce qui reste à l'humain

L'agent prépare et alerte, il n'exécute jamais un changement d'accès ou d'infrastructure de sa propre initiative. Accorder ou révoquer effectivement un accès reste une action humaine : l'agent ouvre la demande documentée dans Jira, une personne de l'IT l'exécute et la referme.

La criticité réelle d'une alerte ambiguë, celle qui ne correspond à aucun déploiement récent identifiable, est tranchée par un humain avant toute escalade au delà d'une notification Slack. Décider et appliquer un correctif de code ou d'infrastructure reste, sans surprise, un travail d'ingénieur. Et comme pour tout agent Atako, un admin doit accorder et ajuster les grants sur Jira, GitHub et Datadog, action par action, avec une portée lecture ou lecture et écriture définie explicitement.

Cette limite vaut aussi pour l'agent lui-même : s'il tombe sur une situation qui sort de ce que son contexte métier couvre, un renouvellement de licence inhabituel, une demande d'accès à un système non documenté, il ne force pas une réponse approximative. Il notifie l'équipe IT et laisse le ticket ouvert pour un traitement humain, plutôt que de deviner une procédure qui n'existe pas dans sa base de connaissances.

Résultat mesurable

Le bénéfice le plus direct est la réduction du temps mort entre l'arrivée d'un ticket ou d'une alerte et sa première prise en charge. Un agent qui tourne 24 heures sur 24 peut catégoriser un ticket ouvert un dimanche soir et préparer la demande d'accès correspondante avant l'arrivée de l'équipe le lundi, plutôt que de laisser la demande attendre dans la file.

Le deuxième bénéfice touche directement le problème documenté par Wing Security : en systématisant l'ouverture d'un ticket de révocation dès qu'un départ est signalé, l'agent réduit le délai entre l'événement déclencheur et l'action de l'IT, ce qui limite la fenêtre pendant laquelle un accès reste actif inutilement, une fenêtre qui, sans surveillance continue, peut s'étirer sur des semaines voire des mois selon les constats cités plus haut.

Chaque ticket ouvert, chaque alerte corrélée, chaque message envoyé reste consultable dans l'audit trail d'Atako, exportable en CSV pour l'équipe IT jusqu'à 50 000 lignes. Cette traçabilité complète facilite aussi les audits de sécurité internes : retrouver qui a demandé un accès, quand, et sur quelle base la demande a été formalisée ne nécessite plus de reconstituer une chronologie à partir de plusieurs outils différents.

Un agent IT s'inscrit dans le plan Standard, 20 euros par mois et par slot, avec 1 000 crédits inclus chaque mois pour couvrir les appels au modèle. Le nombre de tickets traités ou de collaborateurs qui interagissent avec l'agent n'a aucun impact sur ce prix, seul le nombre d'agents actifs en simultané compte. Une équipe IT réduite peut ainsi faire tourner un seul agent sur l'ensemble de ses tickets internes, ses alertes de monitoring et ses demandes d'accès, sans avoir à multiplier les slots pour couvrir chaque flux séparément, ce qui garde le coût prévisible même quand le périmètre de l'agent s'élargit progressivement à de nouveaux outils ou de nouvelles équipes internes au fil des mois.