Automatiser la création de tickets ITSM dans NinjaOne avec une IA locale et du RAG

📋 Le problème : du travail réel, mais invisible

Une grande partie du travail informatique commence hors de l'outil ITSM : discussion avec un utilisateur, lecture d'un journal, analyse d'un script, échange avec une IA de développement ou constat fait pendant une intervention. Sans discipline, les sujets courts restent dans une conversation, les améliorations attendent « quand on aura le temps » et les décisions ne laissent aucune trace exploitable.

Créer manuellement un ticket pour chaque constat résout la traçabilité, mais ajoute une friction. Le risque est alors de choisir entre deux mauvaises options : documenter parfaitement au prix d'une lourdeur quotidienne, ou aller vite en perdant le suivi.

🧩 L'architecture : découpler chaque responsabilité

Le système est volontairement composé de petites briques. L'émetteur décrit le besoin ; un seul composant connaît l'API ITSM ; le calendrier organise le temps ; l'IA locale prépare le dossier. Cette séparation réduit les secrets distribués et permet de désactiver une fonction sans arrêter toute la chaîne.

Le flux général est le suivant :

1. une discussion ou un outil produit un fichier de demande ;
2. une tâche planifiée relève les nouvelles demandes ;
3. le validateur contrôle le format, la référence, les catégories et les doublons ;
4. le synchroniseur crée le ticket avec l'API NinjaOne ou ajoute un commentaire au ticket existant ;
5. les demandes éligibles au quick win reçoivent un créneau de traitement ;
6. une autre tâche prépare un prédiagnostic local à partir des sources autorisées ;
7. le technicien relit, corrige et décide de l'action.

🎫 Créer et suivre les tickets avec l'API NinjaOne

La documentation publique NinjaOne expose des opérations dédiées au ticketing, dont la création d'un ticket, l'ajout d'un commentaire, la lecture d'un ticket, les formulaires, les contacts, les statuts et les tableaux de tickets. L'authentification repose sur OAuth 2.0 et doit être configurée dans l'administration NinjaOne.

Dans cette architecture, un seul synchroniseur porte cette complexité. Les autres programmes n'ont pas besoin de connaître l'URL régionale de l'instance, les identifiants internes des formulaires ou les jetons OAuth. Ils déposent une demande locale ; le synchroniseur traduit ensuite les libellés métiers vers les identifiants attendus par l'API.

Un contrat de dépôt simple

---
ref: SUPERVISION-EXEMPLE-001
titre: "[Application] - Contrôle à effectuer"
priorite: moyenne
domaine: Alerte / Supervision
categorie: Applications métier
source: AssistantTechnique
---

## Constat

Décrire le symptôme observé, son contexte et son impact.

## Action attendue

Vérifier la cause et proposer le traitement adapté.

La référence sert de clé d'idempotence : rejouer le même fichier ne doit jamais créer un deuxième ticket. Une nouvelle information devient une entrée de suivi, publiée comme commentaire. Cette règle est plus sûre qu'une mise à jour complète du ticket, car elle évite d'écraser une assignation ou un changement effectué entre-temps par un technicien.

💬 Quand une discussion technique devient un suivi ITSM

Dans mon usage, une session avec un assistant de développement peut faire émerger une anomalie, une dette technique ou une amélioration. Au lieu de laisser cette information dans l'historique de la conversation, l'assistant rédige le fichier de dépôt selon la convention du service informatique.

Ce point est important : l'assistant ne parle jamais directement à NinjaOne. Il n'a ni secret OAuth, ni droit d'écriture dans l'ITSM. Il produit une proposition structurée dans une zone surveillée. Le synchroniseur applique ensuite les règles déterministes :

• titre court et compréhensible dans une liste ;
• référence unique et stable ;
• catégorie issue du formulaire réel ;
• recherche de tickets ou de fichiers proches ;
• plafond de créations par passage ;
• journalisation des acceptations, avertissements et refus.

Le bénéfice dépasse la création automatique : le travail réalisé avec l'IA entre dans le même système de suivi que les demandes utilisateurs, les alertes et les projets. Il devient visible, attribuable et planifiable.

📅 Le quick win : réserver automatiquement du temps

Un ticket bien écrit n'est pas encore un ticket traité. Pour les actions courtes et peu risquées, le système peut créer ou proposer un rendez-vous calendrier relié au ticket. C'est particulièrement utile pour les tâches qui prennent quinze à trente minutes mais restent repoussées pendant plusieurs semaines.

La qualification « quick win » doit rester bornée par des critères explicites :

• action réversible ou sans impact de production ;
• durée estimée courte ;
• contexte et résultat attendu déjà connus ;
• aucune dépendance à une validation externe ;
• créneau limité et déplaçable par le technicien.

Le rendez-vous contient le numéro et le lien du ticket, l'objectif du créneau et la définition de fini. Il ne déclenche pas automatiquement la clôture : il réserve du temps. Le technicien reste libre de déplacer le rendez-vous, d'escalader le sujet ou de requalifier l'estimation.

🧠 Prétraiter les tickets avec une IA locale et du RAG

Une tâche planifiée peut périodiquement sélectionner les tickets en attente de préparation. Le contenu est nettoyé, limité au strict nécessaire puis transmis à un modèle exécuté localement. Le RAG — génération augmentée par recherche — ajoute les fragments pertinents issus d'un corpus autorisé : procédures, documentation interne, historiques techniques assainis ou fiches d'exploitation.

Le résultat est un brouillon technique, pas une décision. S'il est utile, il peut être ajouté comme note privée ou présenté au technicien avant publication. Les sources récupérées doivent être visibles pour permettre une vérification rapide.

🗄️ Connecter l'IA à des bases de test sans ouvrir le système d'information

Le caractère local du modèle ne suffit pas à sécuriser l'accès aux données. Une IA locale reste un logiciel capable de produire une requête incorrecte ou trop large. L'accès aux bases doit donc être conçu comme celui de n'importe quel composant non fiable.

Dans mon environnement, les expérimentations se font sur des bases de test et dans un périmètre réseau cloisonné. Les principes publiables — sans exposer la cartographie réelle — sont les suivants :

• réseau ou VLAN dédié pour le service d'IA ;
• filtrage explicite par source, destination, port et service ;
• compte de base de données dédié, en lecture seule chaque fois que possible ;
• accès à des vues ou copies de test plutôt qu'aux tables de production ;
• limite de durée, de volume et de complexité des requêtes ;
• journalisation des connexions et des requêtes exécutées ;
• absence de secrets dans les prompts, les tickets et les journaux du modèle.

🛡️ Les garde-fous qui rendent l'automatisation exploitable

La supervision du système doit aussi être indépendante de la chaîne qu'elle contrôle. Un synchroniseur en panne ne peut pas ouvrir son propre ticket si son jeton est expiré. Il lui faut donc au minimum un journal local, un code de sortie surveillé et une alerte passant par un canal distinct.

🚀 Une trajectoire réaliste pour une PME

Pour une PME autour de Montchanin, du Creusot ou de Montceau-les-Mines, il n'est pas nécessaire de déployer toute l'architecture en une fois. Le meilleur ordre est celui qui produit une preuve rapidement tout en gardant le risque bas.

1. Structurer les demandes. Définir le titre, la priorité, la catégorie, la source et le résultat attendu.
2. Automatiser un seul émetteur. Par exemple une alerte de supervision ou un compte rendu technique.
3. Fiabiliser l'idempotence. Vérifier qu'un rejeu, un doublon ou une panne réseau ne crée pas de bruit.
4. Ajouter le calendrier. Réserver quelques créneaux quick win et mesurer s'ils sont réellement utilisés.
5. Introduire le RAG local. Commencer par un corpus court, versionné et explicitement autorisé.
6. Ouvrir une base de test. Seulement après avoir défini le compte, les vues, les limites et les journaux.

🔗 Sources techniques

• NinjaOne Public API 2.0 — opérations de ticketing ;
• NinjaOne — configuration des jetons OAuth ;
• NinjaOne — utilisation de l'API publique ;
• NinjaOne — référence de création d'un ticket.

NinjaOne est une marque de son propriétaire. FAC6 n'est pas affilié à NinjaOne. Les comportements présentés comme retours d'expérience ont été observés sur un environnement donné le 25 août 2026 ; ils ne remplacent pas la documentation de l'éditeur ni un test sur votre propre instance.

❓ Questions fréquentes

Peut-on créer automatiquement un ticket dans NinjaOne ?

Oui. L'API publique propose une opération de création de ticket. Une intégration fiable doit également gérer OAuth, les formulaires, les contacts, les doublons, les erreurs et la trace de ce qui a réellement été publié.

Pourquoi une IA locale avec un RAG ?

Le modèle reste dans un périmètre maîtrisé et le RAG lui fournit uniquement les procédures autorisées. Il peut ainsi préparer une synthèse et des contrôles en citant ses sources, sans être chargé de décider ou d'exécuter seul.

L'IA peut-elle interroger une base de données ?

Oui, mais d'abord sur une base de test ou une vue dédiée, avec un compte à privilèges minimaux, des limites de requêtes, un filtrage réseau et une journalisation complète.

Quel premier quick win choisir ?

Automatiser un flux simple et fréquent : une alerte ou une demande structurée devient un ticket dédupliqué, puis un créneau est proposé pour les actions courtes. L'IA arrive après la stabilisation des règles.

🎯 En résumé

Automatiser l'ITSM ne consiste pas à donner une clé API à une IA. Le système robuste sépare la rédaction, la validation, la publication dans NinjaOne, la planification et le prédiagnostic.

Le calendrier transforme les petits tickets en temps réellement réservé. L'IA locale avec RAG prépare le contexte sans envoyer les données vers un service externe. Le cloisonnement réseau, les comptes minimaux et la validation humaine restent obligatoires.

C'est cette combinaison — automatisation déterministe autour du modèle, preuves dans l'ITSM et périmètre local maîtrisé — qui rend l'usage de l'IA utile au service informatique.