Vous ne nous donnez pas les clés de votre annuaire.
Un agent tourne chez vous et applique les changements localement. Les identifiants de votre Active Directory ne quittent jamais votre réseau — nous ne les détenons pas, et il n'y a rien à nous voler. Voici, en détail, comment l'architecture est conçue pour tenir cette promesse.
Aucun port entrant
L'agent installé chez vous initie une connexion sortante HTTPS (443). Pas de VPN, pas de flux entrant vers vos contrôleurs de domaine, aucune exposition de votre annuaire sur Internet.
Compte gMSA — aucun mot de passe
L'agent tourne sous un compte de service géré (gMSA) de votre Active Directory. Le mot de passe fait 120 caractères, il est généré et tourné automatiquement par l'AD tous les 30 jours : personne ne le connaît, ni vous, ni nous.
Droits délégués, jamais admin
Le compte est créé par vos soins, avec une délégation granulaire sur les seules OU du périmètre. Jamais Domain Admin. L'agent refuse toute opération qui sortirait de ce périmètre, même si l'ordre vient du control plane.
Audit anonymisé, hors ligne
Le script de cadrage initial est strictement en lecture seule et ne sort aucune donnée personnelle — que des statistiques et de la structure. Vous relisez le résultat avant de nous le transmettre vous-même.
Un agent qui tourne chez vous
Pour un annuaire on-premises (Active Directory), un agent léger s'exécute sur un serveur membre de votre domaine. C'est lui — et lui seul — qui applique les changements localement. Le control plane hébergé ne fait jamais d'écriture directe dans votre annuaire : il transmet des intentions, l'agent décide.
Le modèle est le même que celui d'Azure Arc ou de l'agent Okta AD : liaison sortante uniquement, initiée depuis votre réseau. Sur Entra ID, Google Workspace ou Okta, tout est SaaS-to-SaaS et il n'y a aucun agent à installer.
Nous ne détenons aucun identifiant de votre annuaire
C'est le point central. Aucun mot de passe, aucun compte administrateur, aucune clé de votre Active Directory n'est stocké chez JML Autopilot. Le compte gMSA est géré par votre AD ; sa rotation est automatique et son secret n'est lisible que par le serveur autorisé à l'héberger.
L'agent s'authentifie auprès du control plane via une paire de clés qui lui est propre, scellée localement. Il n'y a donc rien, dans notre infrastructure, qui permette de rejouer un accès à votre annuaire.
Procédures fournies, exécutées par vos équipes
Vous gardez la main à chaque étape sensible. Nous vous fournissons les procédures complètes de déploiement : création du compte de service géré (gMSA), délégation précise à positionner sur les OU concernées, installation de l'agent sur le serveur membre, et paramétrage du périmètre.
Ces opérations sont réalisées par vos administrateurs, dans votre environnement. Rien n'est exécuté à l'aveugle : votre équipe applique, vérifie et valide chaque étape. Le dossier de déploiement complet est remis au démarrage du projet.
Dry-run puis approbation avant toute écriture
Tout nouveau connecteur démarre en dry-run : l'agent calcule le différentiel et vous l'affiche, sans rien écrire. Vous voyez exactement ce qui serait fait avant que quoi que ce soit ne le soit.
Vient ensuite l'approbation : par défaut, chaque opération passe par une validation IT. Une fois que vous avez confiance dans le pipeline, vous ouvrez l'auto-approbation sur les cas structurés (arrivée standard, poste et service connus), en gardant la validation manuelle sur le reste.
Et si JML Autopilot était compromis ?
Un attaquant qui prendrait le contrôle du control plane ne disposerait d'aucun identifiant exploitable sur votre annuaire — nous n'en détenons aucun. Surtout, l'agent ne fait pas confiance au control plane : il applique sa propre politique locale et refuse toute opération sortant de sa délégation, même si l'ordre vient de nous.
S'ajoutent des plafonds de sécurité : une désactivation en masse anormale stoppe l'agent et déclenche une alerte. Et vous gardez une révocation en un clic depuis le cockpit, qui coupe immédiatement le lien.
Hébergement UE et chiffrement
Chaque tenant dispose de son propre déploiement isolé, hébergé sur des régions de l'Union européenne (Francfort par défaut). Aucune donnée ne quitte l'espace européen.
Les secrets nécessaires au fonctionnement — jetons OAuth des connecteurs, clés d'API — sont chiffrés en AES-256-GCM avec une clé unique par déploiement. Les identifiants de votre annuaire, eux, ne sont pas chiffrés chez nous : ils ne nous sont tout simplement jamais transmis.
Ce que nous demandent les DSI et RSSI.
Est-ce qu'on doit vous donner un compte administrateur de notre AD ?
Non — et nous ne le voudrions pas. Vous créez vous-même, dans votre annuaire, un compte de service géré (gMSA) dédié à l'agent. Son mot de passe fait 120 caractères, il est généré et tourné automatiquement par l'AD tous les 30 jours, et personne ne le connaît : ni vous, ni nous. Ce compte n'est jamais Domain Admin ; il reçoit une délégation granulaire sur les seules OU du périmètre. Aucun identifiant de votre annuaire n'est stocké chez JML.
Est-ce qu'on doit installer quelque chose sur nos serveurs ?
Si votre annuaire est on-premises (AD), oui : un agent léger tourne sur un serveur membre du domaine. Il fonctionne uniquement en flux sortant HTTPS (443) — aucun port entrant à ouvrir, aucun VPN, aucune exposition de vos contrôleurs de domaine. C'est le même modèle qu'Azure Arc ou l'agent Okta AD. Sur Entra ID / Google / Okta, tout est SaaS-to-SaaS : rien à installer.
Que se passe-t-il si JML Autopilot est compromis ?
Un attaquant qui prendrait le contrôle de notre control plane ne disposerait d'aucun identifiant exploitable sur votre annuaire — nous n'en détenons aucun. Surtout, l'agent ne fait pas confiance au control plane : il applique sa propre politique locale et refuse toute opération sortant de sa délégation, même si l'ordre vient de nous. S'ajoutent des plafonds de sécurité (une désactivation en masse anormale stoppe l'agent) et une révocation en un clic depuis le cockpit.
Que voyez-vous de notre annuaire pendant l'audit initial ?
Le script de cadrage est strictement en lecture seule (uniquement des cmdlets Get-AD*) et ne produit aucune donnée personnelle : ni nom, ni e-mail, ni identifiant, ni matricule. Il ne sort que des statistiques (taux de remplissage, cardinalités, masques de format) et de la structure (arborescence d'OU, groupes). Le nom de domaine est haché, un seuil de k-anonymat supprime les statistiques portant sur de faibles effectifs, et rien n'est transmis automatiquement : vous exécutez le script, vous relisez le fichier produit, et vous nous le transmettez vous-même. Le code est fourni en clair, auditable avant exécution.
Où sont hébergées les données ?
Chaque tenant a son propre déploiement isolé, hébergé chez Vercel + Neon (Postgres) sur des régions UE (Francfort par défaut). Aucune donnée ne quitte l'espace européen. Les secrets (tokens OAuth, clés API des connecteurs) sont chiffrés AES-256-GCM avec une clé unique par déploiement. Les identifiants AD, eux, ne sont pas stockés — ils ne quittent jamais votre réseau.
Est-ce qu'on peut approuver automatiquement certains cas ?
Oui, mais nous ne recommandons pas de démarrer avec ça. Tout nouveau connecteur démarre en dry-run : l'agent calcule le diff et vous l'affiche, sans rien écrire. Vous configurez ensuite la règle « toutes les demandes passent en approbation IT ». Une fois que vous avez confiance dans le pipeline, vous ouvrez l'auto-approbation sur les cas structurés (ex. : arrivée standard, poste connu, service existant).
Un questionnaire sécurité ou une DPA à nous faire remplir ? Contactez-nous via le formulaire — nous fournissons également, au démarrage du projet, le dossier de déploiement complet (procédures de création du gMSA, délégation à positionner, installation de l'agent).