---
title: "Automatiser la configuration d'une data room de levée de fonds avec le CLI Papermark (2026)"
lang: fr
canonical_url: https://www.papermark.com/fr/blog/automate-fundraising-data-room-papermark-cli
last_updated: 2026-07-08
published: 2026-07-03
category: [datarooms, fundraising]
author: "Marc Seitz"
summary: "Un seul script shell transforme un dossier local en une data room de levée de fonds structurée avec des liens par investisseur, une vérification par e-mail et des dates d'expiration. Guide pratique du CLI Papermark avec code."
---

# Automatiser la configuration d'une data room de levée de fonds avec le CLI Papermark (2026)

Un seul script shell peut transformer un dossier de PDFs sur votre ordinateur en une data room de levée de fonds structurée, avec un lien distinct, sécurisé par e-mail et à expiration automatique pour chaque investisseur de votre liste. Le `papermark` CLI (disponible sur npm) encapsule l'ensemble de l'[API data room Papermark](/fr/blog/data-room-api.md) avec une sortie JSON lisible par machine, ce qui permet d'automatiser facilement l'ensemble du workflow : téléversement, organisation, génération de liens, affichage de la liste. Ce guide vous fournit le script complet ainsi que les éléments pour l'adapter, à destination des fondateurs techniques qui préfèrent passer quinze minutes à écrire du bash plutôt qu'un week-end à cliquer dans un tableau de bord.

## Pourquoi automatiser votre data room de levée de fonds ?

Un processus de levée de fonds est répétitif par nature. Chaque investisseur accède à la même data room, mais a besoin d'un accès personnalisé : son propre lien, sa propre vérification par e-mail, son propre suivi analytique pour savoir qui a réellement consulté les données financières avant la réunion avec les associés. Faire cela manuellement pour 20 fonds, c'est 20 configurations de liens identiques à réaliser, et recommencer une partie du travail à chaque nouvelle version du pitch deck.

L'automatisation résout à la fois la répétitivité et les problèmes de cohérence. La liste de liens est générée automatiquement, donc aucun investisseur n'est oublié. Les paramètres de sécurité sont définis dans le code, donc aucun lien ne peut être envoyé par accident sans date d'expiration. Et lorsque vous lèverez à nouveau dans 18 mois, le script servira de documentation sur le fonctionnement de votre dernier processus. La structure sous-jacente suit le modèle standard de [data room de levée de fonds](/fr/blog/why-startups-need-virtual-data-room-for-fundraising.md) ; nous la rendons simplement reproductible.

Le coût caché de l'approche manuelle n'est pas le temps passé à cliquer, c'est la dérive. À la douzième entreprise pour laquelle vous configurez un lien à la main, vous avez cessé de vérifier systématiquement le paramètre d'expiration et la porte d'accès par e-mail — et c'est précisément à ce moment-là qu'un lien part grand ouvert. Un tour de table bouclé avec une URL active et non protégée qui traîne dans la boîte mail d'un partenaire, c'est le genre de fuite qui ne se révèle jamais avant qu'un concurrent cite vos chiffres. Quand les paramètres sont définis dans un script, chaque investisseur obtient exactement la même politique d'accès, bit pour bit, et cette politique peut être examinée dans une pull request avant même que le moindre lien n'existe. C'est ainsi que l'automatisation de la data room fonctionne, à la manière de l'infrastructure-as-code : la configuration est la source de vérité, et non l'état dans lequel se trouve le tableau de bord à un instant donné.

Il y a également un avantage en matière d'audit. Une data room virtuelle scriptée vous laisse avec deux artefacts que vous pouvez intégrer au dépôt de la transaction : le script qui a construit la salle et le `links.csv` qu'il a généré. Six mois plus tard, lorsqu'un virement est en cours de finalisation et que les juristes demandent qui avait accès au tableau de capitalisation et à quel moment, vous répondez depuis le contrôle de version plutôt que de mémoire. Pour un fondateur technique, cette reproductibilité vaut bien plus que les quinze minutes que le script économise le jour de la mise en place.

La CLI est le bon outil pour cette tâche : elle est conçue pour les scripts ponctuels, les tâches cron et la CI, avec environ 50 à 150 ms par appel. Si vous construisez plutôt un service backend, appelez directement l'[API REST](https://www.papermark.com/docs/api), et si vous préférez dialoguer plutôt que scripter, le même workflow est accessible via [Claude et le serveur MCP](/fr/blog/how-to-create-data-room-with-claude.md).

## Configuration : installation et connexion

Deux commandes. Vous avez besoin de Node 24+ et d'un abonnement Papermark avec accès API (Business ou supérieur ; l'abonnement Data Rooms est à 99 €/mois avec un essai gratuit de 7 jours).

```bash
npm install -g papermark
papermark login
```

`papermark login` lance un flux OAuth 2.1 par appareil : il affiche un code, vous l'approuvez dans le navigateur, et le jeton est enregistré sur le disque avec les permissions `0600`. En environnement CI, définissez la variable d'environnement `PAPERMARK_TOKEN` avec un jeton généré depuis le tableau de bord. Confirmez avec `papermark whoami`, et en cas de problème, `papermark doctor` vérifie votre configuration, votre jeton et l'accessibilité de l'API.

Deux options globales rendent la CLI scriptable. `--json` force une enveloppe JSON stable (`{ "ok": true, "data": ... }`) et s'active automatiquement lorsque la sortie est redirigée, ainsi `jq` reçoit toujours une sortie lisible par machine. `--dry-run` affiche la requête HTTP qui serait envoyée, avec le jeton masqué, puis se termine — c'est le moyen le plus rapide de déboguer un script sans toucher à votre compte.

## Le script : dossier en entrée, liste de liens en sortie

Voici l'ensemble du script. Il s'attend à ce que vos documents soient organisés dans des sous-dossiers locaux (la [structure de collecte de fonds en six dossiers](/fr/blog/data-room-folder-structure.md) fonctionne très bien) et un fichier `vcs.txt` avec un nom de société et une adresse e-mail par ligne.

```bash
#!/usr/bin/env bash
set -euo pipefail

DEAL_DIR=~/deals/acme-series-a
ROOM_NAME="Acme Series A"
EXPIRY="2026-09-30T00:00:00Z"

## 1. Create the data room
DR_ID=$(papermark datarooms create \
  --name "$ROOM_NAME" \
  --description "Series A raise, Q3 2026" \
  --json | jq -r '.data.id')
echo "Created data room: $DR_ID"

## 2. Upload every PDF and attach it to the room
for f in "$DEAL_DIR"/**/*.pdf; do
  DOC_ID=$(papermark documents upload "$f" --json | jq -r '.data.id')
  curl -sX POST "https://api.papermark.com/v1/datarooms/$DR_ID/documents" \
    -H "Authorization: Bearer $PAPERMARK_TOKEN" \
    -H "Content-Type: application/json" \
    -d "{\"documentId\":\"$DOC_ID\"}" > /dev/null
  echo "Uploaded: $(basename "$f")"
done

## 3. One gated, expiring link per VC
echo "" > links.csv
while IFS=, read -r FIRM EMAIL; do
  URL=$(papermark links create \
    --dataroom "$DR_ID" \
    --name "$FIRM" \
    --email-protected \
    --expires "$EXPIRY" \
    --json | jq -r '.data.url')
  echo "$FIRM,$EMAIL,$URL" >> links.csv
done < vcs.txt

echo "Done. Link list written to links.csv"
```

Exécutez-le, et `links.csv` sera votre outil de prospection : société, contact, URL personnalisée. Chaque lien pointe vers la même salle, exige une vérification par e-mail, et expire le 30 septembre, que vous vous en souveniez ou non.

![Salle de données de levée de fonds créée par la CLI Papermark](https://assets.papermark.io/upload/file_35DtVER7SdS1G6unRE8unv-papermark-data-room.png)

_La salle de données structurée et les liens par investisseur que le script génère à partir d'un dossier local._

## Anatomie du script

L'étape 1 crée la salle et récupère son identifiant depuis l'enveloppe JSON avec `jq`. Tout ce qui suit dépend de `$DR_ID`, ce qui rend le script facile à adapter : modifiez le nom et le répertoire, et rien d'autre ne change.

L'étape 2 télécharge chaque PDF et l'associe à la salle. Les téléchargements s'effectuent via des URLs présignées S3 en coulisses, ce qui signifie qu'il n'y a aucune limite de taille de fichier à prendre en compte. Si vous relancez le script, commencez par lister ce qui se trouve déjà dans la salle (les sous-commandes `papermark datarooms` couvrent cela) et ignorez les doublons ; le [guide de démarrage CLI](https://www.papermark.com/docs/cli/getting-started) présente la variante idempotente.

L'étape 3 est là où se concentre la valeur spécifique à la levée de fonds. Les liens par VC signifient des analyses par VC : lorsque le lien de Sequoia indique 40 minutes passées sur le modèle financier et celui d'Index deux minutes sur la diapositive de couverture, vous savez exactement où concentrer votre semaine. La vérification par e-mail (`--email-protected`) confirme qui, au sein de la société, a réellement ouvert le document, et l'expiration impose une discipline de processus, car un tour de table clôturé ne devrait pas avoir de liens actifs qui circulent dans les boîtes mail. Vous pouvez également ajouter `--password` par lien si une société l'exige.

## CLI vs API REST vs serveur MCP vs tableau de bord

Le script ci-dessus utilise le CLI, mais la même salle de données de levée de fonds est accessible de quatre façons, et choisir la mauvaise peut faire perdre une après-midi. Papermark expose une seule interface — documents, salles de transaction, liens par investisseur, analyses investisseurs — derrière un seul token, et le CLI, l'API REST, le serveur MCP et le tableau de bord ne sont que des portes d'entrée différentes vers celle-ci. La question n'est jamais de savoir lequel est « le meilleur », mais lequel correspond à la tâche en cours, il est donc utile de préciser où chacun a sa place avant de lui confier un flux de travail.

Optez pour le CLI lorsque le travail est un script ponctuel, une tâche cron ou une étape dans la CI : il est optimisé pour exactement la forme dossier-en-entrée, liste-de-liens-en-sortie autour de laquelle cet article est construit, avec environ 50 à 150 ms par appel et aucun code répétitif. Optez pour l'[API REST](/fr/blog/data-room-api.md) lorsque vous créez un service backend qui génère des liens selon un calendrier ou en réponse aux événements de votre propre application, où vous souhaitez des réponses typées et un contrôle total sur les nouvelles tentatives. Optez pour le [serveur MCP](/fr/blog/papermark-mcp-server.md) lorsque vous préférez décrire le résultat plutôt qu'écrire les étapes, en laissant [Claude piloter l'automatisation de la salle de données](/fr/blog/how-to-create-data-room-with-claude.md) depuis une invite. Et le tableau de bord reste la meilleure option pour ce qu'un humain doit examiner à l'œil : parcourir une carte thermique, vérifier une salle avant de l'envoyer, ou gérer le lien unique et sur mesure pour lequel un script serait superflu.

| Interface | Idéal pour | Effort de configuration | Reproductibilité |
| --- | --- | --- | --- |
| CLI | Scripts ponctuels, tâches cron, étapes CI — la configuration de levée de fonds décrite dans cet article | Faible : npm install -g papermark, puis connexion | Élevée : le script constitue la trace de ce que vous avez fait |
| REST API | Services backend qui génèrent des liens selon un calendrier ou en réponse à des événements applicatifs | Moyenne : écrire et héberger le code d'intégration | Élevée, si votre code est versionné |
| MCP server | Workflows conversationnels et flexibles pilotés par Claude ou ChatGPT | Faible : connecter le serveur, puis envoyer des instructions en langage naturel | Faible : les instructions varient d'une exécution à l'autre |
| Dashboard | Consultation visuelle des analyses, vérifications rapides, liens personnalisés ponctuels | Aucun : se connecter et cliquer | Aucune : clics manuels, non enregistrés |

Pour la plupart des fondateurs, la démarche la plus pragmatique consiste à commencer avec le script présenté ici, à garder le tableau de bord ouvert pour un suivi visuel de l'engagement, et à passer à l'API REST ou au serveur MCP uniquement lorsqu'un besoin spécifique le justifie. Étant donné que les quatre interfaces partagent un seul token et un seul modèle de données, rien de ce que vous construisez via le CLI n'est jetable : la salle, les liens et les analyses sont identiques quelle que soit la porte par laquelle vous êtes entré.

## Sécurité et contrôle d'accès par lien investisseur

La levée de fonds est le moment où vos documents les plus sensibles — tableau de capitalisation, modèle financier, contrats clients — échappent à votre contrôle direct. La politique d'accès associée à chaque lien investisseur est donc aussi importante que le pitch deck lui-même. L'avantage d'une data room virtuelle scriptée, c'est que la sécurité cesse d'être une case à cocher que vous pourriez oublier pour devenir un ensemble de paramètres appliqués à chaque appel `links create`, de manière identique pour les 20 sociétés. Chaque contrôle disponible dans le tableau de bord est accessible depuis le CLI ou une requête curl, car ils utilisent tous la même API — rien dans l'approche scriptée ne vous oblige donc à sacrifier le contrôle au profit de la commodité.

Quatre indicateurs font l'essentiel du travail. `--email-protected` conditionne l'accès à la salle à une adresse e-mail vérifiée, ce qui vous permet de savoir qu'une vraie personne au sein du cabinet a ouvert le document, plutôt qu'une URL transférée ; `--password` ajoute un secret partagé pour les cabinets qui en font la demande ; `--expires` fixe une date limite stricte afin que l'accès expire avec le tour de table, que vous vous en souveniez ou non ; et les permissions de téléchargement déterminent si un lecteur peut récupérer les PDF ou seulement les consulter dans le navigateur. L'API sous-jacente prend également en charge le filigranage dynamique, qui imprime l'adresse e-mail de chaque lecteur sur toutes les pages, de sorte qu'un modèle financier capturé en screenshot soit directement traçable jusqu'au cabinet qui l'a divulgué. Combinez ces options dans le même appel `links create` et chaque lien investisseur est automatiquement accompagné de l'intégralité de la politique d'accès :

```bash
papermark links create \
  --dataroom "$DR_ID" \
  --name "Index Ventures" \
  --email-protected \
  --password "$SHARED_SECRET" \
  --expires "$EXPIRY" \
  --no-download \
  --json | jq -r '.data.url'
```

La révocation est le levier que les fondateurs oublient, et c'est pourtant celui que les scripts rendent trivial. Comme chaque cabinet dispose de son propre lien, vous pouvez supprimer l'accès d'un cabinet spécifique — un investisseur qui a décliné, une URL qui a fuité — sans affecter les dix-neuf autres, soit en supprimant le lien, soit en lui appliquant une date d'expiration déjà dépassée. Le modèle par investisseur garantit un contrôle d'accès granulaire par construction : il n'existe pas de lien partagé unique dont vous devez évaluer l'exposition, mais simplement une correspondance claire un-à-un entre cabinet, lien et historique analytique, que vous pouvez auditer à tout moment pendant la levée de fonds.

## Consulter les analyses investisseurs depuis le terminal

L'intérêt de scripter une data room de levée de fonds ne réside pas seulement dans sa construction, mais aussi dans son suivi. Une fois les liens envoyés, la levée devient un jeu d'information, et les analyses investisseurs vous indiquent où vous en êtes avant même qu'un associé ne vous en parle. Un cabinet qui passe vingt minutes sur le modèle financier et y revient deux fois mène une due diligence en interne ; un cabinet qui a ouvert la slide de couverture une seule fois sans jamais revenir représente un refus poli dont vous n'avez pas encore été informé. Lire ce signal depuis le terminal signifie que vous n'avez jamais besoin d'ouvrir un onglet de navigateur pour savoir qui est chaud, et que ce signal peut alimenter l'automatisation plutôt que de rester figé dans un tableau de bord.

Le même token qui a créé la salle permet de la consulter, ainsi les analytics se trouvent à une seule commande de là où vos scripts s'exécutent déjà. Les statistiques agrégées de la salle, les empreintes par spectateur et les événements de vue par lien ne nécessitent chacun qu'une seule commande, et comme la sortie est par défaut en JSON lors d'un pipe, `jq` permet d'extraire exactement le champ qui vous intéresse :

```bash
## Aggregate stats for the room
papermark datarooms stats "$DR_ID"

## One firm's footprint
papermark datarooms viewers "$DR_ID" --email partner@sequoia.com

## Raw view events for one link
papermark views list --link link_abcd1234 --json | jq '.data[]'
```

Redirigez l'un de ces résultats vers `jq` et vous obtenez un tableau de bord matinal dans votre terminal, ou une tâche cron qui publie sur Slack. Les codes de sortie sont contractuels (2 pour l'authentification, 3 pour la validation, 4 pour le réseau), ce qui permet à votre script de distinguer « token expiré » de « faute de frappe » sans analyser les messages d'erreur. La [documentation sur le contrat de sortie](https://www.papermark.com/docs/cli) répertorie chaque code.

Pour une analyse d'engagement plus approfondie, les données page par page derrière ces commandes correspondent aux mêmes [analytics par page](https://www.papermark.com/docs/api/reference) affichées dans le tableau de bord : quelles pages ont retenu l'attention, où les lecteurs ont décroché, depuis quel appareil et depuis quel emplacement.

Le vrai avantage est de transformer cette lecture en une notification proactive. Une douzaine de lignes de bash sur un cron planifié peut vérifier la salle chaque matin et vous alerter uniquement en cas de changement, de sorte que les analytics viennent à vous plutôt que l'inverse. L'approche consiste à récupérer le nombre de vues, à le comparer à celui de la veille, et à publier sur un webhook Slack lorsqu'une entreprise franchit un seuil justifiant une réaction :

```bash
#!/usr/bin/env bash
set -euo pipefail

NEW=$(papermark datarooms views "$DR_ID" --since 24h --json | jq '.data | length')
if [ "$NEW" -gt 0 ]; then
  curl -sX POST "$SLACK_WEBHOOK" \
    -H "Content-Type: application/json" \
    -d "{\"text\":\"$NEW new investor views in the last 24h\"}" > /dev/null
fi
```

Comme les codes de sortie sont contractuels, une tâche cron de ce type échoue de manière explicite et cohérente : un `2` vous alerte que le token a expiré, tandis qu'un `4` reste silencieux lors d'une coupure réseau passagère et réessaie à la prochaine exécution. Vous obtenez un flux d'analytics investisseurs directement dans la messagerie que vous utilisez déjà, construit sur le même CLI qui a créé la salle, sans onglet de tableau de bord laissé ouvert ni surveillance manuelle.

## Réutiliser le script d'une levée de fonds à l'autre

Un script de levée de fonds révèle vraiment sa valeur la deuxième fois que vous l'exécutez, pas la première. La plupart des entreprises lèvent des fonds plusieurs fois, et les éléments qui changent entre un seed et une Série A sont exactement les trois variables en haut du fichier : le répertoire de la transaction, le nom de la salle et la date d'expiration. Tout ce qui suit — la boucle d'upload, la logique de lien par investisseur, la sortie CSV — est indépendant de la levée. Traiter le script comme un petit outil paramétrable plutôt que comme un hack à usage unique signifie que la prochaine levée part d'une base solide et éprouvée plutôt que d'un terminal vide. Ce principe s'applique également à la démarche de [levée de fonds pour startups](/fr/blog/data-room-for-startups.md) à chaque étape, du pré-seed en avant.

Ce modèle s'étend au-delà des levées de fonds aux entités juridiques. Si vous gérez des SPV, un véhicule de fonds ou des salles distinctes pour les investisseurs existants et les nouveaux, le script devient une boucle sur un fichier de configuration : une salle par entité, chacune avec son propre jeu de documents et sa propre liste d'investisseurs, le tout généré en une seule passe. La même reproductibilité qui garantit une sécurité identique pour 20 sociétés garantit une structure identique pour cinq entités — ce qui correspond précisément à la rigueur [attendue par les VCs lorsqu'ils ouvrent votre data room](/fr/blog/vc-firms-data-room-essentials.md). Vous cessez de construire des salles manuellement et commencez à les déclarer.

La gestion des versions du pitch deck est le troisième cas de réutilisation, et c'est là que le modèle de documents de l'API démontre toute sa valeur. Lorsque le deck de métriques ou le modèle financier est mis à jour en cours de levée, vous ne créez pas un nouveau lien et ne le renvoyez pas ; vous publiez le nouveau fichier comme une nouvelle version du document existant, et le lien de chaque investisseur affiche désormais la version actuelle, tandis que les anciennes statistiques de consultation restent associées à la salle. Le lien qu'une société a mis en favori la première semaine fonctionne toujours la sixième semaine, pointant vers les chiffres de cette sixième semaine. Maintenir le deck à jour devient un simple upload en une ligne dans le même script, et non une course effrénée pour déterminer qui dispose de quelle version.

## Une levée de Série A, de bout en bout

Imaginez une fondatrice technique — appelons-la la CTO devenue PDG d'une startup d'infrastructure en phase d'amorçage — qui lance une Série A. Un lundi, elle exporte son dossier de deal dans la [structure en six dossiers](/fr/blog/data-room-folder-structure.md), dépose un `vcs.txt` avec 18 sociétés dans le répertoire et exécute le script. Quatre-vingt-dix secondes plus tard, la data room est créée, chaque PDF est téléchargé, et `links.csv` contient 18 liens protégés par email qui expirent le jour prévu pour la clôture du tour. Elle colle chaque lien dans un email d'introduction personnalisé et envoie la série avant le déjeuner. Une configuration qui aurait nécessité un samedi entier à cliquer dans des tableaux de bord est bouclée avant sa première réunion.

Dès mercredi, les analyses commencent à montrer leur valeur. Un `papermark datarooms stats` matinal révèle que Sequoia a passé 35 minutes sur le modèle financier et l'onglet de rétention des cohortes, et y est revenu deux fois ; Index a ouvert le deck une fois, s'est attardé sur la couverture, et n'est jamais revenu. Elle interprète cela avec précision : Sequoia mène une vraie due diligence et Index se désiste en douceur. Elle concentre donc ses relances sur les sociétés que les données indiquent comme intéressées, et quand le partner de Sequoia demande des chiffres NDR actualisés le jeudi, elle pousse une nouvelle version du modèle — le même lien continue de fonctionner, servant désormais la version à jour. Deux sociétés qu'elle n'a jamais contactées apparaissent dans la liste des visiteurs, transmises via une introduction chaleureuse, et comme les liens sont protégés par email, elle peut voir précisément qui elles sont.

Le vendredi suivant, elle reçoit une term sheet, et la boucle de révocation clôture le tour proprement : une exécution du script fait expirer les 18 liens, de sorte qu'aucun cap table actif ne traîne dans une boîte mail après la signature. L'ensemble de la levée a reposé sur le script qu'elle a écrit en quinze minutes, et `links.csv` ainsi que l'historique des analyses constituent son registre complet et auditable de qui a vu quoi et quand.

## Variantes à s'approprier

La mise à jour trimestrielle : encapsulez les étapes 1 et 2 dans une tâche cron qui synchronise un dossier exporté depuis Drive dans la salle chaque mois, afin que votre data room ne devienne jamais obsolète en pleine levée de fonds. Comme les uploads ignorent les fichiers existants, la synchronisation est légère.

La passe de révocation : lorsque le tour se clôture, listez les liens de la salle et supprimez-les en une seule boucle. C'est la seule opération destructrice du workflow, et l'exécuter via un script lisible vaut mieux qu'espérer n'avoir oublié aucun lien. (Gardez les suppressions hors des [mains des agents IA](/fr/blog/build-due-diligence-agent-claude.md) ; dans un script que vous avez écrit, elles ne posent aucun problème.)

La publication en CI : votre deck de métriques est de toute façon compilé en CI chaque mois, alors configurez le pipeline pour qu'il uploade le nouveau PDF en tant que nouvelle version et notifie votre liste de mise à jour investisseurs. Un token `pm_live_` avec uniquement le scope `documents.write`, défini comme secret CI, suffit amplement.

## Conclusion

Quinze minutes de bash vous donnent une data room de levée de fonds qui se configure elle-même, contrôle les accès par investisseur et rapporte son propre engagement. Le CLI, l'[API REST](/fr/blog/data-room-api.md) et le [serveur MCP](/fr/blog/papermark-mcp-server.md) exposent tous la même surface avec le même token — commencez par le script et passez à l'interface qui correspond au problème suivant. Le plan Data Rooms est à 99 €/mois avec un essai gratuit de 7 jours.

## Présentation du CLI Papermark

## FAQ

### Qu'est-ce que le CLI Papermark ?

Le client en ligne de commande officiel de Papermark, installé avec npm install -g papermark. Il encapsule la même API REST que le tableau de bord, avec des commandes pour les documents, les data rooms, les liens et les analyses de vues, ainsi qu'une sortie JSON stable pour les scripts.

### Faut-il être développeur pour l'utiliser ?

Vous avez besoin d'une aisance basique avec le terminal : exécuter des commandes et modifier un script shell. Le script complet de cet article est prêt à copier-coller ; il vous suffit de modifier trois variables (chemin du dossier, nom de la salle, date d'expiration) et de fournir un CSV de vos contacts investisseurs.

### Comment fonctionne l'authentification dans les scripts et en CI ?

En mode interactif, papermark login lance un flux OAuth 2.1 par device flow et stocke le token de manière sécurisée sur le disque. En CI ou dans des tâches cron, définissez la variable d'environnement PAPERMARK_TOKEN avec un token scopé depuis le tableau de bord. Un seul token fonctionne sur le CLI, l'API et le serveur MCP.

### Pourquoi créer un lien distinct pour chaque investisseur ?

Pour l'analyse et le contrôle. Chaque lien possède son propre historique de vues, ce qui vous permet de voir quelle société a consulté quoi et pendant combien de temps. La vérification par e-mail confirme qui a ouvert le lien, et vous pouvez expirer ou révoquer l'accès d'une société sans affecter les autres.

### Puis-je définir des mots de passe et des filigranes depuis le CLI ?

Oui. La création de liens prend en charge les mots de passe, la protection par e-mail, les dates d'expiration et les permissions de téléchargement sous forme de flags, et l'API sous-jacente prend également en charge le filigrane dynamique par lien. Tout ce que l'API supporte est accessible depuis le CLI ou un appel curl.

### Combien coûte cette configuration ?

Le CLI est gratuit à installer depuis npm. L'accès à l'API est inclus dans les plans Papermark Business et supérieurs ; le plan Data Rooms avec documents illimités, domaines personnalisés et journaux d'audit est à 99 €/mois avec un essai gratuit de 7 jours.

### Puis-je automatiser cela avec l'IA plutôt qu'avec bash ?

Oui. Le serveur MCP Papermark expose les mêmes opérations sous forme d'outils typés pour Claude et ChatGPT, de sorte que 'créer une data room depuis ce dossier avec des liens par VC' fonctionne comme une seule invite. La version bash est plus reproductible ; la version agent est plus flexible.

### Puis-je réutiliser le même script pour mon prochain tour de table ?

Oui, c'est justement l'intérêt. Seules trois variables changent entre une seed et une Série A : le répertoire du deal, le nom de la salle et la date d'expiration. La boucle d'upload, la logique de lien par investisseur et la sortie CSV sont indépendantes du tour, donc la prochaine levée démarre sur une base éprouvée. Le même schéma s'étend à plusieurs entités ou SPV en bouclant sur un fichier de configuration.

### Comment révoquer l'accès des investisseurs à la clôture du tour ?

Comme chaque société possède son propre lien, vous pouvez révoquer l'accès d'une société sans toucher aux autres en supprimant le lien ou en le mettant à jour avec une date d'expiration passée. Pour clore l'ensemble du tour, lancez une boucle sur les liens de la salle et faites-les tous expirer, afin qu'aucun cap table actif ne reste dans une boîte mail après la signature.

---

_Markdown version of [this article](https://www.papermark.com/fr/blog/automate-fundraising-data-room-papermark-cli) for AI agents and LLMs._
_More Papermark content: [llms.txt](https://www.papermark.com/fr/llms.txt) · [full index (English)](https://www.papermark.com/llms-full.txt)._