Une IA qui travaille tous les jours se trompe tous les jours. Ce qui est utile, c'est ce qui se passe ensuite : si l'erreur se répète ou si quelqu'un la détecte et la corrige. Chez ADRI, il existe deux mécanismes pour cela, et ils fonctionnent sans que personne n'ait à s'en souvenir.
Nous vous expliquons comment elles fonctionnent, ce que vous voyez en tant que client et quels garde-fous elles ont.
Les quatre façons dont ADRI apprend
ADRI ne réentraîne aucun modèle avec vos données. Il conserve, organise et réutilise ce qui se passe dans son travail quotidien, de quatre manières différentes.
- Ce qu'il apprend de vous. À la fin d'une conversation, un petit modèle rapide passe en revue l'échange et met à jour votre profil : comment vous préférez qu'il vous écrive, quelle signature vous utilisez, quelles corrections vous lui avez apportées. Ce profil sert pour le ton et les préférences. Il ne sert pas de source de données : s'il a besoin d'un e-mail ou de l'état d'un compte, ADRI le consulte dans la plateforme au lieu de le sortir de sa mémoire.
- Sa mémoire des conversations. Vos chats précédents et les fichiers qu'il a générés pour vous sont indexés toutes les quelques minutes. Ainsi, il comprend « ce que nous avons regardé sur la concurrence » même si ce chat disait « étude des rivaux ». Chaque utilisateur ne cherche que dans ses propres données. Si la recherche par sens échoue, elle bascule vers la recherche par mots au lieu de renvoyer une erreur.
- Leçons techniques. Lorsqu'un outil échoue et qu'ADRI trouve comment le résoudre, ou lorsqu'il se bloque dans une boucle, ou lorsque vous le corrigez, il peut enregistrer une leçon courte du type « pour ce cas, fais ceci à la place ». Plus bas, nous expliquons pourquoi une nouvelle leçon ne vaut rien tant qu'elle n'a pas été prouvée.
- Expérience par outil. Le navigateur, par exemple, se souvient de ce qui fonctionne sur chaque site web et oublie les notes anciennes.
La règle qui unit tout est simple : stocker beaucoup, injecter peu. La mémoire stockée peut croître, mais chaque conversation ne reçoit qu'un petit extrait pertinent. Ainsi, chaque réponse ne devient pas plus coûteuse. Nous l'expliquons plus en détail dans comment fonctionne la recherche sémantique dans la base de connaissances.
La révision nocturne
Apprendre à chaud accumule des doublons et des notes qui ne s'appliquent plus. Chaque nuit, une révision s'exécute pour remettre de l'ordre :
- Il nettoie les profils utilisateur. Il supprime les doublons, résout les contradictions (c’est le plus récent qui l’emporte) et élague.
- Il passe en revue le cycle de vie des leçons. Il promeut celles qui ont démontré leur efficacité, retire celles qui échouent plus qu’elles ne réussissent et fusionne celles qui disent la même chose avec d’autres mots.
- Il retire les leçons qui n’ont plus de sens. Si elle parle d’un outil que son agent n’a plus, le code la retire. C’est une vérification mécanique, pas l’opinion d’un modèle, et elle est réversible.
- Il fait une copie des tables d’apprentissage. Une copie locale quotidienne, en plus des sauvegardes générales.
- Il conserve les métriques de la nuit. Ainsi, on voit la tendance au lieu de se fier à l’intuition.
Il y a une étape supplémentaire qui est aujourd’hui en mode test : un modèle compare chaque leçon avec les instructions en vigueur de l’agent et propose de retirer celles qui sont déjà couvertes ou celles qui les contredisent. Pour l’instant, il ne fait que proposer et le consigne ; il ne touche à rien avant que nous l’ayons révisé. Et même s’il est activé, il ne peut retirer une leçon que s’il cite littéralement la partie des instructions qui la couvre, et jamais plus d’un tiers des leçons d’un agent en une nuit.
Comment nous évitons que l’apprentissage n’abîme quelque chose
Un système qui apprend seul peut apprendre des mensonges : s’il enregistre comme une réussite quelque chose qui s’est mal passé, il le répétera avec plus de confiance. C’est pourquoi presque tout le travail se trouve dans les freins :
- Une leçon commence comme candidate. Elle ne passe à vérifiée qu’après plusieurs utilisations réussies et sans échec. Si elle échoue plus qu’elle ne réussit, elle est retirée. Si elle n’est plus utilisée pendant des semaines, également. Si l’erreur qu’elle corrigeait réapparaît, la leçon revient à la vie.
- Elle n’est créditée que si elle a réellement été utilisée. Une leçon sur un outil n’ajoute un succès que si cet outil a été utilisé dans cette tâche. Une tâche annulée ou interrompue à moitié ne compte ni comme succès ni comme échec.
- Données personnelles exclues. Les leçons techniques sont communes à toute l’installation, elles sont donc nettoyées des données personnelles deux fois avant d’être enregistrées.
- Les leçons ne touchent pas aux instructions fixes. Elles sont ajoutées sous forme de note au début de la requête, au maximum les trois les plus proches du cas. Si quelque chose va mal, un interrupteur permet de les désactiver.
- Votre profil ne peut pas rétrécir par erreur. Si, lors de sa mise à jour, le résultat est beaucoup plus court que l’original, la modification est rejetée. Avant de le réécrire, une copie est sauvegardée.
- Les tests ne paient pas d’apprentissage. Nos batteries de tests ont un verrou qui empêche qu’elles déclenchent des appels d’apprentissage réels et facturables.
- Vous pouvez l’effacer. Les rôles autorisés peuvent effacer d’un coup la mémoire d’ADRI. Par défaut, les rôles super-admin, admin et manager en disposent.
C’est la même philosophie que celle que nous racontons dans les harnais qui décident quel modèle travaille et qui vérifie : le modèle propose ; le code vérifie.
Le veilleur : un agent qui lit les journaux
Le deuxième mécanisme n’apprend pas : il surveille. C’est un agent à part, le veilleur, qui tourne sur chaque serveur une fois par jour, à une heure aléatoire de la nuit. Il lit ce qui a été écrit dans les journaux d’ADRI et de la plateforme depuis la dernière fois, regroupe les erreurs par type et, s’il trouve un incident réel, ouvre un ticket dans notre installation centrale de support.
| Étape | Ce qui se passe |
|---|---|
| 1. Lecture | Il ne lit que les nouveautés de chaque journal, sans sauter de segments. |
| 2. Preuve | Pour ouvrir un ticket, il doit citer des lignes littérales du journal, et l'outil vérifie qu'elles existent. Si la citation ne figure pas dans le fichier, le ticket est refusé. |
| 3. Sans doublons | Chaque incident porte une empreinte. S'il y a déjà un ticket ouvert avec la même empreinte, aucun autre n'est créé. |
| 4. Une panne commune, un ticket | Si la cause se trouve dans une ressource partagée par plusieurs serveurs, un seul ticket est ouvert avec plusieurs confirmations. Si elle est locale, comme un disque plein, un ticket est ouvert par serveur, car ce sont des problèmes différents. |
| 5. Fermeture | Chaque matin, les tickets du surveillant dont l'erreur n'est pas apparue depuis plusieurs jours se ferment seuls. S'il ne peut pas le mesurer correctement, il ne ferme pas. |
Les étapes 2 et 4 sont nées d'erreurs réelles. En juillet 2026, nous avons examiné les six tickets que le surveillant avait ouverts en deux jours : trois citaient des compteurs et des noms qui n'existaient dans aucun journal. Le modèle avait inventé des incidents plausibles. Nous ne lui demandons pas d'être honnête : nous l'obligeons à citer des lignes que l'outil peut rechercher. Ce même mois, une seule panne sur une ressource partagée a ouvert sept tickets identiques, un par serveur. Depuis, cela compte comme un seul.
Et si le surveillant cesse de passer ? Il y a un second avertissement : chaque matin, on vérifie quand a eu lieu sa dernière vérification correcte. Si plus de 30 heures se sont écoulées, un ticket est ouvert pour le signaler. Et s'il se bloque ou répète la même action en boucle, on l'interrompt.
Ce que tu vois en tant que client
Au quotidien, rien. Les tickets du surveillant arrivent à notre équipe de support, pas dans ta boîte de réception. L'idée est que nous apprenions une panne par le journal, souvent avant qu'elle ne t'affecte. Nous n'arriverons pas toujours avant : le surveillant vérifie une fois par jour et certains défauts ne se remarquent que lorsque quelqu'un utilise la fonction.
Ce que tu remarques, en revanche, c'est l'effet de l'apprentissage : ADRI t'écrit avec ton ton, se souvient de ce que vous avez déjà évoqué et cesse de répéter certains faux pas techniques. Si tu veux que tes propres serveurs ouvrent des tickets avec la même logique d'empreintes, la plateforme propose une API : tu la trouveras dans tickets et support avec IA.
Ce qu'il ne fait pas encore
- Il ne se répare pas tout seul. Le surveillant fonctionne en mode lecture seule. Une seconde phase est prévue pour fermer les tickets après avoir corrigé la panne, mais elle est désactivée et la réparation automatique n'a aujourd'hui aucun chemin réel. C'est une personne qui répare.
- Il n'est pas infaillible. Un ticket du surveillant est une hypothèse étayée, pas un fait. Nous le vérifions avant d'agir.
- Apprendre n'est pas comprendre. Une leçon vérifiée a fonctionné plusieurs fois ; elle ne garantit pas le cas suivant.
- Il mesure, et parfois la mesure échoue aussi. En septembre, nous avons audité le cycle nocturne lui-même et constaté qu'il validait la nuit même si une étape échouait. Nous l'avons corrigé.
Si tu veux voir la liste des agents et ce que fait chacun, elle est dans ce que fait ADRI. Pour l'essayer, commence par le chat avec ADRI. Et si tu t'intéresses à la façon dont nous traitons les données qu'il apprend, tu la trouveras dans sécurité et conformité.
- ADRI
- Auto-apprentissage
- Tickets automatiques
- Surveillance