Automatisation par IA pour portefeuilles de private equity, mesurée en points de base

Ce que nous automatisons, et les points de base que cela fait évoluer

Les operating partners n'achètent pas de l'automatisation ; ils achètent de la marge. Chaque chantier ci-dessous nomme l'automatisation, l'agent ou le code qui fait le travail, et le levier qu'il actionne dans le compte de résultat d'une société en portefeuille.

Comment quelques heures de votre temps en font gagner une centaine

1. Lire, pas interroger. Le diagnostic automatisé s'exécute sur les enregistrements réels des transactions, des lignes et des notes système. Votre équipe consacre deux ou trois heures à accorder les accès et à écouter la restitution, et non quarante heures en ateliers.
2. Une fuite, un sprint. Chaque sprint de quatorze jours supprime une fuite identifiée, avec du code mis en production. Votre temps : la validation du périmètre, une revue en milieu de sprint et la recette.
3. Des agents encadrés par un contrat. Là où un agent a sa place, il s'exécute derrière un contrat de schéma et une passerelle en lecture seule ou à privilèges minimaux. Rien n'atteint le grand livre sans passer par le contrat et, si nécessaire, par une personne.
4. Publier la ligne. Trente jours après le déploiement, la télémétrie avant/après devient une ligne du registre de temps 100x, avec sa classe de source.

The productized offers

Le registre de temps 100x

100x est l'objectif de conception. Le registre montre à quel point chaque automatisation s'en approche, avec des lignes mesurées entre environ 15x et 90x sur le temps et des lignes projetées au-delà de 100x. Chaque chiffre indique s'il est mesuré dans une mission de conseil, issu d'un rôle du fondateur (avant DataOngoing), projeté ou modélisé. Lire le registre.

Cinq lignes sur 12. Grand livre complet, méthode et conversion en points de base.

Le piège du conseil à 300 k$, et l'alternative

Ce qui reste encadré quelle que soit la vitesse

La vitesse tient à l'analyse, pas à la gouvernance. Les agents lisent via une passerelle à privilèges minimaux, avec contrôles par champ et journalisation d'audit ; les modifications proposées sont comparées au périmètre convenu et vérifiées quant à leur impact financier net avant de toucher un système de référence. La structure de gouvernance est construite en premier. C'est pourquoi la partie rapide est sûre.

Où vont vos données lorsqu'un modèle les lit

Chaque conception présentée sur ce site place, à un moment donné, un modèle devant vos enregistrements : un bordereau de colisage, un référentiel fournisseurs, une liste de rôles, un grand livre. Trois questions déterminent si cela est acceptable pour vos conseils juridiques et vos investisseurs : ce qui quitte vos systèmes, qui peut s'en servir pour l'entraînement, et qui peut le lire ensuite. L'architecture répond aux trois avant le choix du modèle, et le modèle reste votre choix.

Ce qui quitte vos systèmes : le minimum requis par la tâche

• Le paquet de contexte. Un worker ne reçoit jamais une base de données ni un export. Il reçoit les lignes dont la tâche a besoin, assemblées par des requêtes préalables, avec la politique qui s'y applique. La conception, voie par voie.
• Les données personnelles sont masquées lorsque la tâche n'en a pas besoin. Les noms, coordonnées bancaires, identifiants fiscaux et champs de contact sont remplacés par des jetons stables avant le prompt et ne sont rétablis que dans le système de référence, par la personne qui valide. Un modèle qui rapproche une facture fournisseur d'un bon de commande n'a pas besoin de savoir qui est le contrôleur du fournisseur.
• Les lectures renvoient des lignes en direct ; les écritures sont des brouillons qu'une personne valide. Chaque prompt, les lignes qu'il contenait, le modèle et sa version, la réponse et le validateur sont consignés sur l'enregistrement concerné, de sorte qu'un auditeur peut rejouer ce que le modèle a vu et ce qu'une personne a décidé.

Qui peut l'entraîner : le choix du modèle vous appartient

Deux voies, livrées de la même manière. Le routeur, le paquet de contexte, la validation par approbation et le journal d'audit ne changent pas avec le modèle ; seul le point d'accès change.

Notre recommandation, énoncée clairement : utilisez Claude, Gemini ou les modèles d'OpenAI, sauf si un contrat, un régulateur ou un chiffre de volume en décide autrement. La voie open-weight est une vraie option, pas une concession, et c'est la bonne lorsque les données ne peuvent pas sortir. Dans les deux voies, les comptes, les clés et les factures appartiennent à la société en portefeuille ; la relation sur les données est donc entre vous et le fournisseur, et rien dans le circuit des données ne dépend de DataOngoing après le sprint.

Qui peut les lire ensuite

• Aucun outil de chat grand public. Le travail passe par des points d'accès entreprise ou API, dans le cadre d'un accord signé, jamais par un compte de chat personnel.
• Aucun apprentissage mutualisé entre clients. Rien d'une mission n'entraîne, n'affine ni n'alimente une autre. Ce qui se transmet, c'est le schéma, publié ici sous forme de cas composite modélisé, le client étant présenté comme un archétype.
• Notre propre accès suit la mission. Rôles à moindre privilège accordés pour la mission et retirés à son terme ; la revue de due diligence s'exécute en lecture seule, et l'analyse porte sur des extraits anonymisés, sans données personnelles, sous votre NDA et non le nôtre. Conditions de confidentialité.
• Inscrit dans le SOW. Le fournisseur, le point d'accès, le paramètre de conservation et les règles de masquage sont nommés dans l'énoncé des travaux avec le reste du périmètre ; ils sont donc vérifiables à la recette comme toute autre condition.

Questions fréquentes