Regarder les tâches réelles avant de choisir un outil IA

Une réunion de cadrage commence presque toujours de la même manière. Quelqu’un pose un nom d’outil sur la table, et attend qu’on dise oui ou non. Nous répondons rarement tout de suite. À la place, nous demandons qui fait quoi le lundi matin, combien de temps cela prend, et ce qui se passe quand la personne est absente. Le silence qui suit est souvent plus instructif que la question de départ.

Ce réflexe nous a coûté quelques rendez-vous. Il nous en a fait gagner d’autres. Nous l’assumons parce qu’il repose sur une observation simple : un outil ne fait jamais gagner du temps tout seul. Il en fait gagner sur une tâche précise, exécutée par une personne précise, dans un contexte précis. Sans ces trois éléments, il n’y a rien à évaluer.

Le travail réel n’est pas celui qui est décrit

Quand une entreprise décrit son fonctionnement, elle décrit le processus officiel. Celui qui figure dans les procédures, dans l’organigramme, dans la présentation commerciale. Le travail réel contient autre chose : des tableurs personnels qui ne sont dans aucun système, des messages échangés en dehors des outils prévus, des vérifications faites de tête par la personne qui est là depuis douze ans.

Ces écarts ne sont pas des dysfonctionnements. Ce sont des adaptations. Elles existent parce que le processus officiel ne couvrait pas un cas particulier, et que quelqu’un a bricolé une solution qui marche. Une automatisation posée sur le processus officiel passe à côté de ces cas, et casse au premier écart.

C’est la raison pour laquelle notre offre Diagnostiquer commence par un état des lieux avant de recommander quoi que ce soit. Nous nous donnons jusqu’à cinq activités et cinq processus prioritaires, pas davantage. La limite est volontaire. Une cartographie exhaustive de toute l’entreprise produit un document que personne ne lit. Cinq processus regardés sérieusement produisent un plan que l’on peut suivre.

Nous cherchons les tâches, pas les métiers

Une erreur fréquente consiste à raisonner par métier. « L’IA pour les commerciaux », « l’IA pour la comptabilité ». Ces catégories sont trop larges pour décider quoi que ce soit. Un commercial passe sa journée sur une dizaine de tâches différentes, dont certaines se prêtent bien à un assistant et d’autres pas du tout.

Nous découpons donc plus finement. Une tâche utile à examiner a quelques caractéristiques reconnaissables. Elle revient souvent. Elle produit un livrable identifiable, un document, un message, une liste. Elle demande une transformation de matière écrite plutôt qu’une décision engageante. Et la personne qui la fait sait dire à quoi ressemble un bon résultat.

Ce dernier point est le plus discriminant. Si personne ne sait décrire un bon résultat, personne ne saura relire ce que produit l’outil. La tâche n’est pas prête, et l’IA ne la rendra pas prête. Elle produira simplement plus vite des résultats que personne ne peut valider.

Trois raisons de dire non à un projet

Nous refusons certains projets. C’est une position tenable seulement si on sait expliquer pourquoi, alors voici nos trois motifs les plus fréquents.

Le premier est l’absence de sujet. Une entreprise veut « faire de l’IA » parce que son secteur en parle, mais ne peut nommer aucune tâche qui pose problème. Nous ne construisons pas un besoin qui n’existe pas. Dans ce cas, un diagnostic reste possible, et il conclura parfois qu’il n’y a rien d’urgent à installer. C’est un résultat honnête, et nous le remettons tel quel.

Le deuxième est un désordre en amont. Quand les données sont dispersées, contradictoires ou introuvables, un assistant ne sert à rien. Il produira des réponses confiantes à partir de documents faux. Le chantier utile est alors le rangement, et il est rarement de notre ressort. Nous le disons plutôt que de vendre une couche d’IA par-dessus.

Le troisième est un projet qui repose sur le remplacement d’une personne sans que cela soit dit. Nous le repérons assez vite, aux questions posées et à celles qu’on évite. Nous ne travaillons pas dans ces conditions, parce qu’une installation d’IA réussie suppose que les personnes concernées collaborent, et qu’elles ne collaborent jamais à leur propre remplacement.

Ce que quatre à six semaines changent

Quand un sujet est identifié, nous installons deux à trois usages, pas plus, sur quatre à six semaines. C’est le cadre de notre offre Pratiquer. Le nombre et la durée ne sont pas des arguments commerciaux, ce sont des contraintes apprises.

Deux ou trois usages tiennent dans la tête d’une équipe. Au-delà, l’attention se disperse et rien n’est vraiment adopté. Quatre à six semaines laissent le temps de rencontrer les cas particuliers, ceux qui n’apparaissent pas la première semaine. Une installation faite en trois jours a l’air parfaite le troisième jour, et s’effondre au premier dossier qui sort du cadre.

La formation est comprise dans ce temps, et pas ajoutée à la fin. Une personne qui a vu construire son outil sait pourquoi il fonctionne ainsi, et sait le corriger quand le contexte bouge. Une personne qui reçoit un outil terminé ne sait faire qu’une chose quand il dérape : arrêter de s’en servir.

Une question qui règle beaucoup de débats

Nous utilisons une question de tri, très simple, que vous pouvez poser vous-même dans votre équipe. Elle sert à savoir si une tâche mérite qu’on s’y attarde.

Les réponses sont rarement celles qu’attend la direction. Les tâches les plus coûteuses sont souvent invisibles depuis le haut, parce qu’elles sont fragmentées, qu’elles ne figurent dans aucun outil de suivi et que personne ne s’en plaint. Ce sont pourtant celles où un assistant bien réglé fait une différence mesurable dès la deuxième semaine.

Quand la dernière partie reste sans réponse, c’est également une information. Elle signale une tâche dont le critère de qualité n’a jamais été formulé. Là, le travail à faire n’est pas technique. Il consiste à écrire ce qu’on attend, ce qui améliore la tâche même sans aucune IA.

Choisir l’outil en dernier, et l’assumer

Une fois les tâches identifiées et les critères de qualité écrits, le choix de l’outil devient presque ennuyeux. Il se réduit à quelques questions pratiques : où sont les données, qui doit y accéder, quel budget mensuel est tenable, et qui reprendra la main dans six mois. Les grands assistants généralistes se ressemblent beaucoup plus qu’on ne le dit. L’écart de résultat vient de la manière dont on les branche sur le travail réel, pas de la marque.

Nous gardons le développement sur mesure pour les cas où rien d’existant ne convient, et ces cas sont moins nombreux qu’on ne l’imagine au départ. Construire un logiciel spécifique est une décision lourde, qui crée une dette de maintenance pour des années. Elle se justifie quand le besoin est vraiment particulier, pas quand personne n’a pris le temps de configurer correctement un outil du marché.

Cette manière de travailler nous vaut parfois d’être plus lents que ce que le client espérait à la première réunion. Nous préférons ce reproche à l’autre, celui qui arrive six mois plus tard, quand un outil payé chaque mois n’est plus ouvert par personne.

Si vous voulez tester l’approche sans nous, faites l’exercice cette semaine. Choisissez trois personnes de services différents, posez-leur la question ci-dessus, et notez les réponses sans les commenter. Vous saurez très vite si votre sujet d’IA est celui que vous croyez, ou un autre. Notre offre Diagnostiquer fait exactement cela, en plus méthodique et avec un plan chiffré à la fin, mais le premier pas ne demande qu’une feuille et trois conversations.