Notre approche

Comprendre ne consiste pas à produire un audit de plus. Nous cherchons les écarts entre le fonctionnement prévu et le travail réel : les doubles saisies, les informations qui restent dans une boîte mail, les étapes que chacun contourne — et, tout aussi important, ce qui fonctionne déjà et ne doit pas être cassé.

Concrètement, nous regardons où l'information entre, qui s'en sert ensuite, à quel moment elle se perd, et ce qui oblige aujourd'hui à sortir de l'outil. Nous parlons aux personnes qui font le travail, pas seulement à celles qui le décrivent.

Ce que vous recevez tient en quelques pages : ce que nous avons observé, ce que nous en déduisons, et ce que nous n'avons pas pu vérifier. Les trois sont séparés.

Choisir, c'est surtout écrire ce que nous ne ferons pas. Une liste de tout ce qui serait souhaitable n'aide personne à décider.

Nous rangeons ce qui a été vu en trois : ce qui gêne tous les jours et se traite maintenant, ce qui peut attendre sans coût, et ce qui n'entre pas dans ce projet. La troisième colonne est celle qui protège le budget.

Vous arbitrez. Nous donnons notre avis et ce sur quoi il repose, mais le périmètre est le vôtre.

Nous évitons la bascule unique où tout change le même jour. Elle concentre le risque au pire moment et rend impossible de savoir ce qui a cassé.

Nous découpons en lots qui ont un sens pour vous : un lot doit pouvoir être utilisé, jugé et gardé même si la suite s'arrête. Le premier lot sert souvent avant la fin du projet.

Quand une reprise de données est nécessaire, elle se fait sur une copie d'abord, et elle se relit avant d'être conservée.

Vérifier, c'est vous donner de quoi juger — pas vous demander de nous croire.

Nous rejouons vos situations réelles : une commande qui ressemble aux vôtres, un dossier compliqué, le cas limite que tout le monde redoute. Vous voyez le résultat, pas une démonstration préparée.

S'il reste des écarts, ils sont écrits avant la validation, avec ce qu'ils impliquent. Une réserve connue vaut mieux qu'une bonne surprise qui n'arrive pas.

Le test est simple : si nous disparaissions le lendemain, est-ce que cela continue de tourner ?

Nous formons les personnes qui utiliseront l'outil, pas seulement celle qui a suivi le projet. Nous laissons une documentation courte, écrite pour être lue, et nous remettons les accès — y compris ceux d'administration.

Ce qui a été construit reste lisible : nous n'employons pas de mécanisme que vous ne pourriez pas reprendre ou faire reprendre.

La continuité n'est utile que si elle a un périmètre. Sinon c'est un abonnement qui absorbe tout sans résultat identifiable.

Elle a du sens quand l'outil est vraiment entré dans le quotidien, que des questions d'usage apparaissent, et que de petits ajustements valent mieux qu'un nouveau projet.

Elle n'en a pas si rien n'a encore été mis en service, ou si le besoin réel est une évolution : dans ce cas nous le disons et nous la cadrons séparément.