Il y a deux façons de construire une application métier : celle où l'écran parle directement à la base, et celle où l'écran n'est qu'un client parmi d'autres, servi par la même API que tout le monde. La seconde est celle que nous pratiquons chez Descartes. Voici ce qu'elle change, concrètement, pour les outils que vous avez déjà — et pour ceux que vous n'avez pas encore.
Deux façons de construire
Dans la première, le formulaire écrit dans la table et la liste lit la table. Tout 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. Chaque création, chaque lecture, chaque modification, chaque suppression passe par une API, la même pour l'interface et pour n'importe qui d'autre. Il n'existe aucune opération que l'écran saurait faire et qu'un script ne pourrait pas faire. C'est ainsi que sont bâties les applications que nous livrons, et c'est de cette différence que parle cet article.
Ce que cela veut dire, sans jargon
Nos applications métier reposent sur une base de données exposée par une API, et sur une interface qui n'a aucun privilège sur cette API. Quand une chargée de mission fait passer un dossier d'une étape à la suivante, l'écran envoie une requête de modification sur ce dossier. Quand un membre du jury enregistre une note, c'est une requête de création. Quand la liste des dossiers s'affiche, c'est une requête de lecture, 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 pour vous :
Le contrat est complet par construction. La documentation de l'API est engendrée depuis le schéma réel — objets, champs, relations, droits. 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 le navigateur.
Les droits sont les mêmes des deux côtés. Un bénévole qui ne voit que les dossiers de sa région à l'écran ne voit que ceux-là par l'API, avec le même identifiant. 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 un argument commercial, c'est une propriété de l'architecture — et elle se vérifie.
Le tableur du conseil, comme second écran
Prenons le cas le plus courant.
Une fédération instruit ses demandes de subvention dans son application : dépôt, instruction, commission, décision. Mais sa commission mensuelle s'est habituée à une vue tableur — une grille filtrée par étape, avec une colonne « 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 le tableur. 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 se synchronise. Un script, ou un automate comme Make ou n8n, interroge les dossiers de l'étape « Commission » toutes les heures et crée ou met à jour les lignes. La colonne du président reste dans le tableur, où elle est à sa place. Les données du dossier, elles, ne sont jamais ressaisies : elles viennent de l'application et y retournent si on le souhaite — une décision prise en séance remonte d'une requête.
Le tableur n'est ici qu'un exemple. Remplacez-le par Notion, par Airtable, par un tableau de bord de pilotage : le raisonnement est le même, parce que l'interlocuteur est le même — une API documentée, avec un identifiant.
Les outils qu'on ne remplacera pas
Le cas plus sérieux, c'est celui des outils que vous avez déjà et que vous garderez.
Une association a son logiciel comptable, où chaque subvention accordée doit être créée comme engagement. Un syndicat professionnel a son intranet, où l'annuaire des adhérents sert à tout le monde. Une PME a son outil de reporting, développé en interne il y a six ans, qui attend un fichier dans un format précis chaque trimestre.
Aucun éditeur ne fera de connecteur pour ces outils-là. Il n'en existe qu'un exemplaire au monde.
C'est précisément là que « tout passe par l'API » cesse d'être une affaire d'architecte pour devenir une question de survie de l'outil. Votre prestataire — nous, ou un autre, ou l'automate que vous configurez — écrit vingt lignes qui lisent les dossiers passés en étape « Accordé » 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 identifiant, et le pont existe.
Et dans l'autre sens : quand votre intranet crée une fiche adhérent, il peut créer le dossier dans l'application au même moment. La personne reçoit son accès, le circuit démarre, et personne n'a ressaisi le SIREN.
Ce que l'on gagne à ne pas être 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 — dossiers, évaluations, échanges, documents, historique — sont extractibles en entier, par les mêmes requêtes que celles que l'application utilise chaque jour. C'est vrai aussi de ce que nous livrons : 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 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, et nous le chiffrons avec vous.
Un identifiant d'API 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 l'identifiant 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 progiciel ou un développement sur mesure, le nôtre compris —, 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.