L'idée de DataToForm n'est pas née d'un seul moment. Elle est née de deux situations distinctes, dans des contextes très différents, qui posaient exactement le même problème — et pour lesquelles il n'existait aucune solution directe.
Cas 1 — La finance et ses formulaires réglementaires
Dans les équipes financières, les données vivent dans Excel. Des fichiers denses, souvent complexes : plusieurs onglets, cellules fusionnées, colonnes calculées, structures non normalisées qui ont évolué avec les années. Ces données — portefeuilles, positions, caractéristiques de contrats, reporting de risques — doivent régulièrement alimenter des portails réglementaires, des back-offices propriétaires, des outils de reporting imposés par des prestataires ou des autorités de tutelle.
Aucun de ces systèmes n'expose d'API utilisable. Certains ont des APIs internes, fermées, documentées nulle part. D'autres sont des applications web de dix ans qui n'ont jamais eu vocation à être interfacées automatiquement.
Résultat : un analyste qui doit traiter cinquante dossiers dans un portail réglementaire passe sa demi-journée à reproduire ce qui est déjà dans son fichier. Copier le code ISIN. Basculer. Coller. Copier la valeur nominale. Basculer. Coller. Et ainsi de suite pour chaque champ, chaque ligne, chaque déclaration.
Le problème devient critique quand les données changent. Une mise à jour de référentiel, une correction de valorisation — et il faut recommencer. Pas d'import, pas de synchronisation, juste quelqu'un qui recopie à la main ce qu'une autre personne a déjà saisi ailleurs.
Cas 2 — L'agence et la re-contribution multilingue
Dans les startups avec une présence internationale, et dans les agences de communication qui gèrent des sites clients en plusieurs langues, une autre variante du même problème apparaît.
L'équipe contenu produit ses textes dans Excel ou Google Sheets : une colonne par champ, une série de colonnes par langue. titre_fr, description_fr, titre_en, description_en, titre_es, description_es. Une ligne par article, par fiche produit, par page de destination.
Vient ensuite la contribution dans le back-office — WordPress, Drupal, Strapi, un ERP maison, peu importe. On ouvre l'interface admin, on crée le contenu en français, on remplit champ par champ. Puis on bascule sur la version anglaise, on recrée le même contenu, on remplit à nouveau. Puis l'espagnol. Pour chaque article. Pour chaque langue.
Le pire n'est pas la saisie initiale — c'est la re-contribution. Le client demande de reformuler un paragraphe, d'ajuster le ton, de corriger une traduction. Il faut retrouver chaque entrée dans chaque langue, ouvrir chaque formulaire, modifier chaque champ. Une mise à jour de contenu peut coûter autant en temps que la saisie initiale. Pour une agence qui facture au temps passé, c'est du travail non valorisable. Pour une startup sans développeur disponible, c'est une charge qui s'accumule et qu'on repousse.
Ce que ces deux cas ont en commun
Finance réglementaire et back-offices CMS multilingues : rien de commun en surface. Et pourtant, la structure du problème est identique.
Les données existent. Elles sont dans un fichier structuré, propre, validé. Quelqu'un les a déjà saisies, vérifiées, approuvées.
La destination est connue. C'est un formulaire web à l'écran, avec des champs précis qui attendent des valeurs précises.
Le travail intermédiaire est purement mécanique. Regarder la valeur dans Excel, la trouver dans le formulaire, la copier, recommencer. Aucune valeur ajoutée, juste de l'occupation — et une source d'erreurs.
Dans les deux cas, la question est la même : pourquoi est-ce que quelqu'un doit faire ça à la main ?
Pourquoi les outils existants ne répondaient pas
Zapier et Make connectent des applications entre elles via des APIs et des webhooks. Ils sont excellents quand les deux côtés de la connexion ont un connecteur disponible. Un portail réglementaire maison ou un back-office sans API ? Hors de portée.
Les outils RPA (UiPath, Power Automate Desktop) peuvent interagir avec des interfaces web, mais ils nécessitent un développeur pour configurer chaque formulaire et une maintenance continue quand les interfaces changent. Ce n'est pas un outil — c'est un projet.
Les agents IA autonomes (Browser Use, Skyvern, Operator) sont une catégorie plus récente. Ils ouvrent un navigateur, "comprennent" la page et agissent seuls. Prometteur — sauf qu'ils soumettent automatiquement. Pour une déclaration réglementaire ou une publication de contenu en production, laisser une IA décider sans relecture humaine crée des risques concrets : données mal interprétées, contenu publié sans validation, correction impossible après soumission.
La question que j'ai formalisée
Peut-on automatiser le copier-coller sans retirer l'humain de la boucle ?
Cinq conditions implicites :
- Source : un fichier Excel ou CSV existant, sans reformatage préalable
- Cible : n'importe quel formulaire web, sans API, sans connecteur
- Intelligence : une IA suggère la correspondance colonnes → champs
- Contrôle : l'humain valide le mapping avant remplissage
- Arrêt délibéré : le formulaire est pré-rempli, et on s'arrête là — c'est l'humain qui soumet
La cinquième condition est la plus structurante. Elle distingue DataToForm de tous les agents autonomes — pas par défaut, mais par construction.
Premier dessin de la solution
Trois briques sur le papier :
Un parser Excel intelligent. Les fichiers réels ont des cellules fusionnées, des titres au milieu des données, plusieurs onglets, des colonnes calculées. SheetJS peut lire ces fichiers, mais comprendre leur structure nécessite une aide — premier appel LLM pour identifier les vraies colonnes de données.
Un inspecteur de formulaire en vrai navigateur. Playwright ouvre un vrai Chromium, charge la page avec son JavaScript et ses composants dynamiques. L'inspecteur lit ce que le navigateur rend réellement — les champs visibles, leurs labels, leurs types.
Un LLM comme pont sémantique. Il ne voit jamais les valeurs du fichier — seulement les noms de colonnes et les labels de champs. Il comprend que titre_fr correspond au champ "Titre (français)" dans le back-office, que ISIN va dans "Code valeur". Sémantique pure, sans accès aux données.
Il reste à coder. C'est l'objet de l'épisode suivant.