Ce que l'IA déplace dans le travail des managers
Reporting, préparation de réunions, suivi d'activité : ce que l'IA déplace dans le travail d'un manager, et ce qu'elle rend plus difficile.
Écrit par les consultants de Lick & Shannon Partners. Les managers de proximité sont le point où les projets d'automatisation basculent : ils ne décident pas du déploiement, mais ils décident de son adoption réelle.
Ce que l'IA prend en charge
Une part du travail d'encadrement consiste à produire de l'information sur le travail plutôt qu'à l'organiser. C'est cette part-là qui se réduit.
- Le reporting. Compiler, mettre en forme, commenter des chiffres qui existent déjà ailleurs. Le gain est immédiat et personne ne le regrette.
- La préparation de réunions. Reprendre les points en suspens, construire un ordre du jour, retrouver ce qui a été dit la fois précédente.
- La rédaction courante — comptes rendus, notes de cadrage, messages d'information à l'équipe.
- La recherche interne — retrouver une procédure, une décision ancienne, un engagement pris il y a six mois.
Ordre de grandeur observé : quelques heures par semaine sur un poste d'encadrement intermédiaire. Ce qui n'est pas rien — à condition que ce temps soit réaffecté à quelque chose de décidé.
Ce qu'elle rend plus difficile
C'est le point qu'on ne lit nulle part, et que nous constatons systématiquement.
Un manager qui ne rédige plus perd un moment de réflexion. Écrire un compte rendu obligeait à trancher ce qui comptait. Un compte rendu généré et validé en trente secondes fait disparaître ce temps de mise en ordre — et avec lui, une partie de la préparation des décisions.
La détection des signaux faibles s'émousse. Une équipe qui décroche se voit dans des choses ténues : un ton, une absence de question, un délai qui glisse sans explication. Un encadrement qui traite ses échanges par synthèses successives voit les faits et rate le reste.
La conclusion n'est pas d'interdire, mais de choisir : ce qui est répétitif se délègue, ce qui suppose un jugement se garde. Cette frontière se pose explicitement, sinon elle se déplace toute seule.
Le manager comme premier point de blocage — ou de bascule
Dans presque tous les projets que nous accompagnons, l'adoption se joue à ce niveau, et pas au niveau de la direction ni des utilisateurs finaux.
Un manager convaincu explique, corrige les usages maladroits, remonte ce qui ne marche pas et protège le temps nécessaire à l'apprentissage. Un manager qui subit le projet le laisse mourir sans jamais s'y opposer ouvertement — et c'est indétectable dans un tableau de suivi.
Deux causes reviennent quand ils bloquent : ils n'ont pas compris ce que ça change pour eux, ou ils ont compris que ça les expose — parce qu'un processus automatisé rend visible une organisation qui reposait sur des arrangements informels.
Ce qu'il faut leur donner pour que ça marche
- Une réponse claire sur leur propre poste. La première question d'un manager n'est pas « qu'est-ce que ça apporte à l'entreprise » mais « qu'est-ce que ça change pour moi ». Y répondre avant qu'elle soit posée évite des mois de résistance passive.
- Du temps, réellement dégagé. Accompagner un changement demande des heures que personne ne leur retire par ailleurs.
- Le droit de dire que ça ne marche pas. Sans ce droit, les remontées disparaissent et le projet avance à l'aveugle.
- Une règle d'usage écrite. Un manager ne peut pas arbitrer au cas par cas ce que son équipe a le droit d'envoyer dans un outil.
Ces constats valent en général. Ils ne disent pas où sont vos points de blocage : ils dépendent de votre ligne managériale, de l'histoire des projets précédents et de ce que les équipes en ont retenu. Ça se regarde sur un périmètre précis.
Cadrer un cas d’usage sur votre périmètre
On prend une fonction, on regarde ce qui est automatisable, et on chiffre le gain avant d'outiller.
Pour aller plus loin