6 min readSacha Delcourt

MVP d'un projet d'automatisation : que livrer en premier ?

Livrer par lots un projet d'automatisation métier : que mettre dans le premier lot, comment exploiter les retours terrain et quand passer au lot suivant.

MVP d'un projet d'automatisation : que livrer en premier ?

En bref. Le MVP d'un projet d'automatisation métier est la plus petite version qui remplace une partie réelle du processus et que l'équipe utilise en production. Il couvre un flux complet sur un périmètre restreint, repose sur des données propres et laisse l'existant en place. Ce sont les retours d'usage, pas le cahier des charges initial, qui fixent le lot suivant.

Pourquoi livrer par lots plutôt que tout d'un coup ?

Parce que le cahier des charges complet d'un processus métier est presque toujours faux quelque part. Pas par négligence : une partie des règles n'existe que dans la pratique des équipes, et elle ne se révèle qu'au moment où quelqu'un utilise l'outil sur un vrai dossier.

Un projet livré en une fois découvre ces règles à la fin, quand tout est déjà construit dessus. Un projet livré par lots les découvre au premier lot, quand corriger coûte encore peu. C'est la raison principale, et elle suffit.

Il y en a une autre, plus humaine. Une équipe à qui l'on retire tous ses outils le même lundi résiste, et elle a souvent raison. Une équipe qui reçoit un premier morceau utile, qu'elle peut critiquer, devient partie prenante du suivant.

Qu'est-ce qu'un bon premier lot ?

Le mot MVP est abîmé. Dans beaucoup de projets, il désigne une maquette ou une version bâclée. Dans un projet d'automatisation métier, nous lui donnons un sens plus exigeant : une version utilisée en production, sur un vrai flux de travail. Si personne ne s'en sert au quotidien, c'est une démo.

Pour choisir ce qu'on met dedans, on se pose quatre questions :

  1. Quelle étape absorbe le plus de temps, ou concentre le plus de risque ? C'est elle qu'on vise.
  2. De quelles données a-t-elle besoin ? Si ces données sont dispersées ou fausses, les remettre d'aplomb fait partie du lot, sinon le reste ne tiendra pas.
  3. Quelles règles métier faut-il écrire pour l'automatiser ? Elles doivent être validées par écrit avant le développement.
  4. Qu'est-ce qu'on laisse volontairement dehors ? Cette liste compte autant que l'autre.

La quatrième question est celle qu'on saute le plus souvent. C'est pourtant elle qui protège le calendrier. Tout ce qui est utile mais pas indispensable pour que l'équipe travaille avec l'outil va dans un lot ultérieur : noté, daté, mais pas développé.

À quoi ressemblait le premier lot chez un distributeur de câbles ?

Notre client distribue des câbles entre l'Europe et l'Asie. Plus de 3 000 références, trois devises (euro, dollar, yuan), une part significative des produits indexée sur le cuivre, plusieurs modes de transport et plusieurs Incoterms. Tout son pricing tenait dans des fichiers Excel mis à jour à la main, et une seule personne en connaissait les règles.

Le moteur de calcul du prix, de l'achat à la vente, était le centre du MVP. C'était l'étape qui absorbait le plus de temps et qui portait le risque de dépendance. Mais un moteur de pricing a besoin d'un catalogue fiable, et les produits vivaient à plusieurs endroits : dans l'ERP et dans des fichiers Excel plus ou moins à jour. Le moteur repose donc sur une base produit unique, synchronisée chaque jour avec l'ERP pour les stocks et les prix d'achat. Sans elle, il aurait calculé des prix faux, plus vite.

Deux décisions de périmètre ont pesé. L'ERP est resté en place : la plateforme s'y connecte au lieu de le remplacer, et nous expliquons pourquoi dans automatiser sans remplacer son ERP. Et l'import-export Excel a été conservé, parce que les équipes et leurs clients y travaillent encore. Le supprimer aurait donné un premier lot plus « propre » et beaucoup moins utilisé.

Aujourd'hui, la plateforme couvre le processus de bout en bout, jusqu'à la génération des offres. Le projet complet est décrit dans notre article sur le cas client, et la démonstration en vidéo montre l'outil tel qu'il tourne en production.

Comment recueillir des retours terrain qui servent ?

Demander « qu'en pensez-vous ? » ne produit rien d'exploitable. Les retours utiles viennent de l'usage, pas de l'avis. Quelques pratiques qui marchent :

  • Faire utiliser le lot sur des dossiers réels, pas sur des exemples préparés. Les exceptions apparaissent avec les vrais cas.
  • Noter chaque contournement. Quand quelqu'un rouvre son fichier Excel pour finir une tâche, c'est un retour, même s'il ne le formule pas.
  • Séparer les bugs, les règles métier oubliées et les envies. Ils n'ont pas la même urgence.
  • Laisser les utilisateurs décrire le problème plutôt que la solution. « Ajoutez un bouton » cache souvent un besoin qui se traite autrement.

Chez notre client, plusieurs fonctions sont nées de besoins précis de l'équipe. Le choix d'appliquer la marge d'achat avant ou après le transport en est un : un besoin propre à ce client, que nous avons ajouté. La comparaison de simulations ligne par ligne en est un autre, et elle compte parmi les fonctions auxquelles l'équipe tient le plus. Ce sont typiquement les détails qui décident si une équipe adopte l'outil ou retourne à son fichier.

Quand passer au lot suivant ?

Quand le lot en cours est utilisé sans contournement sur le périmètre prévu. Pas quand il est parfait, ni quand la liste des envies est vide : elle ne le sera jamais.

Le cycle que nous suivons ne change pas : audit, cadrage écrit, MVP, livraison, retours du client, itérations, tests communs, puis lot suivant. Le cadrage du lot suivant part de ce que le premier a appris, pas des hypothèses du départ. C'est la méthode que nous appliquons avec les 37 entreprises pour lesquelles nous avons travaillé jusqu'ici, et nous n'avons pas trouvé mieux pour faire avancer un projet sur la durée.

Les erreurs qu'on voit le plus souvent

  • Un premier lot trop large, qui devient un projet complet déguisé. Si sa liste de fonctions tient sur plusieurs pages, il est trop gros.
  • Un premier lot trop mince, qui ne remplace rien. L'équipe continue sur l'ancien outil et le nouveau reste vide.
  • Des données laissées pour plus tard. Automatiser sur un catalogue incohérent donne des résultats incohérents.
  • Des règles métier jamais écrites, découvertes pendant la recette. C'est le rôle de l'audit, que nous détaillons dans pourquoi commencer un projet IA par un audit.
  • Un outil que seul le prestataire peut faire évoluer. Chez notre client, les champs produit s'ajoutent sans code, pour que chaque petite évolution ne devienne pas un nouveau lot.

Si vous préparez un projet de ce type, écrivez d'abord la liste de ce qui ne sera pas dans le premier lot. Si elle est vide, le périmètre n'est pas encore choisi. Nous pouvons faire cet exercice avec vous pendant le diagnostic gratuit, et la page automatisation de processus montre le type de chantiers que nous menons.

Frequently asked questions

Qu'est-ce qu'un MVP dans un projet d'automatisation métier ?
C'est la plus petite version de l'outil qui remplace une partie réelle du processus et que l'équipe utilise en production. Une maquette ou une démo que personne n'utilise au quotidien n'en est pas un.
Que mettre dans le premier lot d'un projet d'automatisation ?
L'étape qui absorbe le plus de temps ou concentre le plus de risque, avec les données dont elle a besoin et les règles métier écrites pour l'automatiser. Tout ce qui n'est pas indispensable pour que l'équipe travaille avec l'outil part dans un lot ultérieur.
Combien de lots faut-il prévoir pour un projet d'automatisation ?
Il n'y a pas de nombre fixe. Chaque lot est cadré à partir de ce que le précédent a appris en production, et on passe au suivant quand le lot en cours est utilisé sans contournement sur son périmètre.
Comment recueillir les retours des utilisateurs sur un MVP ?
En observant l'usage sur des dossiers réels plutôt qu'en demandant un avis général. Chaque retour à l'ancien fichier Excel est un signal, et il faut trier les retours entre bugs, règles métier oubliées et envies, qui n'ont pas la même urgence.

Our latest articles

Let's talk about what you want to build

A 30-minute call to scope your need and see if we're the right team to build it. No strings attached.