Nexus.

Une tâche de fond parcourt les outils connectés des entreprises qui l’ont activée, sous un plafond d’analyses par jour. Six règles y guettent ce qui touche au chiffre d’affaires : une affaire sans mise à jour depuis 21 jours, une date de clôture dépassée, une échéance à moins de 14 jours sans action prévue, un paiement échoué, un abonnement impayé, une facture ouverte.

Les règles ne citent que des identifiants et des libellés tronqués, jamais de données personnelles. Un montant n’est retenu que s’il est en euros : aucun taux de change n’est inventé.

Chaque alerte reçoit un score qui pondère l’urgence (60 %) et la valeur (40 %), plafonnée à 50 000 € : au-delà, c’est l’urgence qui départage. Ce calcul est fait en code ; le modèle de langage explique, il ne note pas. Les signaux liés au chiffre d’affaires occupent une bande de score à part, toujours au-dessus des constats d’hygiène du CRM : une affaire passe avant un champ mal rempli.

Un dernier étage décide de ce qui est montré : trois alertes par jour au plus pour chaque entreprise ; une alerte écartée par l’utilisateur ne revient jamais d’elle-même ; une alerte retirée parce que la situation avait disparu attend 24 heures avant de revenir, pour ne pas clignoter. Chaque alerte non montrée est enregistrée avec sa raison, pour qu’on puisse mesurer ce que ce filtre écarte.

Nexus rédige l’e-mail de relance, avec signature et pièces jointes. L’utilisateur le relit, le modifie s’il le souhaite, et l’envoie lui-même.

L’utilisateur décrit ce qu’il veut dans le chat. À chaque tour, un modèle à sortie structurée choisit entre quatre actions : poser une question avec des réponses à cliquer, présenter le brouillon complet, créer l’automatisation, ou abandonner.

Le modèle ne voit que les connexions réelles et les outils disponibles de l’entreprise : il ne peut donc pas proposer une source qui n’est pas branchée.

Nexus exécutait d’abord ses automatisations dans Activepieces, un outil d’automatisation tiers, caché derrière l’agent. Le 18 juin 2026, nous l’avons remplacé par un moteur Python natif, repris d’Onyx, mon agent IA personnel : plus de connexions à synchroniser entre deux systèmes, et un service de moins à exploiter.

Une étape d’approbation humaine met l’exécution en pause ; à la reprise, les étapes déjà faites sont sautées, et aucune action n’est exécutée deux fois. Le planificateur tourne dans le backend et réserve chaque exécution, pour qu’elle ne parte jamais en double. Les webhooks sont signés (HMAC-SHA256) et refusés si leur horodatage s’écarte de plus de cinq minutes, ce qui empêche de rejouer un ancien appel ; tout refus reçoit la même réponse, qui ne révèle pas si l’automatisation existe. Une automatisation qui échoue trois fois de suite, ou dont le lancement prévu a plus d’une heure de retard, devient une alerte.

Quinze règles écrites en code examinent le CRM : complétude, doublons (repérés par e-mail, téléphone, ou nom et organisation), hygiène, cohérence des dates, conventions de saisie. Un constat n’est retenu qu’à partir de trois occurrences : un ou deux oublis ne font pas une habitude. La note vient de ces règles, et chaque rapport PDF est figé à sa date.

Le rapport est rédigé par le modèle à partir des constats. Pour le contrôler, j’ai écrit un banc de notation déterministe : 85 points vérifiables (exactitude des montants et des comptages, cohérence, structure, honnêteté, langage), ramenés à une note sur 100. Chacune de ses règles est née d’une erreur que le modèle a réellement commise.

Le premier audit d’un vrai CRM de PME (1 350 affaires dont 907 ouvertes) a obtenu 39 sur 100. Le banc y a révélé trois défauts invisibles sur le jeu de test de 19 affaires, dont un montant d’exemple écrit en dur dans le prompt et recopié tel quel dans le rapport. Ces défauts corrigés, le même audit a obtenu 100 sur 100.

L’utilisateur demande un indicateur, un graphique ou un tableau. L’agent interroge la source connectée en SQL, en un nombre d’étapes plafonné, puis propose un widget, dont la structure est validée avant qu’il rejoigne le tableau de bord. À chaque accès à un widget, le serveur vérifie d’abord que son tableau de bord appartient bien à l’entreprise de l’utilisateur.