Il y a deux façons de construire une application métier.
Dans la première, l’écran et la base de données se parlent directement. Le formulaire écrit dans la table, la liste lit la table, et le reste — les exports, les connecteurs, « l’API » promise sur la plaquette — vient après, comme une porte de service percée dans un mur porteur. Elle couvre ce que l’éditeur a eu le temps de couvrir. Le jour où vous demandez une chose qui n’y figure pas, la réponse est un ticket, et le ticket a une date.
Dans la seconde, l’écran n’est qu’un client parmi d’autres. Chaque création, chaque lecture, chaque modification, chaque suppression — le CRUD, dans le jargon — passe par une API, la même pour l’interface et pour n’importe qui d’autre. Toute opération que l’écran sait faire, un script peut le faire par API. C’est ainsi qu’est construite l’architecture de DealFlux, et c’est ce que ça permet que décrit cet article.
Ce que « tout passe par l’API » veut dire concrètement
DealFlux est un front posé sur une base de données exposée par API. Quand un gestionnaire déplace un projet d’une étape à l’autre, l’interface envoie une requête PATCH sur l’objet de suivi. Quand un évaluateur enregistre une note, c’est un POST. Quand la liste des projets s’affiche, c’est un GET avec des filtres.
Rien d’autre ne se passe en coulisses. Il n’y a pas de second chemin, réservé à l’application, par lequel les données entreraient ou sortiraient sans que l’API le sache.
Trois conséquences en découlent, et ce sont elles qui comptent :
Le contrat est complet par construction. La documentation OpenAPI de l’API est générée depuis le schéma réel — collections, champs, relations, permissions. Un champ ajouté à un formulaire existe dans l’API à la seconde où il existe dans la base. Elle se consulte et s’essaie requête par requête, dans une interface Swagger, sur interface.dealflux.com/api-docs.
Les droits sont les mêmes des deux côtés. Un évaluateur qui ne voit que les dossiers qui lui sont attribués à l’écran ne voit que ceux-là par l’API, avec le même jeton. Il n’y a pas de « mode API » plus permissif, parce qu’il n’y a pas de mode API du tout : il n’y a que l’API.
L’application ne peut rien vous cacher. Tout ce qu’elle stocke, vous pouvez le lire ; tout ce qu’elle sait faire, vous pouvez le déclencher. Ce n’est pas une promesse commerciale, c’est une propriété de l’architecture.
Airtable comme second écran
Prenons le cas le plus courant.
Un réseau de Business Angels suit ses dossiers dans DealFlux : dépôt, instruction, comité, investissement. Mais son comité mensuel s’est habitué à une vue Airtable — une grille filtrée par étape, avec un champ « remarque du président » qui n’a rien à faire dans le dossier officiel, et une vue calendrier pour les échéances.
Avec une application fermée, cette vue se remplit à la main, ou par un export CSV du lundi matin que quelqu’un colle dans Airtable. Deux sources, décalées d’une semaine, dont on ne sait bientôt plus laquelle fait foi.
Avec une API complète, la vue Airtable se synchronise. Un script Airtable, ou un automate comme Make ou n8n, interroge /items/projet toutes les heures avec le filtre de l’étape « Comité », et crée ou met à jour les fiches. Le champ « remarque du président » reste dans Airtable, où il est à sa place. Les données de dossier, elles, ne sont jamais ressaisies : elles viennent de DealFlux et y retournent si on le souhaite — un PATCH suffit à faire remonter une décision prise en séance.
Airtable n’est ici qu’un exemple. Remplacez-le par Notion, par un Google Sheet, par un tableau de bord Metabase ou Looker Studio : le raisonnement est le même, parce que l’interlocuteur est le même — une API HTTP documentée, avec un jeton.
Les solutions internes, celles qu’on ne remplace pas
Le cas plus sérieux, c’est celui des outils que vous avez déjà et que vous garderez.
Un fonds a son outil de reporting aux LP, développé en interne il y a six ans, qui attend un fichier dans un format précis chaque trimestre. Une fondation a son logiciel comptable, où chaque subvention accordée doit être créée comme engagement. Un incubateur a son intranet, où l’annuaire des startups accompagnées sert à tout le monde.
Aucun éditeur ne fera de connecteur pour ces outils-là. Il n’y en a qu’un exemplaire au monde.
C’est précisément le cas où « tout passe par l’API » cesse d’être un argument d’architecte pour devenir une question de survie de l’outil. Votre développeur — ou votre prestataire, ou l’automate que vous configurez — écrit vingt lignes qui lisent les projets passés en étape « Investi » ce trimestre, et les déposent au format attendu. Il n’a rien demandé à personne. Il n’a pas attendu une feuille de route. Il a lu la documentation, obtenu un jeton, et le pont existe.
Et dans l’autre sens : quand votre intranet crée une fiche startup, il peut créer le dossier dans DealFlux au même moment. Le porteur reçoit son accès, le pipeline démarre, et personne n’a ressaisi le SIREN.
Ce que l’on gagne quand on n’est pas enfermé
La question à poser à tout outil métier n’est pas « que sait-il faire ? » mais « que puis-je lui faire faire sans lui demander la permission ? ».
Une application dont l’API est une porte de service répond : ce qui est prévu. Une application dont l’API est la seule porte répond : tout ce que vous savez faire vous-même.
La différence se mesure aussi le jour où l’on part. Toutes les données — projets, évaluations, messages, documents, historique — sont extractibles en entier, par les mêmes requêtes que celles que l’application utilise chaque jour. Un outil qu’on peut quitter sans perte est un outil qu’on choisit librement de garder.
Ce que l’API ne fait pas à votre place
Il serait malhonnête de s’arrêter là.
Une API ne fait pas l’intégration ; elle la rend possible. Il faut quelqu’un pour écrire le script, ou pour configurer l’automate, et pour le maintenir quand l’outil d’en face évolue. C’est du travail — moins que la double saisie sur un an, mais du travail.
Un jeton est une clé. Il ouvre exactement ce que le rôle de son détenteur ouvre, ni plus ni moins ; il faut donc créer un rôle pour l’intégration, avec les seuls droits nécessaires, et non prêter le jeton d’un gestionnaire. La règle est la même que pour un badge.
Et une synchronisation à double sens demande de décider, avant de la brancher, qui a raison des deux. L’API ne tranchera pas à votre place. Elle fera exactement ce qu’on lui dit, dans les deux sens, ce qui est précisément la raison d’y réfléchir d’abord.
Le critère
Avant de choisir un outil de gestion de dealflow, d’appels à projets ou d’accompagnement, posez une seule question : l’interface utilise-t-elle la même API que celle qu’on me propose ?
Si l’on vous répond par une liste de connecteurs, vous avez votre réponse : les limites de l’outil, énumérées à l’avance. Mais si l’on vous répond par l’affirmative et que vous pouvez le constater dans une documentation ou une requête sur un dossier que vous connaissez, cela vous montrera non seulement ce que l’outil sait faire aujourd’hui, mais ce que vous pourrez lui faire faire en plus vous-même demain.