B2B / distribution
Un processus contractuel récurrent, impliquant plusieurs marques, types de contrats et langues, a été transformé en outil interne. Pas en numérisant simplement le document existant, mais en rendant d'abord explicites les règles, les exceptions, la numérotation et les données historiques — puis en testant surtout ce qui ne pouvait absolument pas mal tourner.
La situation
Le processus fonctionnait. Les contrats étaient rédigés à partir de modèles existants, les données étaient complétées, la bonne version était choisie et les documents trouvaient leur place dans les archives. Cela fonctionnait parce que la personne qui exécutait le processus savait aussi comment il était structuré. Sauf que toutes les règles n'étaient pas décrites quelque part.
Il y avait plusieurs marques, différents types de contrats et plusieurs langues. Les numéros de séquence devaient s'inscrire correctement dans l'historique existant, certaines combinaisons étaient explicitement interdites, et les données existantes ainsi que les numéros déjà attribués ne pouvaient pas être mis en danger. Tant que tout se fait manuellement, l'expérience absorbe cette complexité. Avec l'automatisation, cette marge de sécurité disparaît.
L’enjeu commercial
La première question semble simple : peut-on, à partir de plusieurs données d'entrée, générer automatiquement le bon contrat ? Techniquement, ce n'est pas le plus difficile. Les questions les plus difficiles venaient avant : quelles données déterminent quel document utiliser, quels champs sont obligatoires, quelles combinaisons doivent être bloquées, comment traiter plusieurs personnes au sein d'un même contrat, et comment éviter que deux actions obtiennent le même numéro de contrat ?
Une erreur dans une publication sur les réseaux sociaux, on la corrige. Un outil qui délivre des numéros de contrat en double ou endommage des enregistrements existants crée un tout autre type de problème. C'est pourquoi la fiabilité a pesé, dès le départ, plus lourd que des fonctionnalités supplémentaires.
Les choix
Le fonctionnement existant n'a pas été remplacé immédiatement. On a d'abord établi ce qui se passait correctement aujourd'hui et quel comportement devait absolument être préservé. Les données existantes sont restées le point de départ — pas quelque chose qu'on reconstruisait pendant le développement parce que c'était plus simple.
Les règles métier devaient être fixées. Le type de contrat, la marque, la langue, la numérotation et les combinaisons autorisées ne pouvaient pas dépendre d'un modèle qui faisait « probablement » la bonne interprétation. L'IA a aidé pour l'analyse, le développement et la relecture ; les règles elles-mêmes sont restées explicites et vérifiables.
Il en a découlé une règle de conception simple : ce qui n'est pas autorisé est bloqué avant qu'un document n'existe — pas signalé après coup. Et pour la numérotation, une exigence stricte s'appliquait : deux actions, même simultanées, ne peuvent jamais aboutir au même numéro de contrat.
Mon rôle
Mon rôle n'a pas commencé par le code. On a d'abord décortiqué le fonctionnement existant : types de documents, choix, exceptions, numérotation historique et façon dont les données étaient tenues à jour. Cela a produit une description explicite du processus — les règles auxquelles l'outil devait de toute façon se conformer.
Ensuite, l'outil a été construit et testé de façon itérative. L'IA a été mobilisée à différents titres : produire du code, remettre en question des hypothèses, repérer des exceptions et faire vérifier le fonctionnement par un second modèle. Le comportement important n'a pas seulement été contrôlé visuellement : des tests automatisés ont été mis en place pour les règles qui ne pouvaient pas bouger lorsque quelque chose changeait plus tard dans l'outil. Cet ensemble de tests est progressivement devenu plus qu'un contrôle a posteriori. Il est devenu la description du comportement que nous voulions préserver.
L’exécution
La première version fonctionnelle tournait en local : une interface simple, les données existantes et la génération de documents. L'utilisateur choisit ce qui est nécessaire ; l'outil contrôle la saisie, applique les règles, crée le document et enregistre ce qui s'est passé.
Sont ensuite venues les situations que l'on oublie facilement dans une démo : plusieurs personnes dans un même traitement, séries de numéros existantes, conversion de documents, une erreur dans un programme dont l'outil dépendait. À chaque fois, la question n'était pas seulement de savoir si on remettait les choses en état de marche, mais aussi si la même erreur pouvait revenir plus tard sans être remarquée. Les corrections ont donc, dans la mesure du possible, été suivies de tests et d'une relecture distincte du comportement concerné.
Lorsqu'une version en ligne a été envisagée, les choix techniques locaux n'ont pas été copiés aveuglément. Le stockage, l'accès, les fichiers et la conversion de documents ont été repensés pour l'environnement web, car ce qui fonctionne bien en local n'est pas automatiquement une bonne solution côté serveur. La règle est restée la même : d'abord fixer le comportement, ensuite seulement changer de plateforme.
Délibérément écarté
Pas de chatbot construit autour d'un processus qui avait surtout besoin de règles fixes. Pas d'IA laissée à décider quelles règles contractuelles s'appliquaient « probablement ». Pas de reconstruction des données existantes ni de réinitialisation de la numérotation parce que cela aurait rendu le développement plus simple. Pas de correction considérée comme réussie simplement parce que le document avait pu être régénéré une fois. Pas de version en ligne conçue en reprenant simplement les choix locaux. Et pas d'automatisation ajoutée uniquement parce qu'elle était techniquement possible.
L'outil devait faire gagner du temps. Mais pas au prix du contrôle sur le processus.