THINK : savoir penser devient la vraie compétence face à l'IA

━━━━━━━━━━━━━━━━━━━━
Une réflexion en trois temps : THINK, LEAD, ORGANIZE

L’IA entre dans l’entreprise par les budgets, les plateformes et les licences. Mais c’est dans les usages qu’elle commence véritablement à transformer l’organisation.

Lorsqu’un collaborateur s’approprie un agent, automatise une tâche ou change sa manière de travailler, quelque chose bouge déjà dans le système. Les rôles évoluent, les compétences se déplacent, les modes de décision sont questionnés. Et à mesure que les individus changent, c’est tout le collectif qui doit s’interroger : le management, les processus, les règles, les métiers, jusqu’à l’organisation elle-même.

Car le changement organisationnel n’est pas seulement une transformation décidée au sommet. Il est aussi la somme des changements qui se produisent dans les pratiques quotidiennes - et de la capacité de l’organisation à les accompagner, les amplifier et parfois les réinventer.

C’est cette dynamique que cette trilogie explore, en remontant progressivement de l’individu vers le système :

1. THINK - l’individu
Comment l’IA et les agents transforment nos façons de penser, d’apprendre et de travailler.

2. LEAD - le manager
Comment le rôle managérial évolue lorsque les collaborateurs, les compétences et les modes de travail changent.

3. ORGANIZE - l’organisation
Comment repenser le système lorsque les transformations individuelles et managériales deviennent suffisamment nombreuses pour remettre en question les modèles existants.

Vous lisez le volet 1/3 - THINK.

━━━━━━━━━━━━━━━━━━━━

Un agent peut désormais chercher une information, produire une première analyse et exécuter une série d'actions sans intervention humaine. Pour un dirigeant, l'enjeu n'est plus d'automatiser davantage : c'est de savoir ce que ses équipes doivent continuer à exercer elles-mêmes quand l'exécution se délègue.

Ma conviction : la compétence qui compte demain, c'est le how to think - savoir formuler le problème, poser les critères de jugement, et savoir combien de capacité agentique mobiliser pour y arriver.

Pour comprendre pourquoi cette compétence prend le pas sur toutes les autres, il faut d'abord voir ce qui a changé dans notre rapport au savoir-faire lui-même.

Du how to do au how to think

Pendant longtemps, développer une compétence signifiait apprendre à faire : analyser une donnée, construire un modèle, rédiger une spécification, écrire du code, produire une recommandation. Avec les agents, une partie de ces tâches devient délégable, et la question se déplace. Il s'agit désormais de savoir quoi demander, pourquoi le faire, comment cadrer le problème, comment évaluer le résultat et quand intervenir. Le how to do se délègue, le how to think reste à construire.

Cela paraît évident énoncé ainsi. Mais cela touche quelque chose de plus subtil dans notre rapport à la compétence, que le modèle des quatre niveaux de compétence permet de bien décrire.

Ce que nous savons sans savoir que nous le savons

Ce cadre, connu sous le nom de modèle des quatre stades de la compétence, ou conscious competence model, a été posé par Martin Broadwell en 1969 puis popularisé par Noel Burch, de Gordon Training International, dans les années 1970. Il décrit la trajectoire d'un apprentissage en quatre étapes :

• l'incompétence inconsciente : on ne sait pas que l'on ne sait pas
• l'incompétence consciente : on découvre ce qui nous manque
• la compétence consciente : on sait faire, mais il faut encore réfléchir à chaque geste
• la compétence inconsciente : avec l'expérience, l'action devient automatique

Cette dernière étape est une force considérable au quotidien. Un product owner expérimenté sait identifier la fonctionnalité qui mérite d'être priorisée sans dérouler consciemment sa méthode : il voit, il compare, il tranche. Une partie de son savoir est devenue presque invisible, y compris pour lui-même. Demandez-lui pourquoi il a retenu cette priorité plutôt qu'une autre : il sait le faire, mais il ne sait plus toujours expliquer précisément comment il le sait.

C'est ce troisième palier, la compétence consciente, qui redevient central avec les agents. Donner une bonne instruction à un agent oblige à redescendre de l'automatique vers le conscient, en précisant :

• le contexte
• les critères
• les exceptions
• les priorités
• les signaux qui doivent alerter

L'agent fait émerger une partie de notre expertise tacite, simplement parce qu'il faut la lui expliquer.

Expliquer sa pensée à la machine

Comparez deux formulations de la même demande, adressée par un product owner à son agent :

« Fais-moi une analyse des retours utilisateurs sur cette fonctionnalité. »

« Nous devons décider si nous priorisons cette fonctionnalité dans les deux prochains sprints. Je veux comprendre ce qui pourrait remettre en cause notre hypothèse d'adoption. Sépare les faits des hypothèses et signale-moi ce que nous ne savons pas encore. »

La seconde formulation porte une intention : une raison, un horizon, des critères pour juger le résultat. On découvre parfois, en essayant de la formuler, qu'un raisonnement qu'on croyait clair ne l'était pas tant que ça.

Exercer sa réflexion pour ne pas la perdre

On parle beaucoup du risque de perdre une compétence parce qu'on la délègue trop à une machine. Ce risque est réel, notamment pour les compétences d'exécution : si le développeur ne conçoit plus jamais lui-même l'architecture d'une fonctionnalité, sur quoi s'appuie-t-il pour repérer une dette technique cachée dans le code produit par un agent ? Ce risque-là se traite en formation ou par de la rotation sur des tâches d'exécution ponctuelles : on peut le prévenir sans changer d'organisation.

Le risque qui nous intéresse ici est plus discret et plus difficile à traiter : cesser d'exercer certaines capacités de réflexion parce qu'on a cessé d'en avoir besoin au quotidien. Si l'agent prépare l'analyse, qui continue à formuler le problème ? Si le PO ne challenge plus jamais une priorité proposée par son agent, qui reconnaîtra une bonne option quand il en verra une ? La compétence ne disparaît pas forcément d'un coup. Elle devient moins visible, moins exercée, moins consciente, jusqu'à ce qu'on en ait besoin et qu'elle ne réponde plus.

Déléguer le how to do ne doit pas signifier abandonner le how to think.

Une nouvelle dimension de la compétence : savoir dimensionner l'agentique

Il y a un autre changement, plus récent, qui commence à apparaître dans les entreprises qui raisonnent déjà en quotas de consommation plutôt qu'en simples licences : combien de tokens (l'unité qui mesure la consommation de calcul d'un modèle d'IA), combien de capacité agentique une tâche mérite-t-elle réellement ?

La réponse n'est pas triviale. La consommation ne dépend pas que de la tâche : elle dépend aussi de la manière dont on la pose. Un product owner peut demander à son agent une analyse en fournissant tout l'historique du produit en contexte, avec plusieurs allers-retours de reformulation ; un autre peut obtenir un résultat comparable avec une demande cadrée dès le départ.

Un développeur peut laisser un agent itérer une dizaine de fois sur un correctif ; un autre peut arriver au même résultat avec un prompt et un contexte mieux construits. Le coût dépend autant de qui pose la question que de la question elle-même.

Cela ajoute une dimension à la compétence individuelle : savoir quand mobiliser de la capacité agentique, laquelle mobiliser, et jusqu'où aller. Il s'agit de savoir pourquoi on consomme. C'est une compétence qui n'a, pour l'instant, presque aucun référentiel.

Réinvestir dans le think

La formation ne peut plus se limiter à l'usage d'un outil ou à l'écriture de prompts. Elle doit redonner l'occasion d'expliciter un raisonnement, de défendre une décision, et parfois de faire soi-même une tâche que l'IA pourrait faire à sa place, pas pour revenir en arrière, mais pour garder la capacité de juger le résultat et de savoir combien il a dû coûter, en temps humain comme en calcul, pour y arriver.

Ces questions ne sont déjà plus seulement des questions d'usage individuel. Dès qu'une équipe entière compose sa propre capacité de travail à partir d'humains, d'agents et de ressources de calcul, elles deviennent des questions de management. C'est le sujet du 2e volet de cette série, LEAD - Le manager pilote un système de travail, pas seulement des personnes.

---

À retenir

Avant de déléguer une tâche à un agent cette semaine, prenez 30 secondes pour formuler par écrit : le critère qui définira un bon résultat, et le signal qui devrait vous faire intervenir.

Deux questions à vous poser cette semaine :

• Sur quelles tâches vos meilleurs experts sauraient-ils le moins bien expliquer comment ils font, et donc le moins bien encadrer un agent qui les ferait à leur place ?
• Pour une tâche donnée, sauriez-vous dire si une consommation élevée de votre agent traduit un problème réellement complexe, ou simplement une mauvaise manière de l'avoir posé ?

Prochain volet : LEAD - le manager pilote un système de travail, pas seulement des personnes.

✨ Note de transparence de l'autrice : cet article est co-construit avec une Intelligence Artificielle générative à partir de mes inputs, mon angle, mes idées. J'ai réalisé plusieurs itérations seule ou avec l'IA Gen. Et l'article a été finalisé par mes soins pour en assurer la clarté et la pertinence. Une revue interne est faite par notre rédacteur en chef avant publication.