● Offre B2B — Support technique & exploitation
Support technique : le diagnostic posé, l'action préparée
Résoudre un incident technique demande d'identifier le symptôme, de retrouver les cas similaires et de connaître les actions déjà validées. Votre agent établit ce diagnostic depuis votre base technique, cite les incidents comparables et prépare l'action de résolution correspondante. Hébergé en France : vos configurations et vos données d'incidents restent chez vous. Le support technique déclenche toute action sur les systèmes.
Hébergé en France
Configurations protégées
RGPD & AI Act : déploiement encadré
Supervision humaine
Mis à jour le
Déployé en quelques semaines
Support technique avancé · hébergé en France
Un client signale des lenteurs sur son environnement depuis ce matin.
Diagnostic documenté : symptôme rapproché de trois incidents comparables de votre base, avec leur résolution.
La configuration du client présente un point commun avec deux d'entre eux : il est indiqué.
L'action de résolution validée pour ces cas est préparée, avec ses prérequis.
🔗 Sourcé · base technique et incidents comparables
La configuration du client présente un point commun avec deux d'entre eux : il est indiqué.
L'action de résolution validée pour ces cas est préparée, avec ses prérequis.
🔗 Sourcé · base technique et incidents comparables
Applique la correction.
L'action est prête avec ses prérequis et son ordre d'exécution.
Son déclenchement sur un environnement client appartient au support technique : une intervention sur un système en production se décide, elle ne se déduit pas.
✎ Appui · action préparée, déclenchement humain
Son déclenchement sur un environnement client appartient au support technique : une intervention sur un système en production se décide, elle ne se déduit pas.
✎ Appui · action préparée, déclenchement humain
Inférence locale · traitements dans l'UE visés
Base technique hébergée en France
Souverain par constructionInférence locale ou hébergement France
RGPD & AI Act : déploiement encadréTraçabilité & supervision humaine
Clé en mainConçu, installé et exploité pour vous
Le support technique décideL'agent prépare, jamais ne tranche
✦ En bref
Un agent Blue Lemon Agent de support technique établit un diagnostic documenté depuis votre base technique, cite les incidents comparables et leur résolution, et prépare l'action correspondante avec ses prérequis. Le déclenchement sur un système en production appartient au support. Il fonctionne en inférence locale ou est hébergé en France : vos configurations restent chez vous, architecture conçue pour réduire l'exposition aux législations extraterritoriales, la localisation ne garantissant pas à elle seule l'immunité.
100 %
hébergé en France dans l'architecture cible
0
transfert hors UE dans l'architecture cible
6
usages de support technique prêts à déployer
0
décision prise sans validation humaine
Repères décrivant notre offre, et non des résultats mesurés chez un client. L'ampleur du gain sur le volume d'incidents et la richesse de votre base technique se confirme par un pilote.
Le contexte
Qu'apporte un agent IA à votre support technique ?
La plupart des incidents ressemblent à un incident déjà traité. Retrouver ce précédent est la moitié du travail.
! L'enjeu
Un diagnostic rapide repose sur la mémoire des incidents passés et sur la connaissance des configurations. Cette mémoire existe dans votre base technique, mais la mobiliser sous pression demande du temps. L'agent la mobilise immédiatement : incidents comparables cités, points communs de configuration indiqués, action déjà validée préparée.
✓ Notre réponse
Le support technique part d'un diagnostic documenté et d'une action prête, plutôt que d'une page blanche. Déclencher une intervention sur un système en production reste sa décision : une action mal placée porte à conséquence sur l'environnement d'un client. Inférence locale ou ressource isolée hébergée en France : vos configurations et vos données d'incidents ne sortent pas de l'entreprise.
Le point décisif
Vos configurations et vos données d'incidents : souveraineté & conformité
Vos configurations techniques et vos historiques d'incidents décrivent précisément votre système d'information. Voici comment ils sont protégés.
Inférence locale
L'agent peut tourner sur une machine de votre organisation : aucune configuration ni donnée d'incident ne sort du réseau.
Hébergement en France
Sinon, une ressource dédiée et isolée hébergée en France, sous droit français — vos bases techniques et vos incidents : traitements et accès opérés dans l'Union européenne visés par l'architecture.
Exposition extraterritoriale réduite
Pour vos configurations et vos données d'incidents, l'architecture vise à réduire l'exposition au Cloud Act et au FISA 702 ; la seule localisation en France ou dans l'Union européenne ne garantit pas l'immunité.
Ressource isolée
Aucune mutualisation : un environnement strictement dédié à votre entreprise et à sa base technique.
Chaque diagnostic adossé à des précédents
Les incidents comparables cités et les points communs de configuration sont indiqués ; chiffrement, accès par rôle (RBAC) et journalisation de chaque diagnostic établi.
AI Act : déploiement encadré
Agent strictement en appui ; aucune action déclenchée sur un système sans décision humaine ; traçabilité et supervision humaine de bout en bout.
Ce qui dépend de l'architecture retenue Ces points ne sont pas des garanties générales : ils sont arrêtés déploiement par déploiement, au devis.
- La localisation applicable est celle de l'architecture décrite au devis et vérifiée avant mise en service.
- L'exécution locale n'est annoncée que pour la configuration explicitement décrite et recettée au devis.
- L'isolation applicable dépend du mode de déploiement décrit au devis ; aucune isolation dédiée n'est présumée.
- Les rôles et permissions sont configurés et recettés pour les identités et systèmes effectivement raccordés.
- Les événements journalisés, leur contenu, leur durée de conservation et leurs accès sont définis pour le déploiement retenu.
Pour les incidents touchant à la sécurité et les configurations d'infrastructures critiques, options SecNumCloud et hébergement renforcé selon votre niveau d'exigence. Une seule architecture est conçue pour répondre à la fois au RGPD et à l'exposition extraterritoriale. Conçu pour être déployé dans le respect du RGPD et de l'AI Act, après qualification du traitement, des rôles et des risques propres à votre contexte.
Démonstration
Voyez l'agent au travail
5 situations réelles, prises parmi celles qui reviennent le plus. Choisissez-en une : l'échange se déroule comme il se déroulerait chez vous.
Démonstration écrite à l'avance. Ces échanges illustrent le comportement de l'agent — ses sources, ses refus, ce qu'il laisse à vos équipes. Rien n'est envoyé depuis cette page, aucun modèle n'y est interrogé, et les dossiers cités sont fictifs. C'est précisément ce que nous promettons à vos données.
Les comportements montrés ici — surveillance, règles d'automatisation, routage et relances — sont paramétrés avec vous lors du déploiement, à partir de vos outils, de vos règles et de vos seuils.
Les points d'architecture cités dans ces échanges — localisation, exécution locale, isolation, chiffrement, accès par rôle, journalisation — ne sont pas une garantie attachée à la démonstration : ils sont ceux de l'architecture décrite à votre devis, et vérifiés avant mise en service.
L'entreprise de cette démonstration
Entreprise fictiveNorvic Systèmes — éditeur et hébergeur d'une plateforme de gestion logistique en mode abonné
- Secteur
- Édition logicielle B2B et exploitation — support technique de 7 h à 21 h du lundi au vendredi, astreinte la nuit et le week-end
- Effectif
- 96 salariés, dont 11 au support technique : 4 au premier niveau, 5 au second, 2 experts qui tiennent l'astreinte à tour de rôle
- Clients servis
- 214 environnements clients — transporteurs, entrepôts et prestataires logistiques, de 30 à 2 000 utilisateurs chacun
- Ordre de grandeur
- 7 400 incidents par an, 620 par mois, 38 minutes de traitement en moyenne ; engagement contractuel de rétablissement en 4 heures sur les incidents bloquants
- Outils en place
- Outil de tickets, supervision, dépôt de configurations, base de connaissances de 9 ans et cinq ans de tickets clos — l'agent s'y branche en lecture, rien n'est remplacé ni migré
- Qui décide
- Le responsable du support technique valide les actions sur les environnements clients ; l'ingénieur d'astreinte déclenche l'exécution ; le directeur technique arbitre les corrections de fond
- Les points d'amélioration
- 60 % du temps d'un incident part à retrouver les précédents ; un incident majeur de nuit attend 3 h 10 avant la première action ; 14 % des tickets clos rouvrent ; 31 dépassements de l'engagement de 4 heures l'an dernier
Norvic Systèmes ne cherche pas à traiter plus d'incidents, mais à traiter les mêmes plus vite et à en voir revenir moins. L'agent tourne en inférence locale sur une machine de l'entreprise et se branche en lecture sur l'outil de tickets, la supervision, le dépôt de configurations et cinq ans d'historique : il diagnostique et prépare, le support décide et déclenche. Les échanges qui suivent couvrent un trimestre, de la reprise de l'historique au bilan présenté au comité technique.
Cette entreprise, ses chiffres et les échanges qui suivent ont été inventés pour la démonstration. Ils illustrent une situation courante ; ils ne décrivent aucun client réel.
Support technique avancé · hébergé en France
J'ai relu vos cinq ans de tickets cette nuit — 36 500 incidents clos — et j'en ai tiré 23 familles de symptômes qui expliquent 71 % de ce que votre support traite chaque jour.
L'écart que j'ai mesuré, et c'est lui qui décide du gain : sur vos 7 400 incidents de l'an dernier, la recherche du précédent pèse 60 % du temps de traitement — 23 minutes sur les 38 que dure un incident en moyenne. Vos ingénieurs ne passent pas leur journée à résoudre : ils passent leur journée à retrouver comment ils avaient résolu.
Ce que chaque famille contient, et qui se vérifie ligne à ligne : le symptôme tel que le client le décrit, les traces de journal qui l'accompagnent, les configurations sur lesquelles il apparaît, la résolution qui a fonctionné et celle qui avait été tentée d'abord sans effet — le renseignement le plus utile, et celui qu'aucune base ne pense à conserver.
· Famille « lenteurs après montée de version » : 2 140 incidents en cinq ans, résolus 9 fois sur 10 par la même action.
· Famille « traitement nocturne dépassant sa fenêtre » : 1 780 incidents, tous sur des environnements de plus de 400 utilisateurs.
· Famille « jeton d'interface expiré » : 960 incidents, et l'échéance est connue d'avance à chaque fois.
Ce que ça vous rend dès demain : à l'ouverture d'un ticket, le diagnostic arrive DÉJÀ documenté, ses précédents cités. La recherche passe de 23 minutes à 2 minutes 40 — 60 % du temps de l'incident ramenés à 7 %.
Ce que je vous propose : que le responsable du support relise les 23 familles, et je les applique dès le prochain ticket ouvert. Chaque famille se corrige d'un mot : c'est votre matière, je n'ai fait que la mettre au clair. familles-d-incidents_23-familles-36500-tickets.pdf71 % des incidents dans 23 familles, résolution et fausse piste
⛓ Sourcé · 5 ans de tickets clos (36 500), journaux joints aux incidents, dépôt de configurations
L'écart que j'ai mesuré, et c'est lui qui décide du gain : sur vos 7 400 incidents de l'an dernier, la recherche du précédent pèse 60 % du temps de traitement — 23 minutes sur les 38 que dure un incident en moyenne. Vos ingénieurs ne passent pas leur journée à résoudre : ils passent leur journée à retrouver comment ils avaient résolu.
Ce que chaque famille contient, et qui se vérifie ligne à ligne : le symptôme tel que le client le décrit, les traces de journal qui l'accompagnent, les configurations sur lesquelles il apparaît, la résolution qui a fonctionné et celle qui avait été tentée d'abord sans effet — le renseignement le plus utile, et celui qu'aucune base ne pense à conserver.
· Famille « lenteurs après montée de version » : 2 140 incidents en cinq ans, résolus 9 fois sur 10 par la même action.
· Famille « traitement nocturne dépassant sa fenêtre » : 1 780 incidents, tous sur des environnements de plus de 400 utilisateurs.
· Famille « jeton d'interface expiré » : 960 incidents, et l'échéance est connue d'avance à chaque fois.
Ce que ça vous rend dès demain : à l'ouverture d'un ticket, le diagnostic arrive DÉJÀ documenté, ses précédents cités. La recherche passe de 23 minutes à 2 minutes 40 — 60 % du temps de l'incident ramenés à 7 %.
Ce que je vous propose : que le responsable du support relise les 23 familles, et je les applique dès le prochain ticket ouvert. Chaque famille se corrige d'un mot : c'est votre matière, je n'ai fait que la mettre au clair. familles-d-incidents_23-familles-36500-tickets.pdf71 % des incidents dans 23 familles, résolution et fausse piste
⛓ Sourcé · 5 ans de tickets clos (36 500), journaux joints aux incidents, dépôt de configurations
Un client signale des lenteurs sur son environnement depuis ce matin 8 h. C'est le genre de ticket qui nous coûte une demi-journée.
Le diagnostic est posé, avec trois incidents comparables de votre base et la résolution de chacun. Il a pris 2 minutes 40.
· Incident 41-2087, il y a 14 mois, même symptôme, même version applicative : résolu par la purge du cache d'agrégation, 6 minutes.
· Incident 39-1144, il y a 21 mois : même symptôme, cause différente — un volume de journalisation saturé. Je vous le donne justement parce qu'il ne colle pas : c'est la fausse piste la plus fréquente de cette famille, et elle coûte 40 minutes à qui la suit.
· Incident 44-0912, il y a 5 semaines, chez un autre client : même symptôme après la même montée de version.
Le point commun de configuration, et c'est lui qui tranche : l'environnement de ce client et ceux des incidents 41-2087 et 44-0912 portent tous les trois le traitement d'agrégation programmé à 7 h 45, alors que la configuration de référence le place à 5 h 30. Les lenteurs commencent à 8 h : elles suivent le traitement, elles ne le précèdent pas.
Ce que j'ai vérifié avant de vous l'affirmer : la charge du serveur d'application à 7 h 45 ce matin, le journal d'exécution du traitement, et les 11 autres environnements portant le même décalage horaire — 7 d'entre eux ont ouvert un ticket comparable dans les six derniers mois.
Le pas suivant que je propose : l'action de résolution de l'incident 41-2087 est montée et vous attend, prérequis compris. Et je vous propose de regarder les 11 environnements décalés dans la foulée : c'est le même ticket qui va arriver onze fois. diagnostic_lenteurs-apres-montee-de-version.pdf3 précédents cités, dont la fausse piste à 40 minutes
⛓ Sourcé · ticket en cours, incidents 41-2087, 39-1144 et 44-0912, dépôt de configurations, supervision du matin
· Incident 41-2087, il y a 14 mois, même symptôme, même version applicative : résolu par la purge du cache d'agrégation, 6 minutes.
· Incident 39-1144, il y a 21 mois : même symptôme, cause différente — un volume de journalisation saturé. Je vous le donne justement parce qu'il ne colle pas : c'est la fausse piste la plus fréquente de cette famille, et elle coûte 40 minutes à qui la suit.
· Incident 44-0912, il y a 5 semaines, chez un autre client : même symptôme après la même montée de version.
Le point commun de configuration, et c'est lui qui tranche : l'environnement de ce client et ceux des incidents 41-2087 et 44-0912 portent tous les trois le traitement d'agrégation programmé à 7 h 45, alors que la configuration de référence le place à 5 h 30. Les lenteurs commencent à 8 h : elles suivent le traitement, elles ne le précèdent pas.
Ce que j'ai vérifié avant de vous l'affirmer : la charge du serveur d'application à 7 h 45 ce matin, le journal d'exécution du traitement, et les 11 autres environnements portant le même décalage horaire — 7 d'entre eux ont ouvert un ticket comparable dans les six derniers mois.
Le pas suivant que je propose : l'action de résolution de l'incident 41-2087 est montée et vous attend, prérequis compris. Et je vous propose de regarder les 11 environnements décalés dans la foulée : c'est le même ticket qui va arriver onze fois. diagnostic_lenteurs-apres-montee-de-version.pdf3 précédents cités, dont la fausse piste à 40 minutes
⛓ Sourcé · ticket en cours, incidents 41-2087, 39-1144 et 44-0912, dépôt de configurations, supervision du matin
Tout ça suppose que vous lisiez nos configurations et les données d'incidents de nos clients. Elles sortent où, exactement ?
Elles ne sortent pas de vos murs. Je tourne en inférence locale sur une machine de Norvic, et vos tickets ne sont recopiés nulle part.
L'inférence locale, c'est le modèle qui calcule sur votre machine : le contenu d'un ticket ou d'un fichier de configuration ne traverse aucun réseau extérieur pour être traité. Si vous préférez ne pas héberger de machine, l'autre voie est une ressource isolée hébergée en France, dédiée à Norvic — aucune mutualisation avec un autre éditeur, ni avec un autre de vos clients.
Ce que ça change, point par point :
· Vos configurations n'entraînent aucun modèle public. Ce que j'apprends de vos 214 environnements sert à vos 214 environnements. Rien de ce que vous me confiez ne ressort ailleurs.
· Je lis, je n'écris pas : le compte technique par lequel j'accède à la supervision et au dépôt de configurations n'a pas le droit d'écrire — c'est plus solide qu'une promesse, parce que ça se vérifie en une commande.
· Chiffrement en transit et au repos, et accès par rôle — les droits suivent la fonction : le premier niveau ouvre les tickets et les familles d'incidents, pas les fichiers de configuration ni les journaux d'authentification.
· Journal complet : quel diagnostic a été établi, sur quels précédents, à quelle heure, et qui l'a lu. C'est ce journal qui vous permet de répondre au client qui vous le demandera.
· Hébergement en France, sous droit français, architecture conçue pour réduire l'exposition aux législations extraterritoriales, la localisation ne garantissant pas à elle seule l'immunité, y compris face à un acteur américain qui hébergerait en Europe.
Le chiffre qui rend ça commercial plutôt que technique : 9 de vos 214 clients imposent déjà l'hébergement en France dans leur contrat, et votre dernier appel d'offres public en faisait un critère noté sur 8 points. Vous avez pu cocher la case sans réserve, et vous l'avez gagné.
Ce que je propose : que je tienne à jour la fiche technique que vos clients réclament au renouvellement — hébergement, sous-traitants, durées de conservation, qui accède à quoi. Le premier état est écrit et vous l'avez sous la main. cadre-technique_ou-vivent-vos-configurations.pdfInférence locale, lecture seule, traitements dans l'UE visés
✎ Cadre · architecture de déploiement, droits du compte technique, journal des accès, clauses des 214 contrats
L'inférence locale, c'est le modèle qui calcule sur votre machine : le contenu d'un ticket ou d'un fichier de configuration ne traverse aucun réseau extérieur pour être traité. Si vous préférez ne pas héberger de machine, l'autre voie est une ressource isolée hébergée en France, dédiée à Norvic — aucune mutualisation avec un autre éditeur, ni avec un autre de vos clients.
Ce que ça change, point par point :
· Vos configurations n'entraînent aucun modèle public. Ce que j'apprends de vos 214 environnements sert à vos 214 environnements. Rien de ce que vous me confiez ne ressort ailleurs.
· Je lis, je n'écris pas : le compte technique par lequel j'accède à la supervision et au dépôt de configurations n'a pas le droit d'écrire — c'est plus solide qu'une promesse, parce que ça se vérifie en une commande.
· Chiffrement en transit et au repos, et accès par rôle — les droits suivent la fonction : le premier niveau ouvre les tickets et les familles d'incidents, pas les fichiers de configuration ni les journaux d'authentification.
· Journal complet : quel diagnostic a été établi, sur quels précédents, à quelle heure, et qui l'a lu. C'est ce journal qui vous permet de répondre au client qui vous le demandera.
· Hébergement en France, sous droit français, architecture conçue pour réduire l'exposition aux législations extraterritoriales, la localisation ne garantissant pas à elle seule l'immunité, y compris face à un acteur américain qui hébergerait en Europe.
Le chiffre qui rend ça commercial plutôt que technique : 9 de vos 214 clients imposent déjà l'hébergement en France dans leur contrat, et votre dernier appel d'offres public en faisait un critère noté sur 8 points. Vous avez pu cocher la case sans réserve, et vous l'avez gagné.
Ce que je propose : que je tienne à jour la fiche technique que vos clients réclament au renouvellement — hébergement, sous-traitants, durées de conservation, qui accède à quoi. Le premier état est écrit et vous l'avez sous la main. cadre-technique_ou-vivent-vos-configurations.pdfInférence locale, lecture seule, traitements dans l'UE visés
✎ Cadre · architecture de déploiement, droits du compte technique, journal des accès, clauses des 214 contrats
J'ai relevé l'état réel de vos 214 environnements et je l'ai comparé à votre configuration de référence : 61 écarts, dont 12 expliquent à eux seuls trois de vos familles d'incidents.
La configuration de référence, c'est l'état que vous considérez comme normal pour un environnement client ; un écart, c'est un réglage qui s'en éloigne — souvent pour une bonne raison, parfois pour une raison que plus personne ne connaît.
Ce que le relevé donne :
· 34 écarts documentés et voulus — un client qui a demandé une fenêtre de traitement particulière, un autre qui garde une version antérieure le temps d'un chantier. Ils sont légitimes, ils sont désormais écrits.
· 15 écarts hérités d'une migration, que personne n'a rétablis parce que rien ne les signalait.
· 12 écarts qui produisent des incidents, et je les chiffre : les 11 environnements dont le traitement d'agrégation est décalé à 7 h 45 ont ouvert 34 tickets « lenteurs » en six mois ; les 6 environnements dont le quota de journalisation est resté à la valeur d'origine ont produit 19 saturations ; les 4 environnements dont le certificat d'interface expire dans le même trimestre en produiront 4 de plus si personne ne bouge.
Ce que ça change sur le temps d'un incident : l'analyse de la configuration concernée passe de 35 % à 6 % du temps de traitement — de 13 minutes à 2 minutes 15 —, parce que le relevé est fait et daté avant que le ticket n'arrive.
Le pas suivant, et il ne coûte rien à décider : les 12 écarts sont classés par nombre de tickets évités par mois, et la remise en conformité de chacun est écrite — commande, fenêtre, contrôle de bon fonctionnement, retour arrière. Vous en validez trois et je les prépare pour la prochaine fenêtre de maintenance ; les 34 écarts voulus, eux, restent tels quels et je cesse de les signaler. ecarts-de-configuration_214-environnements.pdf61 écarts, 12 qui produisent des tickets, chiffrés
⛓ Sourcé · relevé des 214 environnements, configuration de référence, tickets des 6 derniers mois
La configuration de référence, c'est l'état que vous considérez comme normal pour un environnement client ; un écart, c'est un réglage qui s'en éloigne — souvent pour une bonne raison, parfois pour une raison que plus personne ne connaît.
Ce que le relevé donne :
· 34 écarts documentés et voulus — un client qui a demandé une fenêtre de traitement particulière, un autre qui garde une version antérieure le temps d'un chantier. Ils sont légitimes, ils sont désormais écrits.
· 15 écarts hérités d'une migration, que personne n'a rétablis parce que rien ne les signalait.
· 12 écarts qui produisent des incidents, et je les chiffre : les 11 environnements dont le traitement d'agrégation est décalé à 7 h 45 ont ouvert 34 tickets « lenteurs » en six mois ; les 6 environnements dont le quota de journalisation est resté à la valeur d'origine ont produit 19 saturations ; les 4 environnements dont le certificat d'interface expire dans le même trimestre en produiront 4 de plus si personne ne bouge.
Ce que ça change sur le temps d'un incident : l'analyse de la configuration concernée passe de 35 % à 6 % du temps de traitement — de 13 minutes à 2 minutes 15 —, parce que le relevé est fait et daté avant que le ticket n'arrive.
Le pas suivant, et il ne coûte rien à décider : les 12 écarts sont classés par nombre de tickets évités par mois, et la remise en conformité de chacun est écrite — commande, fenêtre, contrôle de bon fonctionnement, retour arrière. Vous en validez trois et je les prépare pour la prochaine fenêtre de maintenance ; les 34 écarts voulus, eux, restent tels quels et je cesse de les signaler. ecarts-de-configuration_214-environnements.pdf61 écarts, 12 qui produisent des tickets, chiffrés
⛓ Sourcé · relevé des 214 environnements, configuration de référence, tickets des 6 derniers mois
Et quand l'incident ne ressemble à rien de connu ? C'est là qu'on y passe la nuit.
C'est 4 % de vos incidents — 296 par an — et c'est là que je vous fais gagner le plus de temps, parce que je pars du travail que personne n'a le temps de faire avant 2 h du matin.
Ce que je remets quand aucun précédent ne colle, et je le remets en 26 minutes :
· La chronologie corrélée : les journaux des trois couches — application, base, interfaces — alignés à la seconde autour de la première anomalie observée, et non trois fichiers à ouvrir côte à côte.
· Le périmètre : combien d'environnements présentent la même trace en ce moment. Un incident isolé et un incident qui touche 40 clients n'appellent pas le même geste, et c'est la première chose que vous voulez savoir.
· La ligne de bascule : le dernier changement intervenu avant la première anomalie — mise à jour, changement de réglage, montée de charge —, avec son heure et son auteur. Sur les 26 incidents sans précédent du trimestre, la ligne de bascule était postérieure de moins de 20 minutes à l'anomalie dans 21 cas.
· Trois hypothèses classées, chacune avec le test qui la confirme ou l'écarte et le temps que ce test demande. L'hypothèse que j'avais placée en tête s'est révélée la bonne 19 fois sur 26 ; les 7 autres fois, le test l'a écartée en moins de dix minutes et la deuxième a tranché.
Le gain, mesuré sur le trimestre : le délai avant la première piste sérieuse passe de 3 h 10 à 26 minutes.
Et le pas suivant, qui est le vrai gain de long terme : chaque incident sans précédent que vous clôturez devient une fiche de la base, écrite par moi le soir même — symptôme, traces, configuration, résolution retenue et fausse piste écartée. Les 26 du trimestre sont écrits et vous attendent : à la prochaine occurrence, ce ne sera plus un incident sans précédent. incident-sans-precedent_dossier-d-analyse.pdf3 h 10 ramenées à 26 minutes, 19 hypothèses justes sur 26
⛓ Sourcé · journaux applicatifs, base et interfaces, journal des changements, 26 incidents sans précédent du trimestre
Ce que je remets quand aucun précédent ne colle, et je le remets en 26 minutes :
· La chronologie corrélée : les journaux des trois couches — application, base, interfaces — alignés à la seconde autour de la première anomalie observée, et non trois fichiers à ouvrir côte à côte.
· Le périmètre : combien d'environnements présentent la même trace en ce moment. Un incident isolé et un incident qui touche 40 clients n'appellent pas le même geste, et c'est la première chose que vous voulez savoir.
· La ligne de bascule : le dernier changement intervenu avant la première anomalie — mise à jour, changement de réglage, montée de charge —, avec son heure et son auteur. Sur les 26 incidents sans précédent du trimestre, la ligne de bascule était postérieure de moins de 20 minutes à l'anomalie dans 21 cas.
· Trois hypothèses classées, chacune avec le test qui la confirme ou l'écarte et le temps que ce test demande. L'hypothèse que j'avais placée en tête s'est révélée la bonne 19 fois sur 26 ; les 7 autres fois, le test l'a écartée en moins de dix minutes et la deuxième a tranché.
Le gain, mesuré sur le trimestre : le délai avant la première piste sérieuse passe de 3 h 10 à 26 minutes.
Et le pas suivant, qui est le vrai gain de long terme : chaque incident sans précédent que vous clôturez devient une fiche de la base, écrite par moi le soir même — symptôme, traces, configuration, résolution retenue et fausse piste écartée. Les 26 du trimestre sont écrits et vous attendent : à la prochaine occurrence, ce ne sera plus un incident sans précédent. incident-sans-precedent_dossier-d-analyse.pdf3 h 10 ramenées à 26 minutes, 19 hypothèses justes sur 26
⛓ Sourcé · journaux applicatifs, base et interfaces, journal des changements, 26 incidents sans précédent du trimestre
Vous voulez donc écrire dans notre base de connaissances. On l'a laissée vieillir justement parce que personne n'a le temps de la tenir.
Elle est déjà relue, et j'ai réécrit les 120 fiches qui portent l'essentiel de votre activité. Vous relisez, vous ne rédigez plus.
L'état que j'ai trouvé, chiffres à l'appui : 3 180 fiches en neuf ans, dont 1 940 visent une version applicative que vous n'exploitez plus — 61 %. Ce n'est pas de la négligence : ce sont des fiches justes qui ont vieilli pendant que le produit avançait.
Ce que j'ai fait, et ce qui le rend vérifiable : j'ai classé les 3 180 fiches par nombre d'incidents où elles ont réellement servi sur cinq ans, et 120 fiches couvrent 68 % de ces emplois. Ces 120 sont réécrites : version applicative concernée, symptôme, contrôle préalable, action, contrôle de bon fonctionnement, retour arrière, et le nombre de fois où la fiche a servi.
Ce que j'y ajoute et qui n'existait nulle part : la fausse piste. Sur la famille des lenteurs, 40 minutes se perdent à regarder la journalisation avant de regarder l'agrégation — la fiche le dit maintenant en première ligne.
Ce que ça rend, chiffré : un ingénieur de premier niveau résout seul 3 des 23 familles aujourd'hui ; avec les fiches réécrites, il en résout 14. Sur les 620 incidents d'un mois, ce sont 180 tickets qui ne montent plus au second niveau — et vos deux experts d'astreinte récupèrent leurs journées.
Le pas suivant que je propose : que le responsable du support valide les 120 en lot, famille par famille — une heure de lecture —, et que j'écrive désormais la version à jour de toute fiche qu'une montée de version rend caduque, dans la nuit qui suit la mise en production. Votre base cessera de vieillir en silence, et elle ne vous coûtera plus qu'une relecture par version. base-de-connaissances_120-fiches-reecrites.pdf1 940 fiches périmées, 120 réécrites, 68 % des emplois
⛓ Sourcé · base de connaissances (3 180 fiches, 9 ans), emplois réels par fiche sur 5 ans, journal des montées de version
L'état que j'ai trouvé, chiffres à l'appui : 3 180 fiches en neuf ans, dont 1 940 visent une version applicative que vous n'exploitez plus — 61 %. Ce n'est pas de la négligence : ce sont des fiches justes qui ont vieilli pendant que le produit avançait.
Ce que j'ai fait, et ce qui le rend vérifiable : j'ai classé les 3 180 fiches par nombre d'incidents où elles ont réellement servi sur cinq ans, et 120 fiches couvrent 68 % de ces emplois. Ces 120 sont réécrites : version applicative concernée, symptôme, contrôle préalable, action, contrôle de bon fonctionnement, retour arrière, et le nombre de fois où la fiche a servi.
Ce que j'y ajoute et qui n'existait nulle part : la fausse piste. Sur la famille des lenteurs, 40 minutes se perdent à regarder la journalisation avant de regarder l'agrégation — la fiche le dit maintenant en première ligne.
Ce que ça rend, chiffré : un ingénieur de premier niveau résout seul 3 des 23 familles aujourd'hui ; avec les fiches réécrites, il en résout 14. Sur les 620 incidents d'un mois, ce sont 180 tickets qui ne montent plus au second niveau — et vos deux experts d'astreinte récupèrent leurs journées.
Le pas suivant que je propose : que le responsable du support valide les 120 en lot, famille par famille — une heure de lecture —, et que j'écrive désormais la version à jour de toute fiche qu'une montée de version rend caduque, dans la nuit qui suit la mise en production. Votre base cessera de vieillir en silence, et elle ne vous coûtera plus qu'une relecture par version. base-de-connaissances_120-fiches-reecrites.pdf1 940 fiches périmées, 120 réécrites, 68 % des emplois
⛓ Sourcé · base de connaissances (3 180 fiches, 9 ans), emplois réels par fiche sur 5 ans, journal des montées de version
L'action de résolution des lenteurs est montée, prête à exécuter, et elle porte tout ce qu'il faut pour la déclencher en confiance.
Ce que le dossier d'action contient :
· Les prérequis : version applicative attendue, sauvegarde de moins de 24 heures vérifiée, et l'absence de traitement en cours sur l'environnement — je l'ai contrôlée il y a deux minutes.
· L'ordre d'exécution, commande par commande, dans l'ordre exact où les incidents 41-2087 et 44-0912 l'avaient appliqué.
· Le contrôle de bon fonctionnement : le temps de réponse moyen doit repasser sous 800 millisecondes dans les 90 secondes qui suivent — c'est le chiffre relevé sur les deux précédents, pas un seuil que j'invente.
· Le retour arrière — la manœuvre qui rétablit l'état exact d'avant l'action, si le contrôle n'est pas au vert — écrit, et essayé ce matin sur votre environnement de recette : 38 secondes.
· La fenêtre : l'action prend 6 minutes et ne coupe aucun service ; elle peut donc se passer de fenêtre de maintenance, et je le dis parce que c'est ce qui va vous faire gagner la demi-journée.
Le temps que ça déplace : la préparation d'une action de résolution passe de 30 % à 7 % du temps de l'incident — de 11 minutes 30 à 2 minutes 40. Sur les 3 100 incidents par an qui appellent une action, ce sont 456 heures d'ingénieur qui repartent vers vos clients.
Ce que je propose maintenant : vous déclenchez celle-ci d'un clic, et je monte les 11 mêmes pour les 11 environnements décalés — elles seront prêtes avant votre café, et le ticket qui devait arriver onze fois n'arrivera pas. action-de-resolution_prerequis-et-retour-arriere.pdf6 minutes, sans coupure, retour arrière essayé en 38 secondes
⛓ Sourcé · incidents 41-2087 et 44-0912, état de l'environnement à l'instant, essai de retour arrière sur la recette
Ce que le dossier d'action contient :
· Les prérequis : version applicative attendue, sauvegarde de moins de 24 heures vérifiée, et l'absence de traitement en cours sur l'environnement — je l'ai contrôlée il y a deux minutes.
· L'ordre d'exécution, commande par commande, dans l'ordre exact où les incidents 41-2087 et 44-0912 l'avaient appliqué.
· Le contrôle de bon fonctionnement : le temps de réponse moyen doit repasser sous 800 millisecondes dans les 90 secondes qui suivent — c'est le chiffre relevé sur les deux précédents, pas un seuil que j'invente.
· Le retour arrière — la manœuvre qui rétablit l'état exact d'avant l'action, si le contrôle n'est pas au vert — écrit, et essayé ce matin sur votre environnement de recette : 38 secondes.
· La fenêtre : l'action prend 6 minutes et ne coupe aucun service ; elle peut donc se passer de fenêtre de maintenance, et je le dis parce que c'est ce qui va vous faire gagner la demi-journée.
Le temps que ça déplace : la préparation d'une action de résolution passe de 30 % à 7 % du temps de l'incident — de 11 minutes 30 à 2 minutes 40. Sur les 3 100 incidents par an qui appellent une action, ce sont 456 heures d'ingénieur qui repartent vers vos clients.
Ce que je propose maintenant : vous déclenchez celle-ci d'un clic, et je monte les 11 mêmes pour les 11 environnements décalés — elles seront prêtes avant votre café, et le ticket qui devait arriver onze fois n'arrivera pas. action-de-resolution_prerequis-et-retour-arriere.pdf6 minutes, sans coupure, retour arrière essayé en 38 secondes
⛓ Sourcé · incidents 41-2087 et 44-0912, état de l'environnement à l'instant, essai de retour arrière sur la recette
Le jour, ça va. La nuit, notre astreinte met trois heures à se connecter et l'action attend. C'est là qu'on paie des pénalités.
Alors donnez-moi un mandat, et la nuit cesse de vous coûter. Il est écrit, plafonné, daté, retirable d'un mot — et vous l'avez sous les yeux.
Ce que le mandat couvre, et rien d'autre : six actions nommées, toutes réversibles — redémarrage d'un service applicatif, purge du cache d'agrégation, extension d'un volume de journalisation, relance d'un traitement nocturne interrompu, rotation d'un jeton d'interface expiré, remise en file d'un lot bloqué. Ce sont vos six actions les plus fréquentes, et vos ingénieurs les ont exécutées 1 240 fois en cinq ans sans un seul incident induit.
Ce qui le plafonne, ligne par ligne :
· Une seule exécution par incident. Si le contrôle n'est pas au vert, je fais le retour arrière et j'appelle l'astreinte, dossier complet en main.
· Les environnements couverts sont listés nommément, et vous en retirez un quand vous voulez.
· Hors des six actions, je monte le dossier et l'astreinte déclenche — elle se réveille pour décider, plus pour chercher.
· Revue au bout de trois mois, relevé en main. Sans décision explicite à la revue, le mandat s'arrête : c'est la reconduction qui demande une signature, pas l'arrêt.
· Retrait : un mot, et l'exécution directe cesse dans la minute. Tout repasse en dossier à déclencher, rien d'autre ne change.
Ce que ça vaut, sur vos propres chiffres : 148 incidents de nuit le trimestre dernier, dont 96 relèvent des six actions. Le rétablissement passerait de 3 h 10 à 4 minutes. Vos 31 dépassements de l'engagement de 4 heures de l'an dernier — 1 200 € de pénalité chacun, 37 200 € — tombent à 6 sur la simulation : 30 000 € qui restent chez vous.
Et la décision reste entière : 0 action déclenchée sans décision humaine — le mandat EST cette décision, écrite d'avance, datée, et le journal la relie à chaque exécution. Signez-le et la première nuit couverte est celle de vendredi. mandat-d-execution_6-actions-plafonne.pdf96 nuits couvertes sur 148, 30 000 € de pénalités évitées
✎ Cadre · mandat rédigé, 1 240 exécutions historiques des 6 actions, 148 incidents de nuit du trimestre, pénalités contractuelles de l'exercice
Ce que le mandat couvre, et rien d'autre : six actions nommées, toutes réversibles — redémarrage d'un service applicatif, purge du cache d'agrégation, extension d'un volume de journalisation, relance d'un traitement nocturne interrompu, rotation d'un jeton d'interface expiré, remise en file d'un lot bloqué. Ce sont vos six actions les plus fréquentes, et vos ingénieurs les ont exécutées 1 240 fois en cinq ans sans un seul incident induit.
Ce qui le plafonne, ligne par ligne :
· Une seule exécution par incident. Si le contrôle n'est pas au vert, je fais le retour arrière et j'appelle l'astreinte, dossier complet en main.
· Les environnements couverts sont listés nommément, et vous en retirez un quand vous voulez.
· Hors des six actions, je monte le dossier et l'astreinte déclenche — elle se réveille pour décider, plus pour chercher.
· Revue au bout de trois mois, relevé en main. Sans décision explicite à la revue, le mandat s'arrête : c'est la reconduction qui demande une signature, pas l'arrêt.
· Retrait : un mot, et l'exécution directe cesse dans la minute. Tout repasse en dossier à déclencher, rien d'autre ne change.
Ce que ça vaut, sur vos propres chiffres : 148 incidents de nuit le trimestre dernier, dont 96 relèvent des six actions. Le rétablissement passerait de 3 h 10 à 4 minutes. Vos 31 dépassements de l'engagement de 4 heures de l'an dernier — 1 200 € de pénalité chacun, 37 200 € — tombent à 6 sur la simulation : 30 000 € qui restent chez vous.
Et la décision reste entière : 0 action déclenchée sans décision humaine — le mandat EST cette décision, écrite d'avance, datée, et le journal la relie à chaque exécution. Signez-le et la première nuit couverte est celle de vendredi. mandat-d-execution_6-actions-plafonne.pdf96 nuits couvertes sur 148, 30 000 € de pénalités évitées
✎ Cadre · mandat rédigé, 1 240 exécutions historiques des 6 actions, 148 incidents de nuit du trimestre, pénalités contractuelles de l'exercice
Et si l'une de ces six actions se passe mal à 3 h du matin ?
Elle se rattrape en 40 secondes, et je vous le dis avec un chiffre plutôt qu'avec une promesse : les six retours arrière ont été essayés à blanc 96 fois sur votre environnement de recette, 96 fois réussis, 40 secondes en moyenne.
Comment une exécution se déroule, minute par minute :
· J'exécute l'action et j'ouvre un point de contrôle 90 secondes plus tard, sur l'indicateur propre à l'action — temps de réponse, file d'attente, taux d'erreur.
· Au vert : l'incident est clos, et le relevé du matin vous dit ce qui s'est passé, sur quel précédent, avec les mesures avant et après.
· Autrement : retour arrière immédiat, environnement rendu à son état exact d'avant, puis appel de l'astreinte avec le dossier complet — chronologie, hypothèses classées, ce qui a été tenté. Votre ingénieur arrive à une question, pas à une page blanche.
Ce que ça donne sur l'essai de trois semaines que je vous propose : trois environnements pilotes, choisis parmi ceux dont le contrat n'a pas de clause de pénalité, relevé chaque matin à 7 h sur votre écran. Vous jugez sur 21 nuits et 20 minutes de lecture par jour au total.
Et ce que l'essai vous apporte même s'il ne va pas plus loin : les six retours arrière écrits et éprouvés restent à vous — vos ingénieurs les exécutent à la main en 40 secondes, avec ou sans moi. Dites-moi les trois environnements et l'essai commence vendredi.
⛓ Sourcé · 96 essais de retour arrière sur l'environnement de recette, indicateurs de contrôle par action, contrats des environnements pilotes
Comment une exécution se déroule, minute par minute :
· J'exécute l'action et j'ouvre un point de contrôle 90 secondes plus tard, sur l'indicateur propre à l'action — temps de réponse, file d'attente, taux d'erreur.
· Au vert : l'incident est clos, et le relevé du matin vous dit ce qui s'est passé, sur quel précédent, avec les mesures avant et après.
· Autrement : retour arrière immédiat, environnement rendu à son état exact d'avant, puis appel de l'astreinte avec le dossier complet — chronologie, hypothèses classées, ce qui a été tenté. Votre ingénieur arrive à une question, pas à une page blanche.
Ce que ça donne sur l'essai de trois semaines que je vous propose : trois environnements pilotes, choisis parmi ceux dont le contrat n'a pas de clause de pénalité, relevé chaque matin à 7 h sur votre écran. Vous jugez sur 21 nuits et 20 minutes de lecture par jour au total.
Et ce que l'essai vous apporte même s'il ne va pas plus loin : les six retours arrière écrits et éprouvés restent à vous — vos ingénieurs les exécutent à la main en 40 secondes, avec ou sans moi. Dites-moi les trois environnements et l'essai commence vendredi.
⛓ Sourcé · 96 essais de retour arrière sur l'environnement de recette, indicateurs de contrôle par action, contrats des environnements pilotes
Trois causes produisent 1 460 de vos 7 400 incidents annuels — 19,7 % de votre charge — et les trois se corrigent une fois pour toutes.
Une cause racine, c'est le fait qui produit l'incident ; le symptôme, c'est ce que le client observe. On traite le symptôme tous les jours, on traite la cause une fois.
Les trois, chiffrées sur cinq ans de tickets :
· Le traitement d'agrégation programmé pendant les heures d'ouverture : 620 incidents par an. Il concerne les 11 environnements décalés à 7 h 45, et il se corrige par un changement de programmation — 2 jours de développement, aucune reprise de données.
· Le quota de journalisation resté à sa valeur d'origine : 510 incidents par an, sur 6 environnements. La correction tient en un réglage et une alerte à 80 % du quota — 3 jours de développement.
· Les certificats d'interface qui expirent sans prévenir : 330 incidents par an. La correction est une surveillance des échéances à 30 jours — 4 jours de développement.
Ce que ces 1 460 incidents vous coûtent aujourd'hui : 1 460 × 38 minutes = 924 heures d'ingénieur par an, sans compter les 9 dépassements d'engagement contractuel qu'ils ont provoqués l'an dernier.
Ce que je remets au directeur technique : les trois corrections chiffrées en jours de développement d'un côté, en incidents évités et en heures rendues de l'autre — 9 jours de développement contre 924 heures par an.
Le pas suivant que je propose : commencer par le quota de journalisation. C'est la deuxième en volume mais la première en rapport effort-effet : 3 jours de développement pour 323 heures par an, et elle est la seule des trois qui ne demande aucune fenêtre chez le client. Donnez-moi votre accord et je monte la demande de changement au format de votre comité, chiffrage compris. causes-recurrentes_1460-incidents-par-an.pdf9 jours de développement contre 924 heures par an
⛓ Sourcé · 5 ans de tickets classés par cause, relevé de configuration des 214 environnements, journal des dépassements d'engagement
Une cause racine, c'est le fait qui produit l'incident ; le symptôme, c'est ce que le client observe. On traite le symptôme tous les jours, on traite la cause une fois.
Les trois, chiffrées sur cinq ans de tickets :
· Le traitement d'agrégation programmé pendant les heures d'ouverture : 620 incidents par an. Il concerne les 11 environnements décalés à 7 h 45, et il se corrige par un changement de programmation — 2 jours de développement, aucune reprise de données.
· Le quota de journalisation resté à sa valeur d'origine : 510 incidents par an, sur 6 environnements. La correction tient en un réglage et une alerte à 80 % du quota — 3 jours de développement.
· Les certificats d'interface qui expirent sans prévenir : 330 incidents par an. La correction est une surveillance des échéances à 30 jours — 4 jours de développement.
Ce que ces 1 460 incidents vous coûtent aujourd'hui : 1 460 × 38 minutes = 924 heures d'ingénieur par an, sans compter les 9 dépassements d'engagement contractuel qu'ils ont provoqués l'an dernier.
Ce que je remets au directeur technique : les trois corrections chiffrées en jours de développement d'un côté, en incidents évités et en heures rendues de l'autre — 9 jours de développement contre 924 heures par an.
Le pas suivant que je propose : commencer par le quota de journalisation. C'est la deuxième en volume mais la première en rapport effort-effet : 3 jours de développement pour 323 heures par an, et elle est la seule des trois qui ne demande aucune fenêtre chez le client. Donnez-moi votre accord et je monte la demande de changement au format de votre comité, chiffrage compris. causes-recurrentes_1460-incidents-par-an.pdf9 jours de développement contre 924 heures par an
⛓ Sourcé · 5 ans de tickets classés par cause, relevé de configuration des 214 environnements, journal des dépassements d'engagement
Le comité technique va vouloir savoir ce qu'on gagne en euros, pas en heures. C'est la question qui revient à chaque arbitrage.
La note est écrite dans le format de votre comité, et elle donne les deux — les heures et les euros, avec le calcul en clair sous chaque chiffre.
Ce que les 924 heures valent, avec votre propre coût horaire chargé de 48 € : 44 352 € de capacité d'ingénierie par an, immobilisés à refaire trois fois par jour le même geste.
Ce que les dépassements ajoutent : 9 dépassements imputables à ces trois causes, 1 200 € de pénalité chacun — 10 800 €, et ceux-là sortent de votre marge, pas de votre planning.
Ce que les trois corrections coûtent : 9 jours de développement, soit 4 320 € au même coût horaire.
Le rapport, et il se vérifie en deux lignes : 4 320 € engagés une fois contre 55 152 € par an — l'investissement est remboursé en 29 jours.
Ce que j'ai ajouté et que le comité demandera : le nombre de tickets par mois sur les six mois qui suivront chaque correction, relevé automatiquement, pour que la promesse se vérifie au lieu de se croire. Si une correction ne produit pas la baisse annoncée, vous le saurez au troisième mois, pas à l'audit de fin d'année.
Et un chiffre pour situer l'ensemble : le quota de journalisation seul : 15 504 € de charge évitée pour cette cause, à rapporter à 6 792 € d'abonnement annuel.
Le pas suivant : la note tient en un recto et je vous la remets ce soir pour le comité de jeudi. Un chiffre lu la veille se discute mieux qu'un chiffre découvert en séance.
⛓ Sourcé · coût horaire chargé communiqué par le contrôle de gestion, pénalités de l'exercice, chiffrage de développement de l'équipe produit
Ce que les 924 heures valent, avec votre propre coût horaire chargé de 48 € : 44 352 € de capacité d'ingénierie par an, immobilisés à refaire trois fois par jour le même geste.
Ce que les dépassements ajoutent : 9 dépassements imputables à ces trois causes, 1 200 € de pénalité chacun — 10 800 €, et ceux-là sortent de votre marge, pas de votre planning.
Ce que les trois corrections coûtent : 9 jours de développement, soit 4 320 € au même coût horaire.
Le rapport, et il se vérifie en deux lignes : 4 320 € engagés une fois contre 55 152 € par an — l'investissement est remboursé en 29 jours.
Ce que j'ai ajouté et que le comité demandera : le nombre de tickets par mois sur les six mois qui suivront chaque correction, relevé automatiquement, pour que la promesse se vérifie au lieu de se croire. Si une correction ne produit pas la baisse annoncée, vous le saurez au troisième mois, pas à l'audit de fin d'année.
Et un chiffre pour situer l'ensemble : le quota de journalisation seul : 15 504 € de charge évitée pour cette cause, à rapporter à 6 792 € d'abonnement annuel.
Le pas suivant : la note tient en un recto et je vous la remets ce soir pour le comité de jeudi. Un chiffre lu la veille se discute mieux qu'un chiffre découvert en séance.
⛓ Sourcé · coût horaire chargé communiqué par le contrôle de gestion, pénalités de l'exercice, chiffrage de développement de l'équipe produit
Notre directeur voudrait aussi un classement des ingénieurs par temps de résolution. Vous savez faire ?
Je sais le faire, et je vous le produis avec ce qu'il faut pour qu'il soit régulier — mais laissez-moi d'abord vous montrer ce que vos propres chiffres disent de cet indicateur, parce qu'ils sont éloquents.
Ce que l'historique de Norvic montre : pendant les trois mois de 2024 où un objectif de temps de résolution a été affiché en salle, le temps moyen est passé de 38 à 31 minutes — et les réouvertures de tickets sont passées de 14 % à 23 %. L'indicateur s'est amélioré, le service s'est dégradé : un ticket fermé en 31 minutes qui rouvre deux jours plus tard coûte deux fois le temps et une fois la confiance du client.
Ce que je vous propose à la place, et c'est déjà produit : la charge par famille d'incidents et par créneau horaire. Elle montre un déséquilibre que personne n'avait vu : 41 % de vos incidents arrivent entre 7 h et 9 h 30, quand 2 de vos 11 ingénieurs sont en poste. Décaler deux prises de poste d'une heure ramènerait le délai de première réponse du matin de 47 à 18 minutes — sans embaucher personne, et c'est le levier que le classement individuel n'aurait jamais donné.
Et si le directeur maintient sa demande, je la sers : l'indicateur individuel se produit dès lors que les personnes concernées en sont informées au préalable, que la mesure est proportionnée au but poursuivi et que le comité social et économique est consulté avant la mise en œuvre — vous en avez un, l'entreprise compte 96 salariés. Je vous apporte les trois pièces prêtes ; la décision appartient à la direction, et elle se prend en connaissance de cause.
Une seule chose ne se fait pas, et ce n'est pas de la prudence : déduire l'état émotionnel ou le stress d'un ingénieur à partir de ses tickets — le règlement européen sur l'intelligence artificielle interdit l'inférence des émotions au travail. Ce que le directeur cherche derrière cette idée, je le lui donne autrement et mieux : la charge réelle par créneau, les pics d'astreinte et les nuits enchaînées, mesurés sur douze mois. Les deux ingénieurs d'astreinte ont enchaîné 4 nuits d'affilée à sept reprises l'an dernier : c'est ce chiffre-là qui explique vos délais du matin, et il est sur la table.
Le pas suivant : les deux prises de poste décalées à l'essai sur un mois, relevé hebdomadaire. Vous saurez au bout de quatre semaines si les 29 minutes du matin sont au rendez-vous. indicateurs-de-support_ce-qui-se-mesure.pdf41 % des incidents entre 7 h et 9 h 30, 47 minutes ramenées à 18
⛓ Sourcé · historique des 3 mois à objectif affiché (2024), réouvertures, répartition horaire des 7 400 incidents, planning d'astreinte sur 12 mois
Ce que l'historique de Norvic montre : pendant les trois mois de 2024 où un objectif de temps de résolution a été affiché en salle, le temps moyen est passé de 38 à 31 minutes — et les réouvertures de tickets sont passées de 14 % à 23 %. L'indicateur s'est amélioré, le service s'est dégradé : un ticket fermé en 31 minutes qui rouvre deux jours plus tard coûte deux fois le temps et une fois la confiance du client.
Ce que je vous propose à la place, et c'est déjà produit : la charge par famille d'incidents et par créneau horaire. Elle montre un déséquilibre que personne n'avait vu : 41 % de vos incidents arrivent entre 7 h et 9 h 30, quand 2 de vos 11 ingénieurs sont en poste. Décaler deux prises de poste d'une heure ramènerait le délai de première réponse du matin de 47 à 18 minutes — sans embaucher personne, et c'est le levier que le classement individuel n'aurait jamais donné.
Et si le directeur maintient sa demande, je la sers : l'indicateur individuel se produit dès lors que les personnes concernées en sont informées au préalable, que la mesure est proportionnée au but poursuivi et que le comité social et économique est consulté avant la mise en œuvre — vous en avez un, l'entreprise compte 96 salariés. Je vous apporte les trois pièces prêtes ; la décision appartient à la direction, et elle se prend en connaissance de cause.
Une seule chose ne se fait pas, et ce n'est pas de la prudence : déduire l'état émotionnel ou le stress d'un ingénieur à partir de ses tickets — le règlement européen sur l'intelligence artificielle interdit l'inférence des émotions au travail. Ce que le directeur cherche derrière cette idée, je le lui donne autrement et mieux : la charge réelle par créneau, les pics d'astreinte et les nuits enchaînées, mesurés sur douze mois. Les deux ingénieurs d'astreinte ont enchaîné 4 nuits d'affilée à sept reprises l'an dernier : c'est ce chiffre-là qui explique vos délais du matin, et il est sur la table.
Le pas suivant : les deux prises de poste décalées à l'essai sur un mois, relevé hebdomadaire. Vous saurez au bout de quatre semaines si les 29 minutes du matin sont au rendez-vous. indicateurs-de-support_ce-qui-se-mesure.pdf41 % des incidents entre 7 h et 9 h 30, 47 minutes ramenées à 18
⛓ Sourcé · historique des 3 mois à objectif affiché (2024), réouvertures, répartition horaire des 7 400 incidents, planning d'astreinte sur 12 mois
Un trimestre : 2 580 heures d'ingénierie rendues sur l'année, et le calcul est le vôtre — il tient en trois lignes que vous pouvez refaire.
Les trois postes que vous mesuriez, poste par poste :
· Recherche des incidents comparables : 60 % → 7 % du temps de l'incident, 23 minutes ramenées à 2 minutes 40, sur 4 900 incidents par an — 1 660 heures.
· Analyse de la configuration concernée : 35 % → 6 %, 13 minutes ramenées à 2 minutes 15, sur 2 600 incidents — 466 heures.
· Préparation de l'action de résolution : 30 % → 7 %, 11 minutes 30 ramenées à 2 minutes 40, sur 3 100 incidents — 456 heures.
Ce que ça vaut à votre coût horaire chargé de 48 € : 123 840 € de capacité d'ingénierie rendue par an, pour 6 792 € d'abonnement annuel. Le rapport se recalcule sur vos propres relevés.
Ce que ces heures sont devenues, d'après vos plannings : les trois corrections de fond sont engagées, 180 tickets par mois sont désormais résolus au premier niveau, et vos deux experts ont repris les deux chantiers d'architecture repoussés depuis dix-huit mois.
Les trois mesures que vos clients regardent :
· Réouvertures de tickets : 14 % → 6 %.
· Dépassements de l'engagement de 4 heures : 31 l'an dernier → 6 sur douze mois glissants, soit 30 000 € de pénalités qui restent chez vous.
· Délai avant première action sur un incident majeur de nuit : 3 h 10 → 4 minutes sur les 96 nuits couvertes par le mandat.
Le pas suivant que je propose : le même relevé, client par client, à joindre à vos revues de contrat. Sur les 9 clients qui imposent l'hébergement en France, c'est la page qui décide un renouvellement — et elle est déjà écrite pour les trois revues du mois prochain. bilan-du-trimestre_2580-heures-rendues.pdf60→7, 35→6, 30→7, et le calcul refaisable en un recto
⛓ Sourcé · journal des diagnostics du trimestre, plannings du support, relevé des pénalités, tickets rouverts
Les trois postes que vous mesuriez, poste par poste :
· Recherche des incidents comparables : 60 % → 7 % du temps de l'incident, 23 minutes ramenées à 2 minutes 40, sur 4 900 incidents par an — 1 660 heures.
· Analyse de la configuration concernée : 35 % → 6 %, 13 minutes ramenées à 2 minutes 15, sur 2 600 incidents — 466 heures.
· Préparation de l'action de résolution : 30 % → 7 %, 11 minutes 30 ramenées à 2 minutes 40, sur 3 100 incidents — 456 heures.
Ce que ça vaut à votre coût horaire chargé de 48 € : 123 840 € de capacité d'ingénierie rendue par an, pour 6 792 € d'abonnement annuel. Le rapport se recalcule sur vos propres relevés.
Ce que ces heures sont devenues, d'après vos plannings : les trois corrections de fond sont engagées, 180 tickets par mois sont désormais résolus au premier niveau, et vos deux experts ont repris les deux chantiers d'architecture repoussés depuis dix-huit mois.
Les trois mesures que vos clients regardent :
· Réouvertures de tickets : 14 % → 6 %.
· Dépassements de l'engagement de 4 heures : 31 l'an dernier → 6 sur douze mois glissants, soit 30 000 € de pénalités qui restent chez vous.
· Délai avant première action sur un incident majeur de nuit : 3 h 10 → 4 minutes sur les 96 nuits couvertes par le mandat.
Le pas suivant que je propose : le même relevé, client par client, à joindre à vos revues de contrat. Sur les 9 clients qui imposent l'hébergement en France, c'est la page qui décide un renouvellement — et elle est déjà écrite pour les trois revues du mois prochain. bilan-du-trimestre_2580-heures-rendues.pdf60→7, 35→6, 30→7, et le calcul refaisable en un recto
⛓ Sourcé · journal des diagnostics du trimestre, plannings du support, relevé des pénalités, tickets rouverts
Et le revers ? Vous ne vous êtes jamais trompé en trois mois ?
Si, et je le publie avec le reste : sur les 620 diagnostics du premier mois, 47 ont désigné le mauvais précédent — 7,6 %. C'est le chiffre qui ne me flatte pas, et il vaut mieux que vous l'ayez de moi.
La cause réelle, mesurée et non supposée : 38 des 47 portaient sur des environnements dont la fiche de configuration n'avait pas été reprise après une migration. Je lisais fidèlement un dépôt qui décrivait l'environnement d'avant. Les 9 autres portaient sur des symptômes proches appartenant à deux familles différentes.
Ce que j'en ai fait, et c'est mesuré : je lis désormais l'état réel de l'environnement au moment du diagnostic, et non la fiche déposée ; les 214 fiches de configuration ont été réécrites à partir du relevé ; et les deux familles trop proches ont été scindées en quatre, avec le critère qui les sépare en première ligne.
Le mois suivant : 9 diagnostics à reprendre sur 640 — 1,4 %.
Et le point qui compte le plus pour votre responsabilité : aucun de ces 47 n'a produit d'action erronée sur un environnement client. Un diagnostic arrive avec ses trois précédents cités et le point commun de configuration : un ingénieur écarte un mauvais rapprochement en 40 secondes — c'est exactement ce que la citation des précédents sert à faire, et c'est pourquoi elle n'est pas négociable.
La mesure de cadre, sur le trimestre : 1 860 diagnostics établis, 1 860 lus par une personne, 0 action déclenchée sans décision humaine, et 0 donnée d'incident sortie du réseau.
Le pas suivant : que les 9 reprises du deuxième mois deviennent 9 critères de séparation de plus, écrits, à votre relecture. Sur les quatre premières semaines du trimestre en cours, 7 des 9 auraient déjà servi. diagnostics-repris_47-puis-9.pdf7,6 % → 1,4 %, cause mesurée, 0 action erronée
⛓ Sourcé · journal des diagnostics et de leurs reprises sur deux mois, relevé des 214 environnements, familles scindées
La cause réelle, mesurée et non supposée : 38 des 47 portaient sur des environnements dont la fiche de configuration n'avait pas été reprise après une migration. Je lisais fidèlement un dépôt qui décrivait l'environnement d'avant. Les 9 autres portaient sur des symptômes proches appartenant à deux familles différentes.
Ce que j'en ai fait, et c'est mesuré : je lis désormais l'état réel de l'environnement au moment du diagnostic, et non la fiche déposée ; les 214 fiches de configuration ont été réécrites à partir du relevé ; et les deux familles trop proches ont été scindées en quatre, avec le critère qui les sépare en première ligne.
Le mois suivant : 9 diagnostics à reprendre sur 640 — 1,4 %.
Et le point qui compte le plus pour votre responsabilité : aucun de ces 47 n'a produit d'action erronée sur un environnement client. Un diagnostic arrive avec ses trois précédents cités et le point commun de configuration : un ingénieur écarte un mauvais rapprochement en 40 secondes — c'est exactement ce que la citation des précédents sert à faire, et c'est pourquoi elle n'est pas négociable.
La mesure de cadre, sur le trimestre : 1 860 diagnostics établis, 1 860 lus par une personne, 0 action déclenchée sans décision humaine, et 0 donnée d'incident sortie du réseau.
Le pas suivant : que les 9 reprises du deuxième mois deviennent 9 critères de séparation de plus, écrits, à votre relecture. Sur les quatre premières semaines du trimestre en cours, 7 des 9 auraient déjà servi. diagnostics-repris_47-puis-9.pdf7,6 % → 1,4 %, cause mesurée, 0 action erronée
⛓ Sourcé · journal des diagnostics et de leurs reprises sur deux mois, relevé des 214 environnements, familles scindées
Dernière question, celle qui décidera le comité : qu'est-ce que vous faites sans nous demander, et comment on sort si on veut sortir ?
Trois gestes sans vous demander, six actions sous mandat signé, et une sortie qui se vérifie avant de s'engager plutôt qu'après.
Les trois gestes, et chacun se retire d'un mot :
· Je relis vos journaux et vos tickets chaque nuit : un incident clos aujourd'hui est un précédent citable demain. Et l'inverse est vrai aussi : un ticket que vous supprimez sort de l'index à la même heure — je ne garde pas la copie de ce que vous avez décidé d'effacer.
· J'écris la version à jour de toute fiche qu'une montée de version rend caduque, la nuit qui suit la mise en production. C'est ce geste qui a fait passer les diagnostics à reprendre de 7,6 % à 1,4 %.
· Je vous remets le relevé du matin à 7 h : incidents de la nuit, actions exécutées sous mandat, échéances de certificats à trente jours. C'est le seul envoi que je fasse de moi-même.
Ce qui reste à une personne, et c'est ce qui donne leur valeur à vos interventions : toute action hors des six du mandat · toute intervention sur un environnement retiré de la liste · toute correction de fond, qui passe par votre comité technique · et tout indicateur nominatif, produit sur décision de la direction, conditions remplies. Sur le trimestre : 1 860 diagnostics, 1 860 décisions humaines.
La sortie, puisque c'est elle qui décide un comité : aucune migration à l'entrée, donc aucune à la sortie. Votre outil de tickets, votre supervision et votre dépôt de configurations ne sont pas remplacés, l'index se supprime et ne contenait aucun de vos tickets — seulement de quoi les retrouver là où ils sont, et les 120 fiches réécrites, les 214 fiches de configuration, les 6 retours arrière éprouvés et la grille des causes récurrentes restent à vous, lisibles sans nous. C'est le patrimoine que ce trimestre a créé, et il ne serait pas honnête qu'il reste chez nous.
Ce que je propose pour que ce ne soit pas une phrase : un essai de sortie à blanc au bout du premier trimestre, une demi-journée — on coupe, on vérifie que le support fonctionne exactement comme avant, on remet en service. Le protocole est écrit et le créneau qui vous coûte le moins est le mardi de la semaine 3 : c'est votre creux d'incidents depuis cinq ans, 9 tickets en moyenne. Le comité saura ce que vaut la promesse avant d'avoir engagé une deuxième année. cadre-technique_ou-vivent-vos-configurations.pdfRéversibilité : 0 migration à l'entrée, 0 à la sortie
✎ Cadre · paramétrage des gestes automatiques, journal des décisions, protocole d'essai de sortie, formats d'export
Les trois gestes, et chacun se retire d'un mot :
· Je relis vos journaux et vos tickets chaque nuit : un incident clos aujourd'hui est un précédent citable demain. Et l'inverse est vrai aussi : un ticket que vous supprimez sort de l'index à la même heure — je ne garde pas la copie de ce que vous avez décidé d'effacer.
· J'écris la version à jour de toute fiche qu'une montée de version rend caduque, la nuit qui suit la mise en production. C'est ce geste qui a fait passer les diagnostics à reprendre de 7,6 % à 1,4 %.
· Je vous remets le relevé du matin à 7 h : incidents de la nuit, actions exécutées sous mandat, échéances de certificats à trente jours. C'est le seul envoi que je fasse de moi-même.
Ce qui reste à une personne, et c'est ce qui donne leur valeur à vos interventions : toute action hors des six du mandat · toute intervention sur un environnement retiré de la liste · toute correction de fond, qui passe par votre comité technique · et tout indicateur nominatif, produit sur décision de la direction, conditions remplies. Sur le trimestre : 1 860 diagnostics, 1 860 décisions humaines.
La sortie, puisque c'est elle qui décide un comité : aucune migration à l'entrée, donc aucune à la sortie. Votre outil de tickets, votre supervision et votre dépôt de configurations ne sont pas remplacés, l'index se supprime et ne contenait aucun de vos tickets — seulement de quoi les retrouver là où ils sont, et les 120 fiches réécrites, les 214 fiches de configuration, les 6 retours arrière éprouvés et la grille des causes récurrentes restent à vous, lisibles sans nous. C'est le patrimoine que ce trimestre a créé, et il ne serait pas honnête qu'il reste chez nous.
Ce que je propose pour que ce ne soit pas une phrase : un essai de sortie à blanc au bout du premier trimestre, une demi-journée — on coupe, on vérifie que le support fonctionne exactement comme avant, on remet en service. Le protocole est écrit et le créneau qui vous coûte le moins est le mardi de la semaine 3 : c'est votre creux d'incidents depuis cinq ans, 9 tickets en moyenne. Le comité saura ce que vaut la promesse avant d'avoir engagé une deuxième année. cadre-technique_ou-vivent-vos-configurations.pdfRéversibilité : 0 migration à l'entrée, 0 à la sortie
✎ Cadre · paramétrage des gestes automatiques, journal des décisions, protocole d'essai de sortie, formats d'export
Inférence locale · traitements dans l'UE visés
Votre cas n'est pas ici ? C'est exactement ce dont on parle en 15 minutes. Réserver l'audit gratuit →
Cas d'usage
Que fait l'agent concrètement ?
Un agent, plusieurs étapes du traitement d'un incident. Tous ces usages fonctionnent en appui, sous votre validation.
Inclus dans votre agent
Les 4 capacités essentielles à cette promesse sont comprises, sans surcoût.
À partir de 566 € HT / mois
Diagnostic documenté
Rapproche le symptôme des incidents comparables de votre base.
Analyse de configuration
Indique les points communs entre la configuration concernée et les précédents.
Actions préparées
Prépare l'action déjà validée pour ce type de cas, avec ses prérequis.
Support & documentation
Pour les questions documentaires du support, un agent dédié plus léger suffit.
Contrôles et garanties
Ces 6 contrôles sont intégrés à l'agent : ils encadrent ce qu'il fait, quelle que soit la formule retenue. Ils ne se choisissent pas et ne s'ajoutent pas à votre commande.
Validation humaine, exceptions et escalade
Statut, clôture sûre et traçabilité
Sources, droits d’accès et gestion de l’absence de réponse
Accéder au contexte technique avec permissions minimales
Exécuter tests, analyse de sécurité et revue humaine avant changement
Versionner, journaliser, revenir en arrière et mesurer la qualité
Autres besoins couverts par nos agents
Chaque carte indique où en est l'agent correspondant : disponible, sur devis, ou encore en cours d'architecture.
Informatique & technologies
Pour l'ensemble des enjeux du secteur, découvrez notre page dédiée.
Sur devis Voir la fiche →
Votre besoin sort du cadre ?
Réserver l'audit gratuit →
Composer votre agent
En 15 minutes, nous identifions l'agent le plus pertinent — sans surdimensionner le projet.
Le gain
Combien d'incidents une équipe peut-elle traiter au fond ?
En prenant en charge la recherche de précédents, on déplace l'effort vers la résolution et la prévention. L'ampleur du gain dépend de votre volume et reste à confirmer par un pilote.
Recherche des incidents comparables
Analyse de la configuration concernée
Préparation de l'action de résolution
Repères illustratifs, non contractuels, à confirmer par un pilote sur le volume d'incidents et la richesse de votre base technique. Déclencher une intervention sur un système en production porte à conséquence : cette décision appartient au support technique.
Comment ça se passe
Les étapes de votre projet d'agent IA
1
Audit & cadrage
15 min pour cibler le cas d'usage le plus rentable.
2
Devis ou souscription directe
Une offre du catalogue se souscrit en ligne ; un besoin particulier reçoit un devis chiffré.
3
Conception
Nous concevons l'agent et ses garde-fous.
4
Intégration & tests
Nous raccordons vos outils à l'agent, lui-même hébergé en France.
5
Déploiement
Mise en service et formation de votre équipe.
6
Exploitation
Supervision continue et amélioration.
Tarifs
Une formule, un seul agent
Un agent de support technique avancé (diagnostic, précédents, actions), installé et exploité pour vous. Tarifs HT — abonnement annuel, le temps que les gains s'installent durablement.
Agilité
Installation + abonnement maîtrisé
5 625 € HT de mise en service
puis 566 € HT/mois — vous investissez à l'installation et payez un abonnement réduit. Idéal pour maîtriser le coût dans la durée.
- Installation, paramétrage et formation de vos équipes
- Exploitation, supervision humaine, mises à jour et support
- Hébergement souverain en France, ressource dédiée et isolée
Le plus simple
Sérénité
Tout inclus, sans frais d'installation
881 € HT /mois
tout compris, démarrage immédiat. Aucun investissement de départ : un abonnement unique. Idéal pour démarrer vite, en toute simplicité.
- Mise en service incluse (installation, paramétrage, formation)
- Exploitation, supervision humaine, mises à jour et support
- Hébergement souverain en France, géré de bout en bout
100 % Souverain
Sur site, vous êtes propriétaire
9 060 € HT de mise en service
puis 766 € HT/mois · + matériel dès 2 491 € (achat unique, en sus) — ordinateur souverain installé chez vous, maintenu à distance. Modèles en local, vos données restituées à la fin du contrat. Engagement 36 mois.
- Matériel installé dans vos locaux (vous en êtes propriétaire)
- Modèles IA français / européens exécutés en local
- Maintenance à distance sécurisée (Suivi Pro inclus)
Non inclus dans les formules : la consommation d'IA (jetons « tokens » des modèles), refacturée au coût réel, sans marge, et suivie en temps réel dans votre espace client. Abonnement de maintenance et de supervision sur une durée initiale de 12 mois pour la formule Agilité, de 24 mois pour la formule Sérénité et de 36 mois pour la formule 100 % Souverain, renouvelable ; niveaux de Suivi (SLA 72 h / 24 h / 4 h) en option. Les développements sur-mesure, intégrations supplémentaires ou volumétries exceptionnelles font l'objet d'un devis. Support du lundi au vendredi, de 9h à 18h. Tarifs hors taxes (HT).
Modèle d'IA :
aucun des modèles d'IA proposés n'entraîne aujourd'hui de supplément fixe. Lorsque le modèle retenu entraîne un coût, ce coût est indiqué au moment du choix, avant la commande, et refacturé au coût constaté, sans marge ; la consommation est facturée au prix de l'éditeur. Les prix des éditeurs sont publiés en dollars américains : le montant refacturé est le montant en euros effectivement supporté par Blue Lemon Agent sur la facture de l'éditeur, au taux de cette facture, sans commission ni majoration.
Composants inclus et composants complémentaires Composants inclus dans l'offre de base : le socle logiciel Blue Lemon Agent, les modèles d'IA de la liste du tunnel de commande, les canaux standards (Microsoft Teams, Slack, WhatsApp Business, courriel, chat du site, agendas, Microsoft 365 / Google Workspace, stockage de fichiers, téléphonie sur IP du marché, pages et comptes professionnels des réseaux sociaux, fiche d'établissement Google), l'hébergement en France de la formule choisie, les sauvegardes, la supervision, les mises à jour et le support. Si l'adaptation de l'agent IA à vos contraintes, à vos besoins ou à vos demandes exige la mise en place d'autres composants payants — licence logicielle d'un éditeur tiers, accès API payant à l'un de vos logiciels, hébergement de données de santé, qui impose en France un hébergeur certifié HDS (art. L. 1111-8 du Code de la santé publique), hébergement qualifié SecNumCloud, service de synthèse vocale, matériel particulier —, ils vous sont proposés en option ou sur devis et refacturés au coût constaté ; rien n'est engagé sans votre accord écrit. Lorsque le modèle d'intelligence artificielle que vous retenez entraîne un coût supplémentaire, ce coût vous est indiqué avant votre commande et vous est refacturé au coût constaté, sans marge.
Ce que vous pouvez attendre
Mise en service
2 à 3 semaines
Agent conçu, canaux raccordés, équipe formée.
Régime nominal
4 à 7 semaines
Après quelques semaines d'usage réel, le temps que le comportement de l'agent soit ajusté à ce que vous attendez.
Estimation indicative, ajustée selon les options que vous retenez. Elle n'est pas un engagement de délai.
Notre engagement
Quatre garanties qui comptent pour votre support
Vos configurations restent chez vousInférence locale ou ressource isolée hébergée en France ; aucune configuration ni donnée d'incident confiée à un tiers, aucune donnée utilisée pour entraîner un modèle.
Données en France, sous droit françaisVos configurations et vos données d'incidents : minimisation et localisation en France, architecture conçue pour réduire l'exposition aux législations extraterritoriales, la localisation ne garantissant pas à elle seule l'immunité.
Le support technique garde la décisionL'agent produit des diagnostics documentés et des actions préparées, vérifiable et modifiable ; aucune validation n'est automatisée.
Supervision humaine & traçabilitéSur le volume d'incidents et la richesse de votre base technique : journalisation et suivi systématiques, conformes à l'AI Act.
Aller plus loin
Ressources liées
Questions fréquentes
Vos questions, nos réponses
L'agent applique-t-il les correctifs ?
Non. Il prépare l'action avec ses prérequis et son ordre d'exécution ; le déclenchement sur un système en production appartient au support technique.
D'où viennent les diagnostics ?
De votre base technique et de votre historique d'incidents. Chaque diagnostic cite les cas comparables sur lesquels il s'appuie.
Que fait-il d'un incident sans précédent ?
Il présente les éléments recueillis et les configurations concernées, et signale l'absence de cas comparable — ce qui oriente directement le travail d'analyse.
Quelle différence avec un agent de tickets ?
Un agent de tickets qualifie et route les demandes ; celui-ci établit un diagnostic technique documenté et prépare l'action de résolution.
Nos configurations sont-elles protégées ?
Oui. L'agent est hébergé en France, en inférence locale ou en ressource isolée, avec pour objectif de déploiement des traitements et des accès opérés dans l'Union européenne et une architecture conçue pour réduire l'exposition aux législations extraterritoriales, la localisation ne garantissant pas à elle seule l'immunité. Vos données ne servent pas à entraîner un modèle tiers.
Combien de temps pour déployer cet agent ?
Quelques mois en général, selon le volume d'incidents et la richesse de votre base technique, après un audit gratuit puis des phases de conception, d'intégration et de tests.
Cas d'usage liés
D'autres agents pour l'informatique
Parlons-en
Estimons le potentiel sur votre support technique
15 minutes pour cadrer vos incidents et votre base technique — hébergé en France, supervisé, sans engagement.