Aller au contenu
BM Automation
Parler de votre request list

Due diligence M&A · Systèmes sur mesure

Une pièce manquante ne fait aucun bruit.

Jusqu’au mauvais moment. Request list, data room, emails : nous relions ce que votre due diligence disperse. Chaque pièce attendue garde un statut sourcé, un responsable et sa prochaine relance.

Parler de votre request list Suivre une demande

Conçu autour de votre request list. Pas une data room de plus.

Illustration : extrait d’une request list. Trois arrivées sont signalées. La ligne 4.2, baux commerciaux, reste partielle : deux sites manquent et aucune notification ne le dit, jusqu’à ce que le suivi lui donne une échéance, un responsable et une relance à valider.

Représentation illustrative · aucune donnée client
Pour les équipes deal qui tiennent la request list, côté cédant comme côté acquéreur. Le manquant, ligne à ligne

01Là où le manquant se cache

Ce qui arrive se voit.
Ce qui manque se reconstitue.

Entre la request list, la data room, les emails du cédant et les listes des conseils, le manquant n’a pas d’adresse. Il vit dans un tableau tenu à la main, exact le jour de sa mise à jour.

Un fichier est déposé en data room.

Répond-il à la bonne demande ?

Le DAF répond avec trois pièces jointes.

Lesquelles sont complètes ?

Le conseil de l’acquéreur envoie sa liste.

Qu’est-ce qui est déjà demandé ailleurs ?

Le point d’avancement est demain.

Qui refait le décompte ce soir ?

Une pièce n’arrive pas.

Rien ne le signale.

Une arrivée déclenche une notification. Une absence ne prévient personne.

Vos analystes tiennent la liste. Vos associés découvrent les trous.

02Le statut réel d’une demande

« Fourni » n’est pas un statut.
C’est une hypothèse.

Une pièce peut être reçue et incomplète : deux exercices au lieu de trois, une filiale oubliée, une version non signée, une annexe absente. Un suivi utile distingue ce qui est arrivé de ce qui répond vraiment à la demande.

Le statut

Six statuts.
Pas une case cochée.

Partiel

4.2 Baux commerciaux, tous sites

Trois sites sur cinq. Metz et Tours manquent.

Ce qu’il déclencheUne relance ciblée sur les deux sites.

Le système
Proposé, avec ses contrôles
Votre équipe
Statue

Le doute a sa propre case. Les statuts se définissent avec votre équipe.

La source

Chaque statut a sa preuve.

L’email, le fichier, la référence en data room, la date : le statut renvoie à ce qui le justifie.

L’échéance

Une date transforme une absence en signal.

Sans échéance, un manque reste muet. Avec elle, il remonte le jour prévu.

Le responsable

En face de chaque manque, un nom.

Pas « le client ». La personne qui détient la pièce, chez le cédant ou chez un conseil.

La relance

Préparée avec ce qui est déjà reçu.

Elle rappelle ce qui manque, ce qui est partiel et l’échéance. Elle part quand vous l’envoyez.

L’historique

Chaque étape garde sa date.

Demandé, reçu, complété, communiqué : le fil reste datable.

Ce qui manque. Chez qui. Depuis quand.

Représentation illustrative · statuts à définir avec votre équipe

03De la liste au point d’avancement

Le système veille.
Votre équipe tranche.

Des agents IA aux rôles délimités surveillent, rapprochent et préparent. Ils ne décident pas de ce qui est complet. Ils n’envoient rien.

Scénario illustratif. Le suivi se construit selon vos outils, vos listes et vos règles ; ce n’est ni un produit standard ni un dossier client.

Passer la démonstration

Étape 01La liste entre.

Le système

Lit la request list, repère ce qui recoupe les listes déjà reçues, propose une catégorie et un responsable par ligne.

Votre équipe

Valide la structure, les priorités et ce qui sort du périmètre.

Étape 02Les pièces arrivent.

Le système

Repère ce qui arrive par email ou en data room et propose un rattachement à une ou plusieurs lignes.

Votre équipe

Confirme ce qui est ambigu.

Étape 03Le manque prend date.

Le système

Compare l’attendu au reçu, contrôle ce qui peut l’être selon vos critères, fait remonter ce qui glisse.

Votre équipe

Statue sur la complétude.

Étape 04La relance se prépare.

Le système

Rédige une relance par responsable : ce qui manque, ce qui est partiel, ce qui est déjà reçu, l’échéance.

Votre équipe

Ajuste le ton, choisit le moment, envoie.

Étape 05Le point se tient.

Le système

Produit l’état du manquant, chaque ligne reliée à sa source.

Votre équipe

Relit et décide de ce qui se partage, avec le client ou la contrepartie.

01/ 05

Défilez ou choisissez une étape

Chaque rôle est délimité.
Aucun n’hérite des droits du suivant.

Voir ce qui reste humain

04Autour de vos outils

Chaque outil sait une partie.
Aucun ne sait tout ce qui manque.

Nous ne remplaçons ni votre data room, ni votre fichier de suivi, ni votre CRM. Nous relions ce que chacun sait, là où le rapprochement se fait encore à la main.

4.2Baux commerciaux, tous sites

Projet Cèdre · une même demande

Ce que vos outils savent

Request list

Demandé

Baux commerciaux, tous sites · 12 sept.

Data room

Déposé

Trois fichiers dans le dossier 4.2

Emails

Promis

« Les deux derniers suivent la semaine prochaine. » DAF, 19 sept.

CRM

Dossier

Projet Cèdre · due diligence en cours

Ce que seul le suivi relié sait

Statut réel

Partiel · 3 sites sur 5

Responsable

Juriste du cédant

Échéance

3 octobre

Relance

Brouillon prêt · à valider

Chaque outil connaît un fragment de la demande 4.2. Relié, le suivi sait aussi son statut réel, son responsable, son échéance et sa relance.

05Confidentialité & maîtrise

Les règles du dossier
s’appliquent aussi au système.

Accord de confidentialité, droits d’accès à la data room, informations communiquées par étapes : le cadre du process précède toute connexion.

Qui fait quoi

Le système

Votre équipe

Proposer · Statut « partiel » : trois sites sur cinq, périodes conformes.

Le système constate et propose. Votre équipe statue et envoie.

Cadre à définir ensembleBM / Due diligence
01Les sourcesQue lit le système ?

Le périmètre convenu : la request list, les dossiers et les boîtes autorisés. Pas l’ensemble de vos dossiers, ni toute votre messagerie.

02Les accèsQui voit quoi ?

Les droits suivent ceux du dossier. Une information réservée à certaines personnes ne devient pas visible par commodité.

Dans un process à plusieurs acquéreurs, les demandes de l’un ne doivent jamais apparaître chez un autre : c’est une règle à construire et à tester. Hébergement, conservation et traçabilité se définissent selon vos contraintes ; aucun dispositif universel n’est présumé.

03Les actionsQu’est-ce qui exige une validation ?

Envoyer une relance, déposer une pièce, modifier un statut partagé : chaque action est une autorisation distincte.

04Les exceptionsQuand l’équipe reprend-elle la main ?

Rattachement ambigu, pièce contradictoire, demande sensible, refus de communiquer : le système signale, il ne tranche pas.

Un statut proposé peut être faux. Les sources, les tests sur un dossier connu et la validation de l’équipe réduisent ce risque. Ils ne remplacent pas le jugement.

Un autre besoin ?

Retrouver, trois mois plus tard, pourquoi une pièce a été jugée non applicable.

Découvrir Company Brain

06Une expérience dans le conseil M&A

Une expérience réelle.
Pas un résultat promis.

Pour un acteur international du conseil M&A, nous avons conçu une application interne et un espace client qui centralisent missions, cibles, relances, documents et reporting.

Conception sur mesure · suivi opérationnel M&A

Ce que cette expérience apporte

La structuration de dossiers M&A, le suivi des relances et le partage d’informations avec un client, entre plusieurs outils et plusieurs intervenants.

Ce qu’elle ne prouve pas

Un suivi de request list déjà livré à l’identique, un gain de temps chiffré ou une due diligence plus courte. Votre premier périmètre se vérifie dans votre contexte.

Voir le cas sur la page M&A

07Un premier périmètre

Un dossier clos pour éprouver.
Le suivant pour s’en servir.

On ne change pas d’outil au milieu d’une due diligence. On part d’une request list réelle et, si un dossier clos exploitable est disponible, on éprouve le suivi dessus avant le process suivant. Sinon, nous convenons d’un autre jeu de vérification.

  1. 01

    Choisir la liste.

    Une request list réelle et les outils qui l’entourent.

  2. 02

    Borner.

    Les sources lues, les statuts, qui valide quoi.

  3. 03

    Rejouer un dossier clos.

    Le suivi retrouve-t-il ce qui manquait, et à quel moment ?

  4. 04

    Passer au process suivant.

    Des critères convenus, un suivi, des corrections.

Comment mesurer la réussite

Sur un dossier connu : les manques retrouvés, la justesse des statuts, des relances sans erreur de contexte, le temps pour produire un point d’avancement.

Hors de ce premier périmètre

  • L’envoi automatique des relances
  • La revue du contenu des pièces
  • L’analyse des risques

04semaines

Notre MVP vise une première valeur en quatre semaines, sur un périmètre convenu. Le chiffrage dépend des sources, des accès et des règles retenues.

Partir de votre request list

Questions pratiques

Avant la prochaine request list.

Pour quelles équipes ce suivi des pièces manquantes est-il pensé ?

Côté cédant, les conseils M&A et cabinets de corporate finance qui tiennent la data room et collectent les pièces. Côté acquéreur, les fonds, conseils et directions M&A qui envoient les listes et doivent savoir, avant l’offre, ce qui n’a pas été communiqué.

Notre data room a déjà une request list. Pourquoi aller plus loin ?

Si elle couvre votre suivi, gardez-la : nous commençons par vérifier ce qu’elle fait déjà. Le sujet commence là où la liste, les emails et le client se croisent. S’il ne reste rien à relier, il n’y a pas de projet.

Faut-il changer de fichier de suivi, de data room ou de CRM ?

Non. Le suivi part de vos outils et de vos formats, y compris la liste envoyée par la contrepartie. Les connexions possibles se vérifient au cadrage ; aucune intégration n’est supposée disponible avant d’avoir été examinée.

L’IA peut-elle déclarer une pièce complète ?

Non. Elle contrôle ce qui est vérifiable selon vos critères écrits, comme la période, l’entité ou la version, propose un statut et signale ses doutes. La complétude reste une décision de l’équipe.

Les relances partent-elles seules ?

Non. Elles sont préparées par responsable, avec le contexte du dossier, puis validées et envoyées par l’équipe. Un envoi automatisé serait une permission distincte, à cadrer séparément.

Que préparer pour un premier échange ?

Une request list, même anonymisée, ou simplement sa structure. Les outils concernés et les personnes qui interviennent. Aucun document confidentiel n’est nécessaire.

Partons de votre liste

Qu’est-ce qui manque encore
à votre dossier en cours ?

Venez avec une request list, même anonymisée. Nous regardons où le manquant se perd et ce qui mérite d’être relié. Aucun document confidentiel n’est nécessaire.

Parler de votre request list Ou écrivez-nous