Étude de cas technique / Kocre IT Services
Le support IT à distance repose sur la rapidité et le contexte. Ghost Admin fournit les deux en quelques secondes — sans laisser la confiance IA suffire à fermer un ticket.
Gérer le support IT pour plusieurs organisations clientes signifie porter simultanément le contexte de chacune — quelles plateformes elles utilisent, quel était leur dernier problème, ce qui a déjà été résolu, quel SLA s'applique. Sans outillage, chaque nouveau ticket commence par 10 à 15 minutes de lecture d'historique avant tout support réel. Le deuxième problème est le risque d'automatisation. Fermer automatiquement des tickets sur la seule confiance IA récupérerait ce temps — mais au détriment de la fiabilité. Un ticket mal classifié qui se résout automatiquement est un problème client que l'opérateur ne voit jamais. Kocre IT avait besoin d'une couche IA réellement utile pour la synthèse de contexte et la rédaction, et réellement conservative pour les actions autonomes — non pas parce que l'IA était faible, mais parce que les conditions d'action sur ses résultats devaient être non ambiguës.
Ghost Admin est la couche d'orchestration. Pour tout ticket ouvert, il récupère un bundle de contexte structuré avant d'appeler le modèle : — Le ticket complet avec tous les champs de triage IA — Jusqu'à 10 messages récents côté client — Tickets similaires précédemment résolus, matchés sur titre et catégorie — Brouillons KB/SOP déjà liés au ticket — Articles de connaissances publiés classés par pertinence — L'état de cycle de vie complet de l'organisation : statut d'accord, statut de paiement, progression d'onboarding Ghost envoie ce bundle à Claude et retourne un JSON à 10 champs : ce que le ticket signifie vraiment, le blocage le plus probable, l'action suivante recommandée, un appel de portée (support_standard / surveiller_scope / travail_scoped), des signaux de cycle de vie et un avertissement opérateur. Cette synthèse de contexte s'effectue en moins de 3 secondes. Ghost génère aussi des brouillons de suivi en 6 modes : réponse initiale, mise à jour de progression, résolution, collecte d'informations, mise à jour d'escalade et évaluation des besoins. Chaque brouillon puise dans le même bundle — ce qui signifie que les réponses tiennent compte de l'étape du cycle de vie du client, pas seulement de la description du problème.
Le triage IA peut marquer un ticket ai_can_auto_resolve: true — mais c'est une entrée dans le portail, pas une décision. Les six conditions suivantes doivent toutes être réunies simultanément :
Condition 1
Liste blanche de catégories
Seuls les tickets portal_account et billing_scope sont éligibles à la résolution automatique. Helpdesk, email, Microsoft 365, Google Workspace et SaaS admin nécessitent une intervention humaine quelle que soit la confiance IA.
Condition 2
Indicateur d'éligibilité IA
Le moteur de triage doit avoir défini ai_can_auto_resolve: true. Par défaut, c'est false. Seules les questions basées sur des instructions ou des politiques de portail obtiennent cet indicateur.
Condition 3
Seuil de confiance
La confiance IA doit dépasser 0,7. En dessous, le ticket nécessite une révision humaine — le portail traite un triage peu confiant comme une classification incertaine, pas comme un candidat limite à la résolution automatique.
Condition 4
Aucune escalade
ai_escalation_needed doit être false. Les tickets sensibles à la sécurité ou à fort impact ne sont jamais résolus automatiquement quelle que soit la confiance.
Condition 5
Aucun indicateur de projet
ai_project_flag doit être false. Migration, installation majeure, remédiation large — tout ce qui dépasse le support courant — nécessite une gestion et un cadrage manuels.
Condition 6
Aucun accès requis
ai_access_needed doit être false. Si la résolution nécessite un accès admin, des changements de compte ou une escalade fournisseur, le portail reste fermé.
Chaque ticket traité par Kocre IT accélère le suivant. Le volant fonctionne en quatre étapes : Enrichissement par triage : À la création du ticket, le triage IA s'exécute immédiatement — classifiant la catégorie, notant la confiance, signalant les risques d'escalade et de projet. Le ticket est enrichi de 10 champs IA avant que l'opérateur l'ouvre. Construction du bundle de contexte : Quand Ghost Admin s'exécute sur un ticket, il récupère des tickets similaires déjà résolus. Plus il y a de tickets résolus, plus le contexte est riche. Génération de connaissances : Quand un ticket se ferme, Ghost peut générer un brouillon KB/SOP à partir du fil de résolution. Ceci est strictement limité aux tickets résolus/fermés. Les tickets en cours ne génèrent jamais de brouillons. Récupération des connaissances : Les articles KB publiés se classent dans les futurs bundles Ghost. Avec le temps, le système accumule une mémoire institutionnelle. Au 50e ticket résolu pour un client, les nouveaux tickets arrivent avec des précédents correspondants — automatiquement.
Sentinel est la couche de surveillance et l'exemple le plus clair où l'IA a été délibérément exclue. Il s'exécute en tâche Cron Vercel toutes les heures, effectuant des vérifications déterministes sur toutes les URLs clients et les données de tickets. Aucun modèle n'intervient dans les décisions de surveillance :
Surveillance des URLs
Requête HEAD vers store_url et website_url de chaque client, timeout de 10 secondes. Temps de réponse > 5 000 ms retourne severity: warning. Statut non-2xx ou échec de connexion retourne severity: critical. Aucune inférence — le résultat est la réponse HTTP.
Détection de violation SLA
Interroge les tickets ouverts sans timestamp first_response_at qui ont dépassé leur seuil sla_response_hours. Le calcul est arithmétique : heures_ouvertes > sla_response_hours. Si vrai, ça déclenche — sans jugement sur la justification de la violation.
Pic de volume de tickets
Compare les tickets créés dans les dernières 24 heures avec la moyenne quotidienne sur 30 jours. Plus de 3× la moyenne déclenche severity: warning. Le seuil est codé en dur — non inféré par un modèle — donc l'alerte est entièrement prévisible.
Les résultats critiques créent automatiquement des tickets assignés à un admin. Les avertissements sont journalisés dans le log d'activité. Aucun modèle ne décide ce qui compte comme incident — Sentinel déclenche ou non, selon l'arithmétique. C'est intentionnel. Un système de surveillance qui demande à un modèle si une panne est significative introduit un risque d'hallucination dans un contexte où le déterminisme importe le plus. Quand une violation SLA survient, l'opérateur doit le savoir — pas une estimation de probabilité.
L'IA rédige la réponse, classifie le ticket et synthétise le contexte. Le code déterministe décide de la fermeture automatique, du déclenchement d'alertes et du franchissement des seuils de surveillance. La confiance est une entrée. Elle n'est jamais une condition suffisante.
C'est le type de système que nous construisons — une IA qui gère la charge cognitive, des portails déterministes pour les décisions importantes, et une couche de connaissances qui se renforce avec le temps.