Louis Grante

J'ai monté une chaîne d'agents IA qui tourne à heure fixe sur un serveur. Elle fait la veille sur quelques sources, résume, rédige un brouillon selon un cadre éditorial, le relit, puis importe les statistiques de la dernière publication. Les agents s'arrêtent au brouillon : je relis et je lance la publication moi-même.

Les contrôles ne passent pas par l'IA. Les actions qu'un agent peut demander figurent dans une liste fermée, et un scanner cherche les secrets avant tout envoi. J'applique la même méthode chez mes clients : spécification, tests, validation humaine, et aucune donnée qui sort du cadre convenu.

Avant de modifier une org Salesforce ancienne, je veux savoir ce que chaque champ, Flow ou classe Apex risque de casser. Pour le voir, j'ai écrit mon propre moteur de dépendances, au sein d'OrgLookup, mon projet personnel.

Il n'utilise pas la Dependency API de Salesforce. Il télécharge les métadonnées de l'org par l'API Metadata, lit chaque fichier et en extrait lui-même les liens : le code Apex passe par un analyseur syntaxique, les Flows sont découpés étape par étape. Il applique 229 règles d'extraction sur 44 types de métadonnées et produit 50 types de liens, rangés dans un graphe Neo4j. Il distingue un champ lu, un champ écrit et un champ utilisé comme filtre : un champ écrit par un Flow ne se retire pas comme un champ seulement lu par un rapport.

Il remonte aussi des liens que la Dependency API ne renvoie pas, comme les champs fusionnés dans le corps HTML d'un modèle d'e-mail ou les droits accordés par les profils et les permission sets.

La carte sert ensuite à réduire la dette : on regroupe les éléments à retirer, et l'outil propose un plan étape par étape, avec les vérifications à faire avant chaque suppression. Rien n'est déployé automatiquement : chaque étape est relue, puis appliquée à la main.

Schéma d'illustration sur une org fictive.

Un déploiement, un réglage modifié, une intégration qui écrit de nouveaux champs : Sentinel surveille une org Salesforce en continu et alerte quand une intégration sort de ses habitudes.

Je le développe depuis janvier 2026 sous la marque OrgLookup ; le produit est en bêta. Il se connecte à une org par OAuth, sans package installé ni code déployé, et relève les déploiements, les modifications du Setup, les connexions et surtout l'activité des intégrations. Pour chaque intégration, il apprend son comportement habituel puis alerte quand elle s'en écarte : elle ne tourne plus, son volume s'effondre, elle touche un champ qu'elle n'utilisait pas.

Sentinel s'appuie sur un moteur de dépendances que j'ai écrit moi-même : 229 règles d'extraction sur 44 types de métadonnées Salesforce, rangées dans un graphe. Il affiche ainsi, à côté de ce qu'une intégration écrit, les triggers Apex et les Flows que ces écritures peuvent déclencher.

Backend Python, front React, plus de 3 000 tests automatisés. Schémas illustratifs sur une org fictive.