L'API REVIEWIT

01En une phrase #sec_decf73bd

L'API REVIEWIT expose les campagnes, les décisions, les preuves et la piste d'audit à vos propres outils — en lecture , sous une identité de machine authentifiée par certificat, et sans jamais permettre de rendre une décision de revue .

02Le problème #sec_148ec0fa

Une campagne de recertification ne vit pas seule. Ses résultats intéressent d'autres systèmes : l'outil de gouvernance des risques qui consolide les contrôles, le SIEM qui corrèle les événements de sécurité, l'outil décisionnel qui suit les indicateurs, la gestion de services qui déclenche les remédiations.

Sans interface programmatique, ces échanges se font par exports manuels : quelqu'un télécharge un fichier, le dépose quelque part, et le refait le mois suivant. Trois défauts en découlent, tous connus :

La fraîcheur. Un tableau de bord alimenté à la main est faux la plupart du temps.

La traçabilité. Un fichier qui transite par une boîte mail n'a plus d'origine certaine, ni de garantie de complétude.

Le coût humain. Le temps passé à transporter de la donnée est du temps qui n'est pas passé à examiner des accès.

03Le parti pris #sec_63100d97

On lit tout. On ne décide rien.

C'est la règle fondatrice de l'API, et elle est le pendant exact du principe qui gouverne les surfaces d'administration : l'administrateur n'approuve rien .

Aucune décision de revue par API

Il est impossible de certifier, révoquer ou poser une exception par appel programmatique. Ce n'est pas une fonctionnalité repoussée à plus tard : c'est une exclusion de principe.

Une décision de recertification tire toute sa valeur de son imputabilité à une personne qui a regardé, jugé, et qui en répond. Une décision produite par un script n'a pas d'auteur — au mieux, elle a un opérateur qui a lancé le script, ce qui n'est pas la même chose. Ouvrir cette porte reviendrait à permettre de certifier un parc entier en une requête, et à réduire à néant la valeur probante de toutes les autres décisions du système.

L'API sert donc à exploiter les résultats du contrôle, jamais à les fabriquer.

La souscription vient du jeton, jamais de l'appel

Aucun appel ne comporte de paramètre désignant le client, la souscription ou le périmètre à interroger. Le périmètre est dérivé de l'identité du jeton présenté.

La conséquence est qu'il n'existe aucune requête, même malformée, même malveillante, qui puisse retourner les données d'un autre client. On ne se protège pas d'une erreur de paramètre : on supprime le paramètre.

L'authentification par certificat est obligatoire

Les systèmes appelants ne s'authentifient pas avec un secret partagé, mais avec un certificat : ils signent leur demande de jeton avec leur clé privée, que REVIEWIT vérifie avec la clé publique déclarée.

La différence est concrète. Un secret partagé est une chaîne de caractères : elle circule, se recopie dans un fichier de configuration, se retrouve dans un dépôt de code, et une fois divulguée elle est utilisable par quiconque. Une clé privée ne quitte jamais le système appelant — il n'y a rien à intercepter.

04Comment ça marche #sec_ad3e5605

Les clients API

Chaque système autorisé à appeler l'API est déclaré comme client , rattaché à une souscription, avec ses habilitations propres. La gestion se fait depuis le Subscription Manager, et la capacité d'ouvrir l'API dépend de l'édition souscrite.

Ces clients sont distincts des connexions que REVIEWIT utilise pour aller collecter les données chez le client. Ce sont deux notions opposées — l'une entre, l'autre sort — et les confondre reviendrait à ce qu'un accès en lecture sur l'API hérite des autorisations de collecte.

Les habilitations

Un client ne reçoit pas « l'API » : il reçoit un ensemble d'habilitations correspondant aux domaines dont il a besoin. Un connecteur SIEM qui ne consomme que la piste d'audit n'obtient pas l'accès aux preuves signées.

La pagination est obligatoire

Toutes les collections se parcourent par curseur : chaque réponse indique où reprendre. Ce n'est pas un détail de confort.

Une pagination par numéro de page devient fausse dès que les données bougent pendant le parcours — des éléments sont vus deux fois, d'autres jamais. Sur un export de conformité, cela signifie une preuve incomplète sans que personne ne s'en aperçoive. Le curseur élimine cette classe d'erreur.

Le contrat est figé, et vérifié

La spécification de l'interface est verrouillée par un test automatisé . Toute modification non intentionnelle du contrat — un champ renommé, un type changé, une réponse dont la forme évolue — fait échouer la chaîne d'intégration avant publication.

C'est ce qui permet de s'engager sur la stabilité de l'interface : elle n'est pas garantie par une bonne intention, mais par un mécanisme qui refuse le changement accidentel. Les évolutions de rupture passent par une nouvelle version.

05Ce que l'API expose #sec_0de57e12

Trois points méritent d'être détaillés.

Les décisions sont normalisées. Les états internes du produit sont traduits en un vocabulaire public stable et documenté. Une évolution du fonctionnement interne ne casse pas les intégrations des clients.

Les preuves ne sont pas stockées. Le certificat attestant d'une revue est produit au moment où on le demande , à partir des données de la piste, puis signé électroniquement. Rien n'est conservé à l'avance. La conséquence est importante : une preuve téléchargée aujourd'hui reflète l'état vérifiable aujourd'hui, et n'est pas un document figé dont on ignorerait la fraîcheur. Une revue non décidée ne produit pas de preuve — elle produit un refus explicite.

L'export d'audit est conçu pour le flux continu. Il fonctionne en avançant sur un curseur, et adopte une sémantique protectrice : tant que des événements sortent, la position suivante est fournie ; lorsqu'il n'y a rien de nouveau, aucune position n'est renvoyée et le consommateur conserve la sienne . Un système de collecte qui interroge toutes les minutes ne perd donc jamais sa place, même s'il redémarre.

06Ce qui vient ensuite #sec_45c04ae7

Les notifications sortantes s'appuieront sur le même mécanisme de sortie que les e-mails du produit. Ce n'est pas un choix d'implémentation anodin : cela garantit qu'un webhook et une notification décrivent le même événement, au même moment, avec les mêmes garanties de livraison — plutôt que deux chemins concurrents qui finiraient par diverger.

Les écritures administratives permettront de piloter des campagnes depuis un outil tiers : créer, lancer, clôturer. Elles resteront strictement administratives.

La décision de revue, elle, ne sera jamais exposée — à aucune version.

07Un point ouvert, assumé #sec_10c3ba42

Les quotas de consommation sont partiellement traités. Une limitation du débit instantané protège aujourd'hui le service, mais les quotas par période et par édition ne sont pas encore arbitrés : c'est une décision commerciale autant que technique, et elle est identifiée comme telle.

Ce dossier le mentionne plutôt que de laisser croire à une couverture complète.

08À retenir #sec_9a930c7a

L'API répond à une demande simple — nos données de conformité doivent vivre dans nos outils — sans céder sur ce qui fait la valeur du produit.

Elle est ouverte en lecture sur tout ce que le dispositif produit, fermée sur ce qui doit rester un acte humain. Elle authentifie ses appelants par certificat, dérive leur périmètre de leur identité plutôt que de leur demander, pagine par curseur pour ne jamais mentir sur la complétude, et garantit son contrat par un test plutôt que par une promesse.

Une intégration ne doit jamais devenir un moyen de faire plus vite ce que le contrôle demande de faire attentivement.