La couche de vérification : le maillon manquant de la plupart des deal flows

Chaque stack de deal flow organise les candidatures : les outils d'intake les collectent, les CRM les suivent, les terminaux data les enrichissent, les tableurs les scorent. Presque aucun ne répond à la question qui est sous toutes les autres, ce claim est-il vrai ? Cette question est une couche à part, et dans la plupart des fonds elle est absente. Ce texte explique ce qu'est la couche de vérification, pourquoi le reste du stack ne peut pas la couvrir, et où elle se place.

Regardez les outils qu'un fonds fait tourner et vous trouverez le parcours du candidat bien instrumenté. Le formulaire a été collecté, le contact loggé, la boîte enrichie avec l'effectif et les données de levée, les évaluateurs ont laissé des notes dans un tableur partagé. Tout cela suppose que l'entrée est exacte. Rien ne le vérifie. Le deck dit que le marché fait 45 milliards, le tableur enregistre une bonne note de marché, et aucune étape de la chaîne n'a jamais demandé si le 45 était réel ou si le chiffre atteignable était plutôt proche de 10.

C'est le trou que comble la couche de vérification. Ce texte la définit, montre pourquoi les outils d'intake, les CRM et les terminaux data ne peuvent structurellement pas l'être, décrit ce que la vérification fait vraiment quand elle est honnête, explique où elle se branche dans un stack existant, et énonce ses vraies limites pour que le propos reste crédible.

Le stack que vous avez déjà, et le trou dedans

La plupart des stacks de deal flow sont bâtis de quatre types d'outils, et chacun fait bien son travail :

• Les outils d'intake et de candidature collectent les dossiers, les routent, enregistrent les notes. Ils organisent le flux.
• Les CRM de deal flow suivent relations et pipeline dans le temps. Ils se souviennent de qui vous connaissez et où en est un deal.
• Les terminaux data vendent de la donnée structurée : levées, effectif, signaux. Ils fournissent la couverture.
• Les tableurs et formulaires vous donnent un endroit où mettre une note. Ils permettent de démarrer.

Alignez-les et quelque chose manque de façon flagrante. Aucun ne demande si les affirmations dans une candidature sont vraies. L'outil d'intake classe le claim, le CRM suit la boîte qui l'a fait, le terminal ajoute de la donnée adjacente, le tableur score le récit. Le claim lui-même, l'assertion porteuse sur laquelle repose la décision, traverse tout le stack sans être examiné. Ce claim non examiné est la perte que personne ne voit venir, parce que chaque outil de la chaîne l'a traité comme une entrée plutôt qu'une question.

Pourquoi le reste du stack ne peut pas la couvrir

Il est raisonnable de demander pourquoi un outil existant ne peut pas juste ajouter la vérification. La réponse, c'est que la vérification est un travail différent, pas une fonctionnalité à boulonner, et les catégories sont bâties autour de travaux différents.

Le travail d'un outil d'intake, c'est le workflow : faire entrer le dossier, le router, enregistrer l'issue. Vérifier un claim exige d'aller hors du dossier vers des sources publiques, ce qui est orthogonal à l'organisation du flux. Le travail d'un CRM, c'est la mémoire et les relations ; il enrichit la fiche de la boîte mais ne juge pas si un claim précis dans un dossier précis tient. Le travail d'un terminal data, c'est la couverture : il vous dit ce qui existe, tours de levée, effectif, mais « cette boîte a levé un tour » n'est pas la même chose que « la traction annoncée de cette boîte est réelle », et la couverture n'est pas le jugement. Un tableur fait ce que vous y tapez, ce qui veut dire que la vérification dans un tableur, c'est un humain qui vérifie les claims à la main, l'étape qui ne passe jamais à l'échelle et donc n'arrive jamais.

Rien de tout cela n'est un défaut des outils. Ce ne sont simplement pas des outils de vérification, pas plus qu'un classeur n'est un fact-checker. La couche est absente parce qu'aucune catégorie du stack standard n'a la forme pour la contenir.

Ce que la couche de vérification fait vraiment

La vérification, bien faite, est un process précis, pas une ambiance de rigueur. Elle sort les affirmations matérielles d'un dossier, les chiffres et énoncés sur lesquels repose la décision, et recoupe chacun contre la preuve publique.

L'ordre compte. Registres officiels d'abord, existence légale, dépôts, les enregistrements qui font autorité là où ils s'appliquent, puis recherche web sourcée pour ce que les registres ne tranchent pas. Chaque claim revient avec un verdict : vérifié, nuancé, contredit, ou à confirmer. Une contradiction n'est pas une note de bas de page, elle change la note. Un « à confirmer » est une information honnête dont le comité a besoin, pas un échec à cacher.

Deux règles d'honnêteté gardent la couche crédible. D'abord, faire correspondre un nom de boîte dans un registre prouve qu'une entité existe, pas qu'un claim particulier à son sujet est vrai, donc la vérification ne crédite un claim que quand la preuve soutient le claim lui-même. Ensuite, une métrique qui bouge dans le temps, un nombre de clients d'il y a trois ans, une valorisation d'un tour précédent, est traitée avec soin plutôt que scorée comme un mensonge parce qu'une source périmée dit autre chose. Une couche de vérification qui sur-affirme est pire que rien, parce qu'elle blanchit une supposition en verdict. Appliquée honnêtement, elle fait l'inverse : elle vous dit exactement combien de poids chaque claim peut porter.

Où elle se branche

La couche de vérification n'est pas un remplacement du stack, c'est l'étape que le stack saute. Elle se place entre collecter un dossier et décider dessus : après l'intake, avant le scoring, ou pendant. L'outil d'intake collecte toujours, le CRM suit toujours, le terminal enrichit toujours. La vérification ajoute le contrôle qui transforme un chiffre annoncé en un fait au statut connu avant qu'il soit scoré et avant qu'il atteigne un comité.

Placée là, elle change ce avec quoi tout l'aval travaille. La note reflète ce qui est réel plutôt que ce qui est affirmé. Le mémo porte les claims avec leur provenance plutôt que la parole du fondateur. Le comité décide sur preuve plutôt que sur un récit soigné. Le reste du stack continue son travail ; la vérification empêche juste que ce travail soit fait sur des entrées non vérifiées.

Les limites honnêtes

Un plaidoyer crédible pour la couche de vérification doit dire où elle s'arrête. Elle est la plus forte sur les claims vérifiables : existence légale, historique de levée, un partenariat nommé, un brevet, une taille de marché annoncée, des faits que la preuve publique peut confirmer ou contredire. Elle est la plus faible sur les claims ponctuels et prospectifs : une métrique qui a légitimement changé depuis son énoncé, une projection, tout ce dont la vérité dépend de données privées qu'aucune source publique ne détient. Sur celles-là, la vérification honnête nuance plutôt qu'affirme, et le dit.

Cette limite est une force, pas une excuse. Une couche de vérification qui prétendrait juger l'inconnaissable vendrait la même fausse certitude que le claim non vérifié qu'elle remplace. La valeur n'est pas qu'elle vérifie tout. C'est qu'elle vérifie ce qui est vérifiable, étiquette honnêtement ce qui ne l'est pas, et vous dit ainsi sur quelles parties d'un dossier vous pouvez vous appuyer et lesquelles non. C'est précisément l'information que le reste du stack ne peut pas vous donner.

Foire aux questions

Qu'est-ce qu'une couche de vérification dans le deal flow ? C'est l'étape qui vérifie si les affirmations matérielles d'un dossier sont vraies, en testant chacune contre des sources publiques et en rendant un verdict, vérifié, nuancé, contredit, ou à confirmer, avant que le dossier soit scoré ou porté en comité. Distincte de collecter, suivre, enrichir ou scorer.

Pourquoi mon CRM ou mon outil d'intake ne peut-il pas faire la vérification ? Parce que leurs travaux sont différents. L'intake organise le flux, un CRM gère mémoire et relations, un terminal fournit la couverture. Aucun ne juge si un claim précis tient face à la preuve publique, ce qui est une tâche à part, pas une fonctionnalité qu'ils ont la forme d'ajouter.

L'enrichissement, c'est la même chose que la vérification ? Non. L'enrichissement ajoute de la donnée adjacente sur une boîte, levée, effectif, signaux. La vérification vérifie si les claims que la boîte elle-même a faits sont vrais. Savoir qu'une boîte a levé un tour n'est pas confirmer que sa traction annoncée est réelle.

Quels claims peut-on vraiment vérifier ? Les vérifiables : existence légale, historique de levée, partenariats nommés, brevets, tailles de marché annoncées, des faits que la preuve publique peut confirmer ou contredire. Les métriques ponctuelles et les projections sont nuancées plutôt qu'affirmées, parce que leur vérité peut dépendre de données qu'aucune source publique ne détient.

Ajouter une couche de vérification remplace-t-il mes outils existants ? Non. Elle comble le trou entre collecter un dossier et décider dessus. L'intake collecte toujours, le CRM suit toujours, le terminal enrichit toujours, la vérification ajoute le contrôle qui transforme les chiffres annoncés en faits au statut connu avant qu'ils soient scorés.

En résumé

La couche de vérification est la question que le reste du stack de deal flow suppose que quelqu'un d'autre a tranchée : ce claim est-il vrai ? L'intake, le CRM, le terminal et le tableur font chacun un vrai travail, et aucun ne fait celui-ci, parce que c'est un travail différent. Ajoutez la couche là où le stack la saute, entre collecte et décision, appliquez-la honnêtement à ce qui est vérifiable, et la note, le mémo et le comité se mettent tous à travailler avec de la preuve au lieu d'affirmations.

Comment ça se traduit dans Deckwise

La vérification n'est pas un ajout dans Deckwise, elle traverse les trois piliers. En Prospection elle qualifie les candidats face à la donnée publique ; en Sélection elle recoupe chaque claim matériel avant le scoring, pour que le rang reflète le réel ; en Due Diligence elle produit un mémo où chaque claim porte son verdict et sa source. Les registres d'abord, puis la recherche web sourcée, et les métriques ponctuelles sont nuancées plutôt qu'appelées mensonges. Elle complète les outils d'intake et les CRM que vous faites déjà tourner, en ajoutant la couche qu'ils n'ont jamais été bâtis pour contenir.

Voir aussi : Comment choisir un outil de screening · Le guide complet de la due diligence · La Méthode Deckwise