Neuf équipes, le même écart à refermer

Les équipes Ops & Admin ne perdent pas des heures à cause d'un mauvais logiciel, elles les perdent dans l'écart entre la boîte mail, le CRM et le drive plein de PDF. Chaque formulaire, scan ou pièce jointe qui arrive devient une course de relais manuelle : le lire, retrouver la bonne fiche, ressaisir les champs, classer le PDF, se souvenir de qui relancer.

Les agents Standards referment cet écart au niveau de la fiche, pas du dossier. Ils lisent ce qui arrive (un état de patrimoine, un formulaire KYC, une pièce d'identité, un fichier de rapprochement bancaire), en extraient les données, notent leur propre confiance champ par champ, et écrivent directement dans la fiche liée : le bon contact, le bon actif, avec la bonne quote-part. Ce qui tombe sous le seuil de confiance n'est jamais deviné : c'est signalé, avec la page et le champ exacts d'où ça vient, pour qu'un humain confirme en quelques secondes plutôt que de tout ressaisir.

Les mêmes agents repèrent ce que les humains repèrent d'habitude trop tard : deux fiches client qui sont en réalité la même personne, un ordre de virement qui n'est jamais vraiment arrivé à la banque, une clause de bénéficiaire enterrée dans un scan que personne n'a OCRisé. Ils pré-remplissent aussi les documents sortants (kits de souscription, bulletins de rachat, annexes de conformité), en ne sourçant que des champs CRM vérifiés, jamais inventés, à vérifier visuellement avant toute signature.

Tâches et notes restent attachées à la fiche qu'elles concernent, qu'elles aient été créées par un humain ou un agent, pour que rien ne vive uniquement dans une boîte mail ou un onglet de tableur. Et chaque action d'un agent laisse la même piste d'audit que vous attendriez de votre meilleur analyste : source, confiance, ce qu'il reste à vérifier avant que ça parte.

Les ingénieurs ne perdent pas de temps à cause de mauvais frameworks, ils en perdent aux quatre endroits où un modèle de données doit rester cohérent avec lui-même : la migration, la route API, le schéma de validation, le contrôle de permission, et l'écran d'admin que quelqu'un finit toujours par devoir ouvrir pour regarder la donnée. Ajoutez un champ, et les quatre doivent être mis à jour en même temps, ou quelque chose dérive en silence jusqu'à ce qu'un ticket support le trouve.

Standards referme cet écart au niveau du schéma, pas de l'endpoint. Déclarez un objet une seule fois, object("mandates") .attribute(text("reference")) .attribute(relation("client")) et l'API REST typée, les contrôles de permission RBAC, l'index de recherche full-text et une UI d'admin fonctionnelle (grille de données, formulaires, vues) en dérivent tous. Changez le type d'un attribut et chaque consommateur suit ; renommez-en un et Standards vous demande de trancher l'ambiguïté explicitement plutôt que de perdre silencieusement de la donnée au prochain déploiement.

Les agents lisent le même schéma que vous. Exposez-le via MCP et Claude Code, Cursor, ou votre propre agent peut interroger et agir directement sur vos fiches, sous exactement le même périmètre de permission qu'une session humaine, pas une "API IA" séparée à construire, sécuriser et auditer de votre côté. Un agent qui écrit sur une fiche mandat apparaît dans le même journal d'audit qu'une personne qui ferait la même chose : qui, quoi, source, horodatage.

Arrêtez d'échantillonner quarante dossiers par trimestre pour prouver ce que le système était censé savoir depuis le début.

Les auditeurs et responsables conformité ne perdent pas de temps à cause de mauvais outils de conformité, ils en perdent dans l'écart entre la transaction qui a eu lieu, le document KYC censé la documenter, et la note auto-déclarée où quelqu'un a noté avoir vérifié. Une revue manuelle, c'est tirer un échantillon, recouper les pièces d'identité, vérifier le risque déclaré face au revenu déclaré, rédiger des constats, puis espérer que rien n'a changé entre deux échantillons.

Les agents Standards referment cet écart au niveau de la fiche. Chaque document KYC entrant (pièce d'identité, justificatif de domicile, déclaration d'origine des fonds) est lu le jour de son arrivée. Chaque champ lié au modèle de données est extrait avec son propre score de confiance et sa source exacte (document, page, zone) ; seul ce qui franchit le seuil de confiance est écrit automatiquement. En dessous, c'est signalé à un réviseur nommé, avec le champ et la source exacts.

Recouper ces sources à la main occupe une bonne part du temps ops et conformité de tout gérant de patrimoine, pas la stratégie de portefeuille, pas les appels clients, juste la traque du même chiffre à travers différents systèmes jusqu'à ce qu'il finisse par se recouper. Chaque souscription, chaque renouvellement KYC/LCB-FT, chaque relevé de dépositaire ajoute une version de plus de la vérité à retrouver.

Même quand des automatisations existent déjà pour ça, ce sont surtout des scripts câblés sur la mise en page d'un portail ou un format de fichier précis, et ils cassent dès qu'un dépositaire change son parcours de connexion, renomme un champ, ou modifie un modèle de PDF.

Standards corrige tous ces processus. Il lit les documents directement plutôt que de demander à quelqu'un de les ressaisir. Un relevé de portefeuille multi-dépositaires, un bulletin de souscription ou de rachat, un dossier KYC, un contrat d'assurance : chacun est analysé champ par champ, noté en confiance, et écrit dans la fiche client, mandat ou actif correspondante, la bonne classe de parts, le bon bénéficiaire effectif, sans mapping de modèle à maintenir à la main. Ce dont l'agent n'est pas sûr est signalé avec sa page source exacte plutôt que deviné.

Les agents Standards n'exécutent pas un script figé sur une structure gelée, ils lisent la page ou le document tel qu'il est aujourd'hui, si bien qu'un nouveau prompt de double authentification ou un champ de formulaire réordonné est géré, ou signalé, plutôt que de planter à 3h du matin sans personne pour le voir.

La réglementation vit sur les mêmes fiches plutôt que dans un classeur à part. Les contrôles d'adéquation MiFID II, les scores de risque LCB-FT, les notes de conseil DDA sont des attributs sur les objets client et mandat sur lesquels les agents écrivent déjà, avec la même piste source-et-confiance qu'un régulateur attend lors d'un contrôle.

Un juriste qui retrouve la clause de résiliation à jour à travers quatre fils d'emails et deux versions de DMS ne fait pas du droit, il fait le contrôle de version que le système aurait dû gérer tout seul. Multipliez ça par chaque avenant, chaque avis de renouvellement, chaque NDA signé en dehors de la plateforme que tout le monde suppose faire foi.

Une partie de tout ça est déjà automatisée dans la plupart des cabinets, mais ces scripts sont généralement câblés sur le webhook d'une seule plateforme de signature ou une convention de dossiers DMS précise, et ils se taisent dès qu'un modèle change ou qu'un dossier est renommé, personne ne s'en aperçoit avant qu'une échéance de renouvellement ne soit dépassée.

Standards remplace ce rapiéçage par un système qui lit les documents lui-même. Un contrat signé, une redline, un dossier de due diligence, un dépôt réglementaire : chacun est analysé champ par champ (parties, date d'effet, clause de résiliation, droit applicable, plafond d'indemnisation), noté en confiance, et écrit dans la fiche dossier, client ou contrat correspondante, la bonne contrepartie, la bonne obligation, sans mapping à maintenir à la main. Ce dont l'agent n'est pas sûr est signalé avec sa page source exacte plutôt que deviné.

Parce que les agents lisent l'état actuel d'une page ou d'un document plutôt que d'exécuter un script figé, un dossier renommé ou un nouveau prestataire de signature électronique est pris en compte et traité, pas silencieusement ignoré jusqu'à ce que quelqu'un trouve l'écart.

Les échéances et obligations vivent sur ces mêmes fiches plutôt que dans un tracker à part. Dates de renouvellement, délais de préavis, statut de vérification des conflits d'intérêts, conditions de traitement RGPD : ce sont des champs sur les objets dossier et contrat que les agents maintiennent déjà, chacun portant le document source et le score de confiance qu'un associé veut voir avant de valider.

Une opération mid-market génère entre 2 000 et 10 000 documents une fois la data room ouverte, et une data room n'est pas que des contrats et des procès-verbaux de conseil : ce sont aussi les chiffres propres de la cible, un export CRM, un grand livre extrait en CSV, une base clients déversée depuis un serveur SFTP. Les deux moitiés doivent être lues avant que quiconque puisse faire confiance à la valorisation, et aujourd'hui une équipe lit les documents pendant qu'une autre lutte pour faire rentrer les exports dans un tableur que personne d'autre ne sait ouvrir.

Certains cabinets font déjà tourner une recherche par mots-clés sur les documents ou un script sur les exports, mais les deux ne se parlent jamais, et les deux cassent dès que la cible suivante fournit un modèle différent, ou qu'une colonne est renommée dans l'export du trimestre.

Standards lit les deux moitiés de la data room dans le même système. Contrats, tables de capitalisation, dépôts de propriété intellectuelle et dossiers RH sont analysés pour les termes qui font bouger une valorisation : déclencheurs de changement de contrôle, droits de résiliation, plafonds d'indemnisation, clauses d'homme-clé, litiges en cours. Les exports CSV, Excel et SFTP sont ingérés de la même façon, transformés en tables liées plutôt qu'en fichiers statiques : un export clients devient une table de fiches clients, un export de grand livre devient une table de transactions, et Standards les relie (ce client, ce contrat, cette ligne de revenu) comme le ferait un modèle de données. Chaque constat, document ou ligne de données, est noté en confiance et écrit sur l'item de diligence correspondant, avec sa source exacte, plutôt qu'un PDF surligné ou un onglet de tableur que personne ne rouvre avant que le mémo ne soit dû.

Parce que les agents lisent un document ou une table tel qu'il est plutôt que de le faire correspondre au modèle du trimestre dernier, une data room restructurée en cours de deal, une cible qui renomme ses propres colonnes d'export, ou un nouveau dépôt SFTP avec un schéma différent ne casse pas la revue. Ça se relit, c'est tout.

Les mécanismes de closing du deal vivent sur ces mêmes fiches. Jalons d'escrow, statut de dépôt HSR, conditions d'assurance R&W, engagements post-closing : ce sont des attributs sur les objets deal et entité sur lesquels les agents écrivent déjà, avec la même piste source-et-confiance que le conseil attend avant de valider la checklist de closing.

L'essentiel est rafistolé avec des intégrations point à point et des bots RPA câblés sur le workflow précis d'une équipe, et ce sont généralement les premiers à casser quand un système est mis à jour, qu'une équipe se réorganise, ou qu'un fournisseur change un parcours de connexion sans prévenir personne en aval. Personne ne possède la couche d'intégration, donc personne ne s'en aperçoit avant qu'un rapport ne sorte faux.

Standards devient le nouveau système de référence plutôt que de laisser l'éparpillement en place. Il ingère ce qui est dispersé entre ces trente à quatre-vingts outils, tableurs et bases de données historiques, et le transforme en un seul ensemble d'objets liés que chaque service lit et alimente désormais. Ce qui était quarante exports prétendant chacun être la source de vérité devient un seul système, déployé sur site et configuré par nos ingénieurs à l'intérieur de l'infrastructure propre de l'entreprise, en production en 30 à 90 jours plutôt que la migration de plateforme pluriannuelle que la DSI redoute déjà.

Chaque action d'un agent porte le même périmètre de permission et la même piste d'audit qu'une session humaine, ce qui compte plus ici qu'ailleurs : une entreprise de cette taille a une équipe sécurité qui va demander, une équipe conformité qui va redemander, et un audit qui a lieu que quelqu'un le demande ou non. SSO, accès par rôle, résidence des données sur site : ce ne sont pas des options entreprise ajoutées après coup, c'est comme la plateforme fonctionne déjà.

Il n'y a pas encore de recrutement ops, personne dont le métier est l'outillage interne, alors celui ou celle qui a du temps maintient un tableur devenu la base client de facto, un board Notion qui suit les deals, et un script écrit un week-end pour garder les deux synchronisés. Ça tient jusqu'à la clôture du tour et le doublement des effectifs, et là trois personnes éditent le même tableur et plus personne ne fait confiance aux chiffres du board deck.

Le construire proprement, un vrai modèle de données, une UI d'admin, des permissions, une API, coûte généralement à la première recrue ingénieur un semestre entier avant qu'elle ne touche la roadmap que les investisseurs ont réellement financée. Et le calcul devient plus serré juste après la clôture de ce tour : une startup avec un plan à deux ans pour multiplier par 10 ne veut pas greffer des agents sur sa stack dix-huit mois plus tard, en défaisant des bricolages de permissions comme une grande entreprise finit par devoir le faire. Elle veut démarrer agentique et le rester, donc le modèle d'objets vient en premier et les agents n'ont jamais été une pensée après coup.

Standards est cette fondation, déjà construite. Vous pouvez utiliser nos bundles prêts à l'emploi ou, avec notre constructeur d'espace de travail, décrire en langage naturel les objets dont votre startup a besoin (clients, deals, etc.). Nos agents proposent ensuite une structure (paramètres, valeurs, relations entre objets, etc.) que vous validez. Configurez vos connexions API, écrans d'admin et modèle de permissions. Les agents connaissent toujours le modèle de données et l'UI, même quand vous les faites évoluer. Une question support ou ops qui demanderait normalement de solliciter la personne qui se souvient où vit un champ trouve sa réponse directement dans la donnée réelle.

Le contrôle humain n'est pas un paramètre ajouté plus tard, c'est le comportement par défaut. Un agent sous le seuil de confiance signale son travail à un réviseur nommé plutôt que de deviner, que la fiche soit un client, un deal ou un ticket support. Une équipe de dix personnes obtient le levier des agents qui font le travail opérationnel répétitif sans perdre les décisions qui nécessitent encore un humain, ce qui compte le plus justement quand l'équipe est trop petite pour tout revérifier à la main.

Une fintech de douze personnes n'a pas le délai de grâce sur la conformité qu'a une SaaS de douze personnes. Le partenaire bancaire, l'émetteur de cartes ou le régulateur attend le même dossier KYC, le même monitoring transactionnel et la même piste d'audit qu'une équipe cinquante fois plus grande produirait, et l'attend dès le premier utilisateur en production, pas une fois qu'il y a des effectifs à y consacrer.

La plupart des fintechs en début de vie gèrent ça avec un tableur qui suit le statut KYC, un canal Slack pour les signalements d'activité suspecte, et une procédure Word listant quelle règle s'applique à quelle cohorte d'utilisateurs. Ça survit aux cent premiers utilisateurs. Ça survit rarement au premier audit.

Standards exécute cette procédure au lieu de se contenter de la documenter. Un skill, la même checklist d'onboarding que la conformité a déjà écrite, indique à l'agent quoi faire de la pièce d'identité, du justificatif de domicile et de la déclaration d'origine des fonds d'un nouvel utilisateur : découper le PDF de huit pages en ses parties, lire la date d'expiration de la pièce d'identité, la vérifier face à l'identité déclarée, et classer chaque pièce dans le champ correspondant de la fiche utilisateur. Chaque valeur extraite porte son propre score de confiance et sa page source. En dessous du seuil, un réviseur nommé voit exactement quoi vérifier. Au-dessus, la fiche s'écrit toute seule le jour où le document arrive plutôt que la semaine avant un audit.

Le même agent agit ensuite sur ce qu'il vient de classer. Ouvrir un compte chez un partenaire banking-as-a-service, soumettre un dossier à la file de revue d'un émetteur de cartes, déposer un renouvellement auprès d'un schéma de paiement : la plupart de ces actions passent encore par le portail propre d'un partenaire, pas par une API. Standards ouvre un navigateur, se connecte, et travaille l'écran comme le ferait un analyste ops : formulaire rempli, documents joints, soumission confirmée, étape par étape, sans rien à construire ni maintenir côté partenaire.

Chacune de ces actions apparaît dans la même piste d'audit qu'une action humaine : qui ou quoi l'a faite, à partir de quel document source, avec quel niveau de confiance. Pour une activité régulée où une seule décision KYC non documentée peut coûter un partenariat bancaire, cette piste n'est pas une fonctionnalité de reporting ajoutée après coup. C'est la raison pour laquelle l'agent a été autorisé à toucher la fiche.