Ouvrir un outil à de vrais utilisateurs, c'est la partie qu'on anticipe mal. On pense avoir prévu les cas limites. On n'a pas prévu les bons.
Ce qui a fonctionné immédiatement
Les formulaires simples ont marché du premier coup. Formulaires d'inscription, espaces d'administration interne, portails avec des champs texte standard : le taux de mapping correct au premier essai dépasse 90%. Les utilisateurs RH en particulier ont été surpris par la vitesse — ce qui prenait 20 minutes se réduit à 30 secondes de configuration initiale, puis quelques secondes par ligne.
Un retour revient souvent dans les premiers jours : "Je ne savais pas que c'était possible sans développeur." C'est la chose la plus satisfaisante à entendre, parce que c'est exactement ce qu'on cherchait.
Ce qui a résisté
Certains cas ont été plus difficiles que prévu.
Les CMS à interface dynamique. WordPress avec Gutenberg génère une interface d'édition dont les champs ne sont pas des champs HTML standards — ils sont construits dynamiquement par React, avec des composants d'édition riches. L'inspecteur de formulaire détecte les mauvais éléments. Drupal avec des champs personnalisés pose des problèmes similaires.
Les formulaires multi-étapes. Certains formulaires SIRH sont des wizards en plusieurs pages — informations personnelles sur la page 1, données de contrat sur la page 2, données bancaires sur la page 3. Chaque étape nécessite de valider la précédente avant de charger la suivante. La gestion de l'état entre les étapes n'était pas encore dans le code.
Les selects en cascade dans les SIRH complexes. Même avec les améliorations de l'épisode 2, certains SIRH propriétaires ont des cascades à trois ou quatre niveaux avec des rechargements asynchrones très spécifiques. La logique de select-utils.js progresse à chaque cas rencontré.
La décision qui est devenue le cœur du produit
Au lancement de la beta, plusieurs utilisateurs ont cherché un bouton "mode automatique" — remplir ET soumettre sans intervention humaine. Ce bouton n'existe pas. Par conception.
Ce qui était initialement une précaution technique — ne pas prendre la responsabilité de soumettre des données sensibles à la place d'un humain — est devenu l'argument de confiance central du produit. Et les secteurs où DataToForm est le plus utile sont précisément ceux où cette garantie compte le plus : la RH, l'assurance, les services publics.
Les utilisateurs qui venaient avec des réticences initiales — "comment puis-je faire confiance à un outil qui touche à mes données URSSAF ?" — repartaient rassurés une fois qu'ils comprenaient le principe. L'outil pré-remplit. Il s'arrête. Vous relisez. Vous soumettez. L'outil ne soumet jamais pour vous.
Cette formule — "l'outil qui pré-remplit mais ne décide pas" — n'était pas dans le pitch initial. Elle est apparue dans les retours utilisateurs, et elle est maintenant au cœur de la communication.
Ce que les retours ont changé
Deux améliorations majeures sont venues directement des retours de la beta.
Le flux en direct du navigateur. Les premiers utilisateurs recevaient un message "remplissage terminé" sans voir ce qui se passait. Plusieurs ont demandé à pouvoir voir le formulaire se remplir en temps réel. C'est devenu le screencast CDP — une diffusion canvas de l'écran Chromium en direct, côté client. Ce n'était pas prévu dans l'architecture initiale. C'est maintenant une fonctionnalité centrale.
Le cas d'usage multilingue. Des agences digitales ont commencé à utiliser DataToForm pour alimenter leurs CMS multilingues. Leur fichier Excel avait des colonnes par langue : titre_fr, contenu_fr, titre_en, contenu_en, titre_es, contenu_es. Ils voulaient remplir leur CMS — WordPress, Drupal, TYPO3 — en plusieurs langues depuis un seul fichier. Ce cas est devenu son propre cas d'usage documenté.
La suite
DataToForm est en bêta ouverte. La première ligne de chaque document est traitée gratuitement — FREE_ROW_LIMIT = 1 dans server.js.
Ce qui est en cours de développement :
- Les selects en cascade robustes pour les SIRH complexes
- Les formulaires multi-étapes (gestion de l'état entre les pages du wizard)
- La mémorisation du mapping entre deux sessions sur le même formulaire
- Google Sheets comme source de données alternative à Excel
Ce qui ne changera pas :
- L'IA ne verra jamais vos valeurs réelles
- Le formulaire ne sera jamais soumis automatiquement
- Le fichier ne sera jamais stocké sur le serveur
Trois mois de travail pour en arriver là. Et l'impression que c'est aussi le début de quelque chose d'autre — une approche de l'automatisation qui fait confiance à l'humain plutôt que de chercher à le remplacer.