01

Écouter le dirigeant.

Comprendre son parcours, l’histoire de l’entreprise et la manière dont elle s’est construite. Revenir sur les projets et déploiements passés : ce qui a fonctionné, ce qui a échoué et pourquoi.

Surtout, comprendre où il veut emmener l’entreprise demain, ses ambitions, ses contraintes et sa vision.

Le dirigeant, le manager et celui qui l’exécute tous les jours en ont chacun une vision différente. Pour comprendre comment l’entreprise fonctionne réellement, il faut aller voir.

02

Aller sur le terrain.

Observer les gestes, les échanges, les outils, les doubles saisies et les contournements. Je cherche à comprendre pourquoi les utilisateurs travaillent ainsi. J’écoute leur avis, ce qui les embête, ce qu’ils aiment faire, où ils vont : ce sont eux qui savent ce qu’il faut faire et comment le faire ! C’est la première étape pour en faire les ambassadeurs de demain.

Analyser les méthodes de travail, les manques des outils, la surcomplexité, les besoins que le processus ou l’outil officiel ne couvre pas.

Avant d’améliorer leur outil, j’ai besoin de comprendre pourquoi il leur est nécessaire : ce qu’il résout, ce qu’il contourne, ce que le processus officiel n’avait pas prévu.

03

Remettre à plat.

On cartographie les processus réels, pas ceux de l’organigramme. Puis on détermine une process map cible : ce que l’on veut.

Puis on trace la roadmap produit : où on va, dans quel ordre, et combien ça va coûter.

On sait maintenant d’où on vient et où on va. On a un plan, on a des coûts : on peut se concentrer sur le ROI. Parfois, la solution n’est même pas un logiciel.

04

Prototyper vite.

J’apporte ensuite un regard neuf et la capacité à transformer rapidement une idée en outil. Mieux vaut se tromper tôt.

Une première version entre les mains des utilisateurs nous apprend bien plus que des dizaines de pages de spécifications.

05

Livrer en sprints.

Avancer à petits pas : prioriser ce qui crée le plus de valeur, construire petit, livrer tôt, apprendre, itérer. Chaque cycle transforme une hypothèse en quelque chose de concret, confronté à la réalité du terrain.

La technologie vient après le problème. Une API existe ? Je l’utilise. Sinon : base de données, export, connecteur, OCR, RPA, hacking si nécessaire. Si une donnée s’affiche à l’écran, on peut la récupérer.

Je reste impliqué de bout en bout, de la direction au déploiement. Je réutilise ce qui marche, j’évite les dépendances inutiles : la complexité a un coût, la valeur doit le justifier.

06

Faire adopter.

Un nouvel outil ne crée de valeur que s’il est réellement utilisé.

Accompagner les équipes, écouter les résistances, former, ajuster et mesurer les résultats, jusqu’à ce que la nouvelle façon de travailler devienne naturelle.

07

Rester.

La mise en production n’est pas la fin du projet. Rester disponible, observer les usages, corriger, améliorer et faire évoluer l’outil avec l’entreprise.

Je ne livre pas un logiciel pour disparaître ensuite.

03 · Arme secrète / exemple 1

« Je n'ai pas reçu mes billets. »

L’IA croise la commande, le paiement, les logs du prestataire et la fiche produit.

Caché quelque part dans les mentions de la fiche produit, la livraison très particulière de ce produit est indiquée sous 48 h… Pas d’incident : il suffit d’attendre.

03 · Arme secrète / exemple 2

« Ma landing page électricité a disparu. »

L’IA ne s’arrête pas au mot. Elle cherche du côté des fournisseurs d’énergie et retrouve la bonne page.

Elle comprend qu’EDF est une marque d’électricité : la recherche est ciblée, efficace, et le webmaster est renvoyé directement au bon endroit dans l’outil.

03 · Arme secrète / exemple 3

« Renvoie l’attestation de Paul Ochon. »

L’IA analyse le client et demande d’abord de confirmer de qui il s’agit.

Puis elle prépare l’envoi, sur une adresse masquée. Rien ne part sans la validation de l’humain.

L’adresse n’est pas au choix de l’utilisateur : c’est celle du compte client. Et l’IA n’a accès ni aux données confidentielles, ni au contenu de l’attestation.