La pensée critique à l’ère de l’IA (Critical Thinking)

• Même dans un environnement où l’IA produit du code, des conceptions et des réponses, la pensée critique — poser les bonnes questions et remettre en cause les hypothèses — reste une compétence clé qui détermine la performance des ingénieurs et des équipes
• Tout au long du processus de résolution de problèmes, il faut utiliser systématiquement les six questions Who·What·Where·When·Why·How pour examiner de façon structurée les personnes, le problème, le contexte, le timing, les causes et le mode d’exécution
• Les réponses de l’IA doivent être traitées comme un brouillon proposé par un stagiaire, donc comme quelque chose à vérifier ; la définition réelle du problème, la collecte des preuves, la compréhension du contexte, l’analyse des causes et la communication doivent rester sous responsabilité humaine
• À cause de la pression temporelle, des biais et de réponses d’IA plausibles, on glisse facilement vers des conclusions hâtives et des rustines temporaires ; pour l’éviter, il faut répéter une réflexion fondée sur les preuves, avec les 5 Whys, l’expérimentation et la validation par les données
• La pensée critique se renforce dans une culture d’équipe faite de curiosité humble et d’attention portée aux preuves ; même si l’IA progresse fortement, « résoudre le bon problème, pour les bonnes raisons, de la bonne manière » reste un avantage proprement humain

---

Vue d’ensemble de la pensée critique à l’ère de l’IA

• À une époque où l’IA génère du code, du design et des réponses, la capacité humaine de pensée critique devient encore plus importante qu’auparavant
  • Même si l’automatisation devient très sophistiquée, le rôle consistant à poser les bonnes questions, à remettre en cause les hypothèses et à penser de manière indépendante reste du ressort des humains
  • Des sorties d’IA construites sur de mauvaises questions et des problèmes mal définis peuvent pousser un projet plus vite encore dans la mauvaise direction
• L’article propose des lignes d’action concrètes en s’appuyant sur le cadre Who·What·Where·When·Why·How pour exercer la pensée critique
  • Chaque question sert d’outil pour examiner la définition du problème, les parties prenantes, le contexte, le timing, l’analyse des causes ainsi que les modalités d’exécution et de communication
  • Dans un environnement assisté par l’IA, ne pas négliger ces six dimensions est essentiel pour réduire les échecs de projet et éviter les problèmes en aval

tl;dr : checklist de pensée critique pour les équipes IA

• Who : il faut considérer l’IA non comme une entité omnisciente, mais comme une entrée à vérifier, et toujours vérifier qui produit la réponse
  • Il faut éviter d’assimiler les réponses d’un LLM à l’opinion d’une personne, et distinguer la source de la responsabilité
• What : avant de foncer vers une solution, il faut clarifier la vraie définition du problème et les critères de succès
  • Au lieu de s’en tenir à des demandes superficielles, il faut définir précisément le problème réel à résoudre à partir de l’expérience utilisateur et des données
• Where : il faut prendre en compte le contexte et l’environnement dans lesquels la solution s’applique (sandbox, production, appareil utilisateur, etc.)
  • Il faut toujours garder à l’esprit qu’une solution efficace dans un environnement peut produire des effets secondaires dans un autre
• When : il faut distinguer les situations où une heuristique simple suffit et celles qui nécessitent une analyse approfondie
  • Il faut séparer le moment des correctifs d’urgence de celui de l’analyse des causes racines, afin de préserver un minimum de rigueur malgré les contraintes de temps
• Why / How : il faut remonter à la cause racine avec les 5 Whys et communiquer à partir des données et des preuves, pas des opinions
  • Il faut privilégier les éléments probants aux affirmations, et les résultats d’expérimentation et de mesure à l’intuition

Who : acteurs impliqués, responsabilité et périmètre d’impact

• Le point de départ de la pensée critique, c’est la composition des personnes et des points de vue impliqués dans la définition et la résolution du problème (qui est inclus, qui manque)
  • Il faut identifier les parties prenantes — ingénieurs, PM, utilisateurs, experts métier, etc. — et les intégrer de façon appropriée au processus de décision
  • Comme un problème affecte le plus souvent plusieurs équipes et plusieurs utilisateurs, il faut commencer par se demander « avec qui faut-il en parler ? qui faut-il informer ? »
• Pour réduire le risque de groupthink (pensée de groupe), où toutes les opinions convergent dans une seule direction, il faut délibérément faire entrer des points de vue variés
  • Si l’on écarte les avis divergents ou les perspectives différentes, on augmente le risque qu’une réponse s’impose comme évidente sans vérification de la validité des données et des hypothèses
  • Faire intervenir un regard extérieur ou une personne hors de l’équipe pour apporter un « œil neuf » est aussi un moyen de gagner en objectivité
• Depuis l’arrivée de l’IA, il est indispensable de distinguer « de qui vient cette réponse, d’un humain ou d’une IA ? »
  • Un LLM n’est qu’un moteur statistique ; il faut donc examiner non pas « qui l’a dit », mais « sur quelles bases cela a été dit »
  • Il faut traiter le code généré par l’IA comme celui d’un stagiaire : la revue, les tests et la vérification de son adéquation au contexte doivent rester sous responsabilité humaine
• Au final, il faut aussi réfléchir à la responsabilité et au périmètre d’impact (qui est responsable, qui subit les conséquences)
  • Un patch urgent peut répondre à une demande managériale à court terme, mais la charge de maintenance et de gestion des incidents retombera ensuite sur d’autres ingénieurs ou sur les utilisateurs
  • Comme pour l’impact d’un changement d’API sur une app mobile ou d’autres microservices, il faut toujours se demander « qui devra assumer les conséquences de cette décision ? »

What : définir le vrai problème et collecter les preuves

• Le cœur de la pensée critique consiste à définir avec précision « quel est le vrai problème »
  • Si l’on reçoit une demande du type « ajoutons une fonctionnalité de résumé par IA », il faut d’abord demander si l’objectif est d’améliorer la compréhension des données, de réduire la fatigue, ou autre chose
  • Selon que la difficulté ressentie par l’utilisateur vient d’un excès de données, d’un manque de visualisation ou d’absence d’explication, la solution peut être totalement différente
• Comme le soulignent notamment Harvard Business Review et d’autres sources, consacrer suffisamment de temps à la définition du problème réduit le risque de mobiliser des ressources sur le mauvais sujet
  • Il faut expliciter les exigences et les critères de succès, puis s’accorder sur la question : « dans quel état pourra-t-on considérer que le problème est résolu ? »
  • Il faut consciemment se méfier du plunging-in bias (le biais qui pousse à foncer immédiatement en mode résolution)
• Une définition du problème fondée sur les preuves, basée sur des faits concrets plutôt que sur des symptômes, est essentielle
  • Dire « le service est lent » est trop vague ; il faut réduire le champ via les données : quelle page, quelle requête, quel type de demande est lent ?
  • Il faut examiner les logs et les métriques avec des questions du type : « qu’est-ce qui est lent ? qu’est-ce qui a changé, et depuis quand ? qu’est-ce qui a été modifié récemment ? »
• Pour toute solution ou conclusion, il faut vérifier en boucle « quelles preuves soutiennent cette conclusion ? »
  • Si l’IA désigne un null pointer comme cause, il faut le valider directement avec les logs, les tests et des expériences de reproduction
  • Lorsqu’on affirme qu’il y a amélioration des performances, il faut vérifier que les indicateurs progressent de manière cohérente dans plusieurs environnements et sur plusieurs exécutions
• Les réponses des LLM doivent en général être traitées comme des hypothèses plausibles, mais sans garantie d’exactitude
  • Les humains ont tendance à cesser d’explorer davantage dès qu’ils entendent une réponse « suffisamment plausible », ce qui rend cette combinaison particulièrement risquée
  • La pensée critique consiste à traiter les idées de l’IA, des collègues et de soi-même comme des hypothèses à tester, en partant du principe qu’elles peuvent être fausses

Where : conscience du contexte, de l’environnement et du périmètre

• Il est important de comprendre où le problème survient et où la solution s’applique (le contexte)
  • Pour éviter de prendre un pic de CPU dans un microservice spécifique pour une panne globale du système, il faut localiser précisément l’endroit où le problème apparaît
  • Selon l’environnement d’exécution — smartphone de l’utilisateur, edge device, serveur cloud — un même code peut être soumis à des contraintes totalement différentes
• En phase de débogage, il faut remonter progressivement où la défaillance se produit en suivant le flux de requêtes et les frontières entre composants
  • Il faut isoler, à l’aide des logs et du monitoring, si le problème se situe côté client, API gateway, backend ou base de données
  • Même lorsqu’on discute d’une idée de fonctionnalité, il est utile de regarder à quelle étape du parcours utilisateur elle agit, et où se concentre la fréquence d’usage
• Pour les expérimentations et les déploiements aussi, l’endroit où tester est un facteur de décision important
  • Selon que l’on teste en staging, dans un environnement interne ou sur une partie du trafic de production, le niveau de confiance obtenu et les risques ne sont pas les mêmes
  • Exposer une partie des utilisateurs réels via un test A/B permet de détecter rapidement des problèmes du monde réel, mais exige aussi des garde-fous pour limiter l’impact
• La capacité à anticiper où des effets secondaires peuvent apparaître et jusqu’où ils peuvent se propager est caractéristique d’un ingénieur expérimenté
  • En cas de modification d’une bibliothèque partagée, il faut lister les autres services et équipes qui l’utilisent, puis préparer un plan de notification et de test avant la release
  • Il faut aussi examiner l’effet d’ensemble sur le système, par exemple si l’optimisation d’un module augmente la complexité d’un autre ou impose un changement de format de données

When : axe temporel et choix de profondeur

• Les informations sur « quand » le problème se produit et quand agir sont des indices clés pour l’analyse de cause
  • Si l’on reconstitue une timeline avec « quand cela fonctionnait encore pour la dernière fois » et « ce qui a changé depuis », on peut réduire plus vite le champ des causes possibles
  • Il est important de prendre l’habitude de relier l’heure d’apparition des incidents à des événements situés à des moments précis, comme un nouveau déploiement, un batch nocturne ou un changement de configuration
• Dans la prise de décision, distinguer quand creuser en profondeur et quand une heuristique suffit est une autre dimension essentielle de la pensée critique
  • Si l’on tente une analyse exhaustive sur tous les problèmes, le planning et les ressources ne suivront pas ; il faut donc ajuster la profondeur d’analyse selon le risque et l’impact
  • Lors d’un incident nocturne, une stratégie réaliste consiste à rétablir le service avec une mesure de court terme, comme un redémarrage, puis à rechercher la cause racine pendant les heures de travail
• Comme l’illustrent les cas de la NASA, le stress et la pression temporelle augmentent fortement le risque d’erreur de jugement humaine
  • Plus une situation exige une décision rapide, plus il est important d’indiquer à l’avance « jusqu’où va la mesure temporaire » et « à partir de quel point une réévaluation est obligatoire »
  • Le simple fait de laisser une note ou un ticket disant « c’est une solution provisoire ; il faudra impérativement faire ensuite une analyse de cause et une correction durable » aide déjà la qualité à long terme
• Pour conserver de la rigueur dans un temps limité, il faut utiliser la priorisation et le triage
  • Il faut tester d’abord les hypothèses les plus risquées et reporter les décisions moins importantes à plus tard
  • Si, dans la conception d’une nouvelle fonctionnalité, la validité de l’algorithme et les risques sont plus critiques que les détails de l’UI, il faut d’abord investir du temps dans la validation de l’algorithme
• La pensée critique est aussi liée à la capacité de reconnaître le bon moment pour demander de l’aide et le bon moment pour s’arrêter et reconsidérer
  • S’il n’y a plus de progrès après un certain temps, il faut attirer un autre regard ; il est aussi utile de définir volontairement des points d’arrêt et de revue, par exemple avant la fin d’un sprint ou avant une release
  • Entre la paralysie par l’analyse et les conclusions hâtives, il est important de vérifier soi-même si l’on dispose d’assez d’informations pour la décision en cours

Why : creuser les motivations, les causes et les fondements

• Répéter la question « pourquoi faisons-nous cela ? » joue le rôle de filtre contre les effets de mode et l’imitation sans sens, pour se concentrer sur la vraie valeur
  • Lorsqu’il s’agit d’adopter un nouvel outil d’IA ou d’ajouter une fonctionnalité, il faut distinguer clairement s’il s’agit de rattraper un concurrent ou de résoudre un vrai problème utilisateur
  • Il faut une réponse convaincante à la question « pourquoi est-ce important ? » pour que les nombreuses décisions de détail prises pendant l’implémentation restent cohérentes
• Lorsqu’un problème survient, il est important d’utiliser la méthode des 5 Whys pour descendre de la cause apparente vers les causes plus profondes
  • Si l’on prend l’exemple d’une baisse de précision d’un modèle, il faut remonter étape par étape les causes en chaîne : changement de distribution des données, ajout d’une nouvelle source de données, absence de validation, manque de monitoring, etc.
  • Si la cause finale est l’insuffisance de validation du pipeline de données ou l’absence de monitoring, on voit bien qu’un simple réentraînement ne résoudra pas le problème à la racine
• Dans les questions en « pourquoi », les humains tombent facilement dans le biais de confirmation et les conclusions hâtives
  • Si l’on se fixe sur une cause familière, comme une fuite mémoire déjà rencontrée, on risque d’ignorer d’autres possibilités comme un changement de configuration ou de données
  • Pour ne pas se satisfaire de la première explication venue, il faut se demander : « y a-t-il d’autres causes possibles ? existe-t-il des preuves qui contredisent cette hypothèse ? »
• Comme le montrent certains cas d’entreprise passés, une mauvaise compréhension du “pourquoi” peut empêcher pendant longtemps de corriger une baisse de part de marché ou un échec stratégique
  • Si l’on attribue tout à des facteurs externes sans voir les problèmes internes de processus, de qualité ou de culture, on répétera des remèdes inadaptés
• Un bon ingénieur conserve une curiosité humble qui pousse à demander “pourquoi” tout en restant ouvert à l’idée que ses hypothèses peuvent être fausses
  • Même lorsqu’il croit qu’une idée va réussir, il sépare « pourquoi il le pense » — données ou intuition — avant de définir la manière de le vérifier
  • Après une décision, il faut documenter et partager les raisons, afin de pouvoir réexaminer d’abord les fondements si le contexte change plus tard

How : mise en pratique et communication

• Mettre en pratique la pensée critique au quotidien peut se résumer autour de trois axes : la manière de poser des questions, la vérification des preuves et la structuration de la communication
  • Au lieu de questions vagues du type « c’est bien ou pas ? », il faut poser des questions concrètes et ouvertes, comme « quel besoin utilisateur cela couvre-t-il, et où cela peut-il échouer ? »
  • Il est important de séparer ce que l’on sait de ce que l’on ignore, puis de planifier comment expérimenter ou mesurer ce que l’on ne sait pas
• Lorsqu’on traite des preuves, il faut vérifier en même temps la possibilité d’interprétations alternatives et l’introduction de biais
  • Il faut recouper si le résultat d’un test de performance unique relève du hasard ou s’il est reproductible, et s’il n’entre pas en contradiction avec d’autres métriques
  • Il faut chercher délibérément non seulement les données qui confortent sa théorie, mais aussi celles qui pourraient la réfuter
• À l’échelle de l’équipe, l’article évoque aussi des méthodes comme le premortem, qui consiste à imaginer à l’avance des scénarios d’échec
  • Si l’on suppose que le projet a échoué et qu’on en écrit les raisons, on peut faire émerger, dès la phase de planification, des risques et des hypothèses cachées qui avaient été négligés
• Lorsqu’on présente une solution, il est efficace de structurer le raisonnement dans l’ordre définition du problème (What·Why) → solution proposée (How) → données et hypothèses qui la soutiennent
  • En explicitant les prémisses et les trade-offs, on aide les autres à vérifier et améliorer l’idée, tout en facilitant pour soi-même la détection de trous dans le raisonnement
  • Présenter en priorité des faits mesurables plutôt que des opinions, par exemple « le temps de chargement des pages s’est amélioré de 25 % en moyenne sur le dashboard », renforce la crédibilité
• Dans un environnement où la pensée critique fonctionne bien, il se forme une culture de communication qui accueille les questions et les objections
  • Après une proposition, il faut demander activement à ses collègues s’il manque quelque chose dans le raisonnement ou s’il y a des points de vigilance, afin d’affiner l’idée
  • Ce n’est pas la présentation unilatérale, mais le processus même de vérification collective du raisonnement qui tire la qualité de la solution vers le haut
• À l’échelle individuelle, l’amélioration continue de la réflexion par la rétrospective et l’apprentissage est importante
  • Si un bug vient d’une décision prise dans la précipitation, il faut ensuite faire une mini-rétrospective pour noter « ce qui a été manqué, et ce qu’il faudra faire différemment la prochaine fois »
  • Lire des postmortems d’autres entreprises et des ressources sur les biais cognitifs aide aussi à apprendre à l’avance les pièges de raisonnement à éviter plus tard

Conclusion : la pensée critique comme avantage proprement humain

• Plus l’usage de l’IA augmente, plus la pensée critique s’impose non comme une option, mais comme une compétence indispensable
  • Il faut examiner systématiquement les personnes, le problème, le contexte, le timing, les causes et la manière d’exécuter via Who·What·Where·When·Why·How
• Dans une culture d’équipe saine, la pensée indépendante et l’habitude de questionner sont considérées comme naturelles
  • Chacun doit pouvoir demander : « est-ce vraiment la solution, ou juste une rustine ? », « les utilisateurs veulent-ils vraiment cette fonctionnalité ? », « les données montrent-elles réellement une amélioration ? »
• La pensée critique protège l’équipe contre la tentation des solutions rapides et superficielles
  • Au lieu de simplement masquer le problème, vérifier la cause racine puis agir permet d’économiser du temps et des coûts sur le long terme
• Même à une époque où l’IA et l’automatisation prennent en charge les tâches répétitives et les brouillons initiaux, « résoudre le bon problème, pour les bonnes raisons et de la bonne manière » reste un rôle humain
  • Les équipes qui conservent une curiosité humble et une pensée centrée sur les preuves sont celles qui continueront à produire de bons résultats à l’ère de l’IA