Aller au contenu
datapredictToutes les
démonstrations

Une expérience d’IA sur une station locale

Spécialiser un LLM local
pour qualifier des incidents informatiques

Lire un dossier, préparer une fiche et retrouver les passages qui justifient chaque réponse.

Un modèle de langage, ou LLM, est un logiciel capable de lire et de produire du texte. Ici, il fonctionne sur notre station. Il aide une équipe informatique à comprendre un incident : quel service est touché, quelle est la nature du problème, qui est concerné et quand faut-il intervenir ?

Vous explorez des résultats enregistrés. L’entreprise et les incidents sont inventés. Cette page ne lance aucun modèle, ne transmet aucun dossier et n’accède à aucun système informatique.

01 Comprendre la tâche

Du dossier d’incident
à une proposition vérifiable

Un signalement, un compte rendu et un échange entre équipes peuvent décrire la même panne. La difficulté consiste à en tirer une fiche cohérente, sans inventer ce qui manque ni effacer ce qui se contredit.

  1. 1. Lire les piècesL’assistant reçoit les documents d’un seul incident. Il relève les informations utiles et les passages qui les étayent.
  2. 2. Préparer et contrôlerLe modèle propose les quatre informations attendues. Des règles contrôlent la structure, les références et certains liens explicites entre les faits.
  3. 3. Laisser l’opérateur déciderLa fiche reste « à vérifier ». L’opérateur consulte les preuves, puis confirme, corrige ou rejette. Sa décision est conservée séparément.

Que signifie « entièrement conforme » ?

Une proposition ne compte comme entièrement conforme que si elle respecte le format demandé, donne les quatre informations attendues, cite les bons passages, applique la règle de choix de l’équipe à solliciter et traite correctement les informations absentes ou contradictoires.

  • Service touché
  • Nature de l’incident
  • Personnes concernées
  • Échéance
  • Preuves pertinentes
  • Inconnues et contradictions

Cette conformité est évaluée avec une grille et des réponses attendues préparées pour le test. Elle ne constitue pas une certification générale de vérité.

02 Examiner une réponse

La proposition, ses preuves
et ce qui peut encore être faux

Commencez par le dossier court. Cliquez sur une information de la fiche pour voir le passage qui la justifie. Les cas difficiles montrent aussi ce que l’assistant a proposé à tort et ce qui était attendu.

Surlignage jaune : passage cité pour le champ choisi.

La décision reste humaine

Confirmer, corriger ou rejeter : trois décisions effectivement testées

Les boutons ci-dessous affichent les traces de trois actions simulées déjà exécutées. Ils ne valident pas de nouveau dossier. Dans l’application locale, ces actions sont prises explicitement par l’opérateur.

L’entrée et la proposition initiale sont conservées. La décision, ses modifications et son horodatage sont enregistrés à part. Ces simulations ne comptent pas comme des revues humaines réelles.

03 Mesurer sans mélanger les essais

Ce que la recette démontre,
et les erreurs qu’elle laisse visibles

Le seuil était fixé à au moins 18 propositions entièrement conformes sur 20 dossiers courants. Les 10 dossiers difficiles sont évalués à part. Les scores ci-dessous portent sur la proposition initiale, avant décision opérateur.

20 dossiers courants

20/20 conformes

Le seuil de 18/20 est atteint. Ce groupe comprend les six dossiers longs du pilote.

Premier résultat
du modèle
14/20
Proposition de
l’assistant complet
20/20

10 dossiers difficiles

6/10 conformes

Quatre dossiers ne satisfont pas la grille : négations, contradictions ou preuves insuffisantes.

Premier résultat
du modèle
5/10
Proposition de
l’assistant complet
6/10

    Ce progrès vient de la chaîne applicative. La première réponse du modèle et la proposition finale proviennent des mêmes requêtes enregistrées. La chaîne complète peut inclure une réparation bornée et la vérification des preuves ; aucun nouvel apprentissage n’a eu lieu pendant cette recette.

    Conditions et portée de cette recette courte
    Ce qui a été vérifiéCe que cela permet d’affirmer
    30 demandes, 30 propositions, aucune erreur de serviceLe parcours technique a abouti pour les 30 dossiers. Cela ne rend pas les quatre propositions non conformes correctes.
    Jeu choisi et attentes figées avant l’essaiLa notation est reproductible. Les dossiers étaient déjà connus : ce test ne mesure pas la généralisation à de nouveaux incidents réels.
    Confirmation, correction et rejet simulésLes fonctions opérateur existent et la traçabilité est vérifiée. La qualité des décisions d’un utilisateur réel n’a pas encore été mesurée.
    Voir aussi le premier essai et les incidents de fonctionnement

    La première recette avait produit cinq réponses conformes, puis 25 refus immédiats : la porte d’entrée du service rejetait les dossiers pendant le refroidissement au lieu d’attendre. Deux précontrôles ont été corrigés. Les mêmes 30 dossiers ont été exécutés une fois de plus, avec le modèle, les règles de qualification et la notation inchangés.

    Les archives techniques conservent 67 demandes : six pour le pilote, une interruption volontaire, 30 pour la première recette et 30 pour la recette corrigée. Les 25 refus sont survenus avant l’inférence ; l’arrêt volontaire a interrompu une génération déjà commencée, hors recette. Ces incidents restent comptés séparément des erreurs de qualification. Le paquet public contient les 30 dossiers finaux complets, les agrégats du premier essai et le résumé de l’arrêt ; les 67 captures détaillées restent dans les archives techniques privées.

    04 Comprendre ce qui a été appris

    Donner une consigne,
    entraîner le modèle, contrôler sa réponse

    Ces trois opérations ont des effets différents. Un exemple placé dans une demande montre au modèle une manière de répondre pour cette demande. Un entraînement modifie une partie de ses paramètres. Les contrôles logiciels examinent ce qu’il a produit.

    1

    La consigne définit le travail

    On demande au modèle de remplir les quatre informations, de citer les pièces et de signaler ce qui manque. Ajouter deux exemples dans la consigne consiste à lui montrer deux dossiers déjà résolus juste avant le dossier à traiter ; cela ne modifie pas ses paramètres.

    2

    L’apprentissage lui fait pratiquer la tâche

    Le modèle reçoit des dossiers d’entraînement accompagnés de la fiche attendue. Ses réponses sont comparées à ces fiches ; un petit ensemble de paramètres supplémentaires est ajusté pour réduire les écarts. L’adaptateur ainsi obtenu est conservé et rechargé pour les demandes suivantes.

    3

    Le logiciel vérifie et prépare la décision

    Il contrôle la forme de la fiche, les passages cités et certains liens explicites. Il conserve les contradictions déjà extraites et ne transforme pas un texte non reconnu en information certaine. Ces règles restent limitées, comme le montrent les quatre dossiers difficiles non conformes.

    Que montrait la comparaison antérieure sur l’apprentissage ?

    Une expérience distincte avait comparé trois façons d’utiliser le modèle sur les mêmes 240 dossiers synthétiques, en NF4 : sans exemple dans la consigne, avec deux exemples, puis avec l’adaptateur entraîné. Elle est conservée pour comprendre la démarche, et ne sert pas de point de départ chiffré à la recette actuelle.

    MéthodeCe qui changeEntièrement conformes
    Modèle de départConsigne seule, paramètres inchangés5/240
    Deux exemples dans la demandeDeux dossiers résolus sont ajoutés au texte envoyé37/240
    Modèle spécialiséAdaptateur appris sur 600 dossiers, sans exemple ajouté à la consigne111/240

    Le progrès restait insuffisant : des erreurs critiques de preuve persistaient. Les 60 dossiers difficiles de cette expérience étaient évalués séparément. Comparer 111/240 à 20/20 serait trompeur : les dossiers, le périmètre et la chaîne applicative ne sont pas les mêmes.

    05 Attendre une fiche utilisable

    Un dossier à la fois,
    avec une attente mesurée et bornée

    La mesure va du déclenchement côté client à la réception de la fiche complète. Elle inclut le démarrage de la commande cliente et l’entrée dans le service. Les pauses de refroidissement et les contrôles font partie de ce temps.

    4,84 s

    Temps médian d’une fiche complète

    La moitié des dossiers est traitée en ce temps ou moins.
    22,35 s

    95e percentile sur les 30 dossiers

    Les pauses de refroidissement sont incluses.
    24,79 s

    Attente maximale observée

    Chaque demande dispose d’une échéance explicite.
    Temps complet de chacune des 30 demandes, dans leur ordre d’exécution. Turquoise : dossiers courants ; gris bleu : dossiers difficiles. Une barre longue peut inclure une attente de refroidissement ; elle ne signifie pas que la réponse est meilleure ou moins bonne.

    Le premier mot n’est pas la fiche

    Le premier jeton interne apparaît à un 95e percentile de 2,32 s. À ce stade, les informations et les preuves ne sont pas encore assemblées en une fiche utilisable. La latence complète ci-dessus est donc l’indicateur utile pour l’opérateur.

    Un fonctionnement local maîtrisé

    Le lancement, une demande, l’arrêt pendant une demande et le redémarrage ont été exécutés. L’arrêt volontaire a produit une erreur explicite en 6,91 s. Les processus de calcul ont ensuite été fermés.

    Le service traite un dossier à la fois. Aucun engagement de disponibilité permanente ou de débit à grande échelle n’est déduit de cette recette courte.

    Délais, refroidissement et arrêt : les détails

    Le service dispose de 120 s par demande ; la limite de capture côté client est de 135 s. Le dispositif attend lorsque l’admission est suspendue à 83 °C et reprend à 70 °C. Un arrêt de sécurité est prévu à 89 °C. Six pauses ont été enregistrées ; la température maximale observée était de 84 °C.

    Lors du test d’arrêt, le groupe de processus possédé a nécessité une fermeture forcée après cinq secondes de grâce. Cette escalade est conservée dans les preuves. Elle n’a pas visé d’autre projet ou processus.

    06 Passer de l’essai au projet

    Quelle machine,
    et pour quel coût ?

    La capacité d’exécution, la qualité des réponses et le coût sont trois sujets distincts. Cette expérience apporte des mesures sur une configuration précise et rend visibles ce qui reste à établir.

    Une RTX PRO 5000 Blackwell de 48 Go

    La configuration finale a occupé jusqu’à 39,97 Gio de mémoire GPU. Le modèle est exécuté en BF16 ; le budget du cache de travail est de 11 Gio. Les dossiers sont traités successivement.

    Le pic concerne toute la carte. Il ne permet pas de déduire la mémoire minimale nécessaire, ni les performances d’une carte de 24 ou 96 Go.

    Les 11 Gio de cache sont un budget configuré ; on ne les ajoute pas au pic de 39,97 Gio, qui les inclut déjà dans la consommation globale.

    Une mesure d’énergie, avec ses limites

    Le compteur de la carte indique 16,205 Wh sur 271,24 s observées, pour une recette d’une durée totale de 278,29 s. Les périodes sans relevé ne sont pas complétées artificiellement.

    Il s’agit de l’énergie de la carte graphique, pauses incluses. La consommation du processeur, de la mémoire, du stockage et des autres équipements n’a pas été mesurée. Les réglages de ventilation sont restés automatiques.

    La carte sait exécuter cette configuration. Les essais ne démontrent ni qu’elle est indispensable, ni qu’une carte plus puissante corrigerait les erreurs de qualification.

    Explorer un budget, en changeant les hypothèses

    Le simulateur répartit le prix d’achat, les frais annuels et le temps d’exploitation sur les heures d’utilisation choisies. Il estime ensuite leur part pour un lot de même durée que la recette, soit 278,29 s pour 30 demandes. Il s’agit d’un scénario, pas d’un devis ni d’un coût métier observé.

    Prérempli pour une petite équipe en France : station complète à 11 000 €, répartie sur quatre ans, utilisée quatre heures par jour pendant 220 jours. Tous les montants du simulateur sont hors TVA. L’électricité inclut l’accise. Les prix repérés et les hypothèses d’usage sont détaillés ci-dessous.

    Modifier l’électricité et les frais d’exploitation

    Le coût du temps de relecture des dossiers n’est pas inclus : aucun temps opérateur réel n’a été mesuré. Les 30 demandes, y compris les quatre propositions non conformes, restent dans le lot. Le scénario ne prédit pas le coût sur d’autres dossiers.

    D’où viennent les valeurs par défaut ? Prix et hypothèses

    Sources consultées le 22 octobre 2026. Les tarifs peuvent évoluer. Les liens ouvrent les sources externes uniquement si vous choisissez de les consulter.

    • Station complète : 11 000 € hors TVA. Hypothèse arrondie à partir d’un prix catalogue de 10 034,19 € hors TVA pour une Lenovo ThinkStation P3 chez Senetic Allemagne : Core Ultra 9, 128 Go de RAM, SSD 1 To et RTX PRO 5000 Blackwell 48 Go, avec service sur site trois ans. Cette référence était hors stock ; disponibilité, configuration française et livraison restent à confirmer par devis. Ce montant ne couvre pas toutes les stations : une configuration MIFCOM différente était affichée à 16 649 € TTC, hors port, en précommande.
    • Électricité : 0,16242 €/kWh hors TVA. La grille EDF professionnelle, page 1, en vigueur au 1er août 2026, indique 0,1318 €/kWh hors taxes en option Base, auxquels s’ajoutent 0,03062 €/kWh d’accise. Repère pour les clients éligibles ; remplacez-le par le prix de votre contrat. L’abonnement et la contribution fixe d’acheminement ne sont pas répartis ici.
    • Entretien : 24 h/an à 90 €/h hors TVA. Deux heures par mois constituent une hypothèse de maintenance courante. Le tarif horaire reprend le barème VOT’INFO 2026 pour un poste de travail. Il ne constitue pas un devis d’expertise IA ou de support critique ; le même prestataire affiche 200 €/h pour un serveur Windows/Linux. Les interventions ne sont pas comptées une seconde fois dans les frais fixes.
    • Quatre ans et 880 h/an. Hypothèses de répartition économique et d’activité : 4 h × 220 jours, avec une valeur résiduelle nulle. Les heures actives de traitement sont distinctes des heures pendant lesquelles la machine reste allumée. Cette durée de répartition ne prescrit pas un amortissement fiscal.
    • Sauvegarde et consommables : 120 €/an. Provision de scénario de 10 €/mois, hors main-d’œuvre, à remplacer par les coûts de votre équipement. Ce n’est pas un tarif fournisseur et cela ne finance pas une infrastructure de sauvegarde à créer.
    • Reste de la station : 100 W. Hypothèse non mesurée pour le processeur, la mémoire, les disques, les ventilateurs et les pertes d’alimentation pendant le lot. À remplacer par une mesure de la station à la prise, en distinguant l’énergie du GPU.

    La mise en service, l’intégration métier, le développement, l’entraînement, les incidents majeurs, le support permanent, la relecture humaine, l’électricité hors des lots et la climatisation ne sont pas inclus. Les sources et les hypothèses sont aussi conservées dans le téléchargement « Configuration et provenance ».

    Voir les formules et l’énergie non mesurée

    Coût horaire hors électricité = (achat ÷ années + frais annuels + heures d’entretien × tarif horaire) ÷ heures d’utilisation. Part de ce coût pour le lot = coût horaire × 278,29 ÷ 3 600.

    La contribution électrique utilise les 16,205 Wh réellement relevés sur la carte, auxquels s’ajoute une estimation du reste de la station sur toute la durée. Elle n’inclut pas les intervalles GPU non observés. Le montant affiché est donc partiel, même avec les hypothèses renseignées ; aucune consommation totale de station n’est prétendue.

    07 Examiner les preuves

    Des résultats que l’on peut
    retrouver et contrôler

    Les dossiers, réponses initiales, attentes du test, scores et traces opérateur présentés ici sont téléchargeables. Les identifiants et empreintes permettent de relier l’affichage aux fichiers sources vérifiés.

    Configuration exacte et contrôle de provenance

    Qwen3-14B, révision 40c069824f4251a91eefaf281ebe4c544efd3e18 ; exécution BF16, adaptateur checkpoint-0150, vLLM 0.11.2. Contexte : 18 432 jetons. Cache configuré : 11 Gio. Une séquence simultanée. Température d’échantillonnage : 0 ; graine : 20261020.

    Version technique locale vérifiée : 99070d77cb426dafb5efc2435eefd6e2dabe2224. Référence éditoriale de cette proposition : 2888b5788e099eb7fff2874e2f43049be50b8e1d, version précédente du parcours accessible.

    Le paquet vérifie les chiffres et la présence exacte des citations. Cette vérification de présence ne juge pas à elle seule leur pertinence. La notation complète conservée provient de l’évaluateur gelé et a été reproduite sur CPU depuis les archives.

    Ce qui reste à démontrer avant un usage réel
    • La qualité sur des incidents représentatifs de l’activité du client, encore inconnus du système et de ses concepteurs.
    • La qualité et le temps des décisions d’opérateurs réels : aucune revue humaine indépendante ni économie de temps n’a été mesurée.
    • Les contraintes d’exploitation : disponibilité, droits d’accès, supervision, sauvegardes et reprise après panne.
    • La sécurité et les obligations propres au contexte. Une exécution locale ne constitue pas une certification de conformité ou de souveraineté.

    Le développement a été assisté par des outils d’IA cloud. Le chemin applicatif évalué — modèle, adaptateur et traitement des dossiers synthétiques — a été exécuté localement, avec isolation réseau. Aucun document client n’est utilisé dans cette démonstration.

    Évaluer un assistant sur votre propre tâche

    La démarche datapredict consiste à définir ce qu’une réponse correcte doit contenir, construire un essai représentatif, mesurer la qualité et le fonctionnement, puis décider où une intervention humaine reste nécessaire.

    Échanger sur votre contexte →