L’avenir de la documentation commence par de vieux formulaires
Pourquoi le papier, le hors-ligne et les processus existants restent au centre des priorités.
Dans les entreprises, l’innovation ne se déroule presque jamais sur un terrain vierge. Un bon logiciel doit pouvoir composer avec la réalité existante.
L’avenir de la documentation commence rarement par une base de données vide. Le plus souvent, il commence par un classeur.
On y trouve des formulaires utilisés depuis des années. Certains ont d’abord été conçus pour l’impression, puis envoyés en PDF, et complétés un jour par des champs de saisie numériques. Certains portent des notes manuscrites, des tampons d’entreprise ou des cases dont chaque collaborateur expérimenté connaît la signification, même si elle n’est consignée nulle part.
Lorsqu’on parle de logiciels d’entreprise dopés à l’IA, on saute volontiers par-dessus cet univers. Dans les présentations, la transformation démarre sur un terrain vierge : les données sont structurées, les processus harmonisés, les interfaces en place. La réalité est moins ordonnée — et c’est justement ce qui la rend plus intéressante.
Une nouvelle solution ne peut changer les choses que si elle peut être mise en œuvre avant même que l’existant ait été entièrement supprimé.
Le papier n’est pas le contraire de la numérisation
Les formulaires papier sont souvent perçus comme le signe d’un processus arriéré. C’est un raccourci. Nombre de ces formulaires renferment un savoir-faire condensé au fil des ans. Leurs champs, leur ordre et leurs indications reflètent des procédures de contrôle réelles. Tout n’y est pas bon. Mais tout n’y est pas superflu non plus.
La question décisive n’est donc pas : comment supprimer le papier de la manière la plus spectaculaire possible ? Elle est : comment reprendre le savoir qu’il contient sans devoir reconstruire chaque modèle à la main ?
Pour KENSA, notre équipe a développé un composant qui transforme le scan d’un formulaire papier en une version numérique de départ. Le système reconnaît la structure du formulaire, de sorte que l’on peut ensuite le modifier.
Je parle sciemment de version de départ. Cette conversion est précieuse parce qu’elle raccourcit les étapes fastidieuses. Mais elle ne remplace pas chaque décision métier. Une case peut sembler visuellement sans ambiguïté et signifier pourtant, sur le plan du processus, autre chose que ce que suppose un modèle. Parfois, un champ devra à l’avenir disparaître entièrement ; parfois, il faut une règle de validation qui n’était jamais visible sur le papier.
C’est précisément ce mélange d’automatisation et de retouche manuelle qui, dans les projets d’entreprise, s’avère souvent plus utile que la promesse d’une conversion intégrale et magique.
Pour KENSA, notre équipe a développé un composant qui transforme le scan d’un formulaire papier en une version numérique de départ. Le système reconnaît la structure du formulaire, de sorte que l’on peut ensuite le modifier.
Je parle sciemment de version de départ. Cette conversion est précieuse parce qu’elle raccourcit les étapes fastidieuses. Mais elle ne remplace pas chaque décision métier. Une case peut sembler visuellement sans ambiguïté et signifier pourtant, sur le plan du processus, autre chose que ce que suppose un modèle. Parfois, un champ devra à l’avenir disparaître entièrement ; parfois, il faut une règle de validation qui n’était jamais visible sur le papier.
C’est précisément ce mélange d’automatisation et de retouche manuelle qui, dans les projets d’entreprise, s’avère souvent plus utile que la promesse d’une conversion intégrale et magique.
Un éditeur n’est pas un détail
Après la reconnaissance automatique commence le travail sous-estimé dans bien des projets de numérisation : un formulaire doit être adapté au processus réel. Des champs sont déplacés, regroupés ou renommés. Il faut définir des dépendances, préciser les mentions obligatoires et ajouter des indications.
C’est pourquoi KENSA comprend un éditeur de formulaires complet. Il permet d’affiner les modèles convertis, mais aussi de concevoir de nouveaux formulaires de A à Z. Pour nous, il ne s’agissait pas d’un simple outil d’administration qui n’aurait qu’à paraître à peu près fonctionnel. L’éditeur devait offrir des possibilités complexes sans redevenir lui-même ce logiciel d’entreprise rigide que nous critiquons par ailleurs.
Cette partie est moins spectaculaire que la reconnaissance automatique, mais au moins aussi importante au quotidien. Un responsable métier peut adapter lui-même un modèle, sans devoir lancer un projet de développement distinct pour chaque modification.
Les bons outils ne déplacent pas la responsabilité au hasard ; ils la placent au bon endroit. L’informatique fournit les règles et les intégrations. Les services métiers peuvent façonner là où leur connaissance des processus est décisive.
Un formulaire n’est pas encore un ordre de mission
Même le meilleur formulaire numérique reste inutile si personne ne sait qui doit le traiter, ni quand. La documentation fait presque toujours partie d’un déroulement plus large : un contrôle est planifié, attribué à une personne, préparé avec des données connues, complété sur place, puis renvoyé.
C’est pourquoi des formulaires et des tâches concrètes peuvent être distribués aux collaborateurs via un serveur. Les informations existantes peuvent être renseignées à l’avance. Le contrôleur ne part pas de zéro : il reçoit le contexte que l’entreprise connaît déjà — objet, site, ordre de mission, rendez-vous ou données de base déjà consignées.
Sur le papier, cela va de soi. Dans beaucoup de projets, pourtant, les processus se disloquent précisément à ces transitions. Un formulaire est rempli par voie électronique, puis envoyé par e-mail. Les données existent et sont malgré tout ressaisies sur place. L’interface est plus moderne ; le déroulement qui la sous-tend ne l’est guère.
Ce n’est que lorsque la mise à disposition, le traitement et le retour sont pensés ensemble qu’un flux de travail numérique voit le jour, au lieu d’un simple document numérique.
Le cloud n’est pas le lieu de travail du contrôleur
La différence entre la démo et le quotidien apparaît de façon particulièrement nette avec la connexion internet. Les contrôleurs travaillent dans des halls d’usine, des locaux techniques, des caves, sur des chantiers ou dans des installations isolées. Là, une connexion stable n’est pas une base fiable pour le processus de travail.
Une application mobile incapable de fonctionner sans réseau n’est pas vraiment mobile.
Chez KENSA, les fonctions dont les contrôleurs et les utilisateurs ont besoin pour leur travail proprement dit sont donc, par principe, utilisables hors ligne. Les tâches et les formulaires sont mis à disposition lorsqu’une connexion existe. Sur place, ils peuvent être traités même sans réseau. La synchronisation s’effectue dès qu’une connexion est de nouveau disponible.
Cette architecture est moins glamour qu’une démo d’IA entièrement centrée sur le cloud. Elle exige un stockage local des données, des règles de synchronisation claires et une gestion soigneuse des conflits. Que se passe-t-il lorsqu’un formulaire a été modifié sur le serveur pendant qu’une version plus ancienne est éditée hors ligne ? Quelles données doivent être chiffrées sur l’appareil ? Comment l’utilisateur sait-il si son ordre de mission a déjà été entièrement transmis ?
Ce ne sont pas des questions marginales. Elles déterminent si une application gagne la confiance dans des conditions réelles.
La recherche sur les interfaces vocales dans la logistique de production cite elle aussi le contexte d’utilisation comme facteur essentiel. Le bruit, la mobilité, les scénarios mains libres, l’acceptation et l’infrastructure technique déterminent ensemble si une solution vocale aide réellement au quotidien. Un bon taux de reconnaissance en laboratoire ne suffit pas si l’application n’est pas disponible sur le lieu d’utilisation.
Le mode hors-ligne pose des limites, et c’est une bonne chose
Toutes les fonctions ne peuvent pas raisonnablement s’exécuter entièrement sur l’appareil. La distribution basée sur serveur, l’administration centrale ou les services gourmands en calcul nécessitent au moins ponctuellement une connexion. L’amélioration automatique du texte par de grands modèles de langage dépend elle aussi de l’architecture choisie et des modèles locaux disponibles.
Une séparation honnête est donc importante : que doit pouvoir faire l’utilisateur sur place à tout moment ? Quelles fonctions peuvent être synchronisées plus tard ? Où une connexion est-elle inévitable ?
Pour le travail d’un contrôleur, la réponse est relativement claire. Il doit pouvoir ouvrir son ordre de mission, voir les indications existantes, consigner ses observations, ajouter des photos ou d’autres informations, et enregistrer l’opération de manière fiable. Aucune zone blanche ne doit le contraindre à interrompre son travail ou à prendre en plus des notes sur papier.
Le fonctionnement hors ligne n’est donc pas une simple case à cocher dans une liste de fonctionnalités. C’est une décision sur la réalité de travail que l’architecture prend au sérieux.
Le design fait partie de la fiabilité
Lorsqu’une application réunit de nombreuses possibilités techniques, une interface surchargée apparaît vite. Champs de formulaire, saisie vocale, intentions reconnues, photos, statut des tâches et synchronisation se disputent l’attention.
Notre équipe a donc consacré beaucoup de travail au design de l’application KENSA. L’interface ne doit pas montrer à quel point le système est complexe en coulisses. Elle doit rendre clair, à chaque instant, la prochaine étape pertinente pour l’utilisateur.
Il ne s’agit pas seulement d’esthétique. Un retour visuel clair évite les erreurs: l’utilisateur doit pouvoir savoir si un enregistrement est en cours, quelles indications ont été reprises, si un ordre de mission n’a jusqu’ici été enregistré que localement, et quels points manquent encore. Avec la structuration automatique en particulier, le système ne doit pas simuler discrètement, en arrière-plan, un rapport parfait.
La recherche sur les systèmes de rapport professionnels à commande vocale décrit un grand nombre de telles décisions de conception : comment un enregistrement commence-t-il et se termine-t-il ? Comment effectue-t-on des corrections ? Quand une question de vérification est-elle utile, quand devient-elle gênante ? Comment relier la voix aux informations visuelles ? La qualité d’une solution ne naît donc pas de la seule composante d’IA, mais tout autant de ces détails d’interaction en apparence minimes.
L’innovation passe aussi par la création de passerelles
Conversion de scans, éditeur de formulaires, distribution centralisée des tâches, fonctionnement hors ligne et application soigneusement conçue semblent d’abord des fonctions très différentes. Elles répondent pourtant à la même question : comment une entreprise passe-t-elle de son univers documentaire actuel à un meilleur, sans ignorer l’exploitation en cours ?
LE SCAN
Le scan reprend les modèles existants.
L’ÉDITEUR
L’éditeur les rend modifiables.
LE COMPOSANT SERVEUR
Le composant serveur relie les formulaires à des ordres de mission concrets.
LE FONCTIONNEMENT HORS LIGNE
Le fonctionnement hors ligne amène le processus sur le lieu de travail réel.
L’INTERFACE
L’interface veille à ce que cette complexité ne retombe pas sur le contrôleur.
LE SCAN
Le scan reprend les modèles existants.
L’ÉDITEUR
L’éditeur les rend modifiables.
LE COMPOSANT SERVEUR
Le composant serveur relie les formulaires à des ordres de mission concrets.
LE FONCTIONNEMENT HORS LIGNE
Le fonctionnement hors ligne amène le processus sur le lieu de travail réel.
L’INTERFACE
L’interface veille à ce que cette complexité ne retombe pas sur le contrôleur.
Ce n’est que sur cette base que l’interface vocale peut déployer son potentiel. Il ne sert à pas grand-chose de comprendre parfaitement le langage naturel si le formulaire adéquat n’est pas disponible, si des données connues manquent ou si le résultat doit ensuite être transféré manuellement dans un autre processus.
Une leçon sobre tirée du développement de logiciels d’entreprise est donc la suivante : la fonction la plus spectaculaire prise isolément suffit rarement. Au quotidien, ce qui compte, c’est que les transitions fonctionnent.
L’avenir doit être compatible avec le présent
La vision d’un formulaire largement invisible reste séduisante. L’utilisateur décrit une situation, le système structure les indications et n’affiche plus que ce qui doit être complété ou confirmé.
Mais le chemin pour y parvenir ne contourne pas les formulaires existants. Il passe à travers eux. Les entreprises ont besoin de moyens pour reprendre le papier et les PDF, faire évoluer elles-mêmes leurs processus, distribuer les tâches de façon fiable et travailler même là où aucun cloud n’est accessible.
C’est moins radical que de déclarer obsolètes tous les systèmes hérités. Dans la pratique, c’est sans doute plus radical : car cela change réellement le quotidien de travail, au lieu de se contenter de décrire une architecture d’avenir.
Une bonne innovation n’exige p
Conseil practique de KENBUN
Automatisez les processus – pas la responsabilité.
D’après notre expérience dans les projets d’IA et d’automatisation, une règle d’or simple a fait ses preuves : tout ce qui suit des règles claires, traite des données ou prépare des ébauches peut souvent être géré par l’IA plus rapidement et de manière plus fiable que par nous, les humains.
Cependant, lorsque les décisions ont des conséquences majeures ou qu’un jugement éclairé, de l’expérience et des responsabilités sont requis, l’humain doit toujours avoir le dernier mot.
C’est précisément à cette intersection entre efficacité et discernement que naissent les solutions de numérisation durables.
Vous souhaitez découvrir où se situe cette frontière dans vos propres processus ? Nous serions ravis d’en discuter avec vous.
