Après les forteresses, les ateliers : apprendre en construisant avec l’IA

Quand fabriquer devient presque trop facile

Il y a encore quelques années, décider de construire son propre outil numérique impliquait un choix assez lourd. Il fallait savoir développer ou trouver quelqu’un qui savait le faire, comprendre l’hébergement, manipuler une base de données, concevoir une interface, sécuriser l’ensemble et accepter qu’une idée apparemment simple puisse nécessiter des semaines de travail.

L’intelligence artificielle a considérablement réduit cette barrière. Elle peut expliquer une technologie, proposer une architecture, produire du code, rechercher une erreur, suggérer une interface, rédiger une documentation ou accompagner une migration. Une personne disposant de connaissances techniques limitées peut désormais aller beaucoup plus loin qu’auparavant ; quelqu’un qui possède déjà ces connaissances peut, de son côté, expérimenter à une vitesse difficilement imaginable il y a encore quelques années.

Cette évolution pourrait conduire à une conclusion assez logique : puisque l’IA permet de produire plus facilement et que des milliers de services existent déjà, pourquoi continuer à fabriquer ses propres outils ?

C’est précisément là que la question devient intéressante, car construire ne sert pas uniquement à obtenir un produit. Construire est aussi une manière d’apprendre.

Cette idée rejoint directement le fil suivi depuis longtemps sur Kachouri.com. Le changelog du site raconte d’ailleurs cette continuité : apprendre en partageant, documenter ce que le terrain apprend et transformer le site lui-même en laboratoire. L’IA change la vitesse de l’exercice, mais pas nécessairement sa nature.

Un site peut être un produit, mais aussi un atelier

Je construis régulièrement de petits sites et outils. Certains deviennent des projets publics, d’autres changent plusieurs fois de direction, quelques-uns finiront probablement abandonnés. Vu uniquement sous l’angle économique, cette démarche pourrait sembler peu rationnelle : il existe souvent une solution déjà disponible, parfois plus mature, mieux financée et immédiatement utilisable.

Pourtant, le produit final n’est qu’une partie de ce que l’exercice produit réellement.

Prenons DimaReady. Construire un tableau de bord permettant d’organiser et de suivre des données ne consiste pas seulement à dessiner quelques graphiques. Très rapidement apparaissent des questions sur la provenance des données, leur historique, leur conservation, la différence entre une observation et une projection, la manière de présenter une incertitude, le fonctionnement hors connexion, l’expérience sur mobile, la récupération d’un accès ou encore la frontière entre ce que l’outil peut montrer et ce qu’il serait imprudent de lui faire affirmer.

Une partie de ces problèmes peut être anticipée en lisant de la documentation. Une autre ne devient réellement compréhensible qu’au moment où elle se présente. Le retour d’expérience sur MiniMax H3 avec WanGP en donne un exemple concret : faire tourner un modèle n’est pas encore savoir produire avec lui, et la valeur apparaît lorsque les erreurs de prompt, de file de génération, de licence et de montage deviennent des règles réutilisables.

C’est le même phénomène avec un projet comme AfterMachine. Dès que l’on veut rendre un corpus réglementaire ou documentaire plus accessible, la question n’est plus seulement de construire une interface. Il faut décider quelles sources font autorité, comment les dater, comment éviter qu’une simplification devienne une déformation et comment distinguer une information vérifiée d’une interprétation.

À chaque fois, le projet que l’on pensait construire finit par nous apprendre quelque chose sur le problème lui-même.

C’est probablement l’une des transformations les plus intéressantes apportées par l’IA : elle ne supprime pas le learning by doing, elle peut en réduire considérablement le coût d’entrée.

Le Knowledge Management commence aussi dans les erreurs

Cette idée n’est pas nouvelle. Dans les travaux sur le Knowledge Management, la distinction entre connaissance explicite et connaissance tacite occupe une place ancienne. La première peut être documentée, organisée et transmise relativement facilement. La seconde est davantage liée à l’expérience, au contexte, aux gestes, aux habitudes et aux arbitrages acquis en pratiquant.

Dans le modèle SECI associé aux travaux d’Ikujiro Nonaka, l’internalisation décrit précisément le passage d’une connaissance explicite vers une connaissance tacite, notamment par l’apprentissage dans l’action. Une revue systématique publiée en 2026 dans le VINE Journal of Information and Knowledge Management Systems, fondée sur 82 publications scientifiques, utilise encore ce cadre pour analyser la manière dont l’IA peut intervenir dans la création de connaissance organisationnelle.

Autrement dit, lire comment faire quelque chose et avoir réellement dû le faire ne produisent pas exactement la même connaissance.

On peut lire pendant des heures qu’une politique de sécurité trop restrictive peut casser une application. Le jour où une CSP bloque réellement une fonction que l’on croyait correctement conçue, la compréhension change. On peut connaître le principe du mobile first ; lorsqu’une interface parfaitement convaincante sur un écran de bureau devient pénible sur un téléphone, le concept cesse d’être une recommandation abstraite. On peut savoir qu’une sauvegarde doit être testée ; lorsqu’il faut réellement reconstruire un système, on découvre immédiatement la différence entre posséder une sauvegarde et disposer d’une procédure de restauration fiable.

L’erreur prend alors une valeur particulière. Elle n’est plus seulement quelque chose à corriger, mais une information sur le système et sur notre propre manière de le comprendre.

Une étude publiée dans l’International Journal of Information Management a justement examiné les relations entre apprentissage par l’action, acquisition de connaissances tacites, partage et innovation auprès de professionnels IT aux États-Unis et en Pologne. Les résultats soutiennent l’idée que l’expérimentation et l’interaction participent à l’acquisition de connaissances tacites et que leur internalisation et leur externalisation contribuent ensuite à transformer cette connaissance en action.

Le véritable enjeu de Knowledge Management apparaît à cet endroit : une erreur individuelle n’a que peu de valeur collective si elle disparaît une fois corrigée. Elle devient un actif lorsqu’on en conserve la cause, la correction et surtout la leçon.

L’IA peut accélérer la courbe d’apprentissage, mais pas automatiquement

Les premières recherches sur l’usage de l’IA générative au travail apportent ici un résultat particulièrement intéressant. Erik Brynjolfsson, Danielle Li et Lindsey Raymond ont étudié le déploiement d’un assistant génératif auprès de 5 179 agents de support. Ils ont observé une augmentation moyenne de productivité de 14 %, mais le résultat le plus instructif concernait la répartition de ces gains : les agents les moins expérimentés et les moins performants bénéficiaient beaucoup plus de l’outil que les travailleurs déjà expérimentés.

Les chercheurs avancent notamment l’idée que le système permettait de diffuser vers les nouveaux employés une partie des pratiques observées chez les meilleurs agents. L’IA ne servait donc pas seulement à produire une réponse plus rapidement ; elle fonctionnait aussi, dans une certaine mesure, comme un mécanisme de transmission de pratiques. Un autre essai randomisé mené auprès de 7 137 travailleurs de la connaissance a observé des gains de temps individuels, notamment sur l’e-mail, sans transformation détectable de la composition globale des tâches. Ce contraste rappelle qu’un gain local ne devient pas automatiquement un changement organisationnel.

Il faut néanmoins résister à une conclusion trop confortable. Utiliser une IA n’entraîne pas automatiquement un apprentissage. On peut obtenir un résultat sans comprendre comment il a été obtenu, accepter du code que l’on serait incapable d’expliquer ou déléguer une décision jusqu’à perdre progressivement la compétence nécessaire pour la contrôler.

La différence se situe probablement dans la manière d’utiliser l’outil. Demander à l’IA de résoudre un problème puis copier sa réponse produit un résultat. Lui demander d’expliquer pourquoi une première approche échoue, comparer plusieurs solutions, tester leurs limites, confronter la proposition au réel puis conserver ce qui a été appris produit potentiellement de la connaissance.

L’IA raccourcit considérablement le chemin entre l’idée et le premier prototype. Elle ne raccourcit pas nécessairement le chemin entre le prototype et la compréhension. C’est aussi ce que suggère l’Answer Engineering : formaliser ce qu’une sortie doit respecter aide à transformer l’essai en méthode plutôt qu’à simplement produire davantage.

Cette distinction prolonge aussi le débat abordé dans Le prix de la pensée, consacré au risque de lock-in et à l’atrophie du jugement lorsque les outils de raisonnement deviennent des intermédiaires permanents. Utilisée comme partenaire d’exploration, l’IA peut accélérer l’apprentissage ; utilisée comme substitut systématique au raisonnement, elle peut au contraire déplacer la compétence hors de l’organisation.

Construire ne signifie pas vouloir tout reconstruire

Il serait pourtant absurde de transformer cette réflexion en apologie du"fait maison". Tout reconstruire soi-même n’est ni une stratégie d’autonomie ni une preuve de compétence.

Personne n’a besoin de réécrire TLS pour apprendre à sécuriser un site, de développer son propre moteur de base de données pour comprendre la persistance ou de réinventer chaque bibliothèque utilisée dans un projet. La connaissance consiste aussi à savoir reconnaître les briques suffisamment éprouvées pour leur faire confiance et celles dont la criticité justifie une compréhension plus profonde.

C’est précisément ce qui relie cette réflexion au dossier Kachouri consacré aux dépendances technologiques. L’autonomie ne signifie pas l’absence de dépendance. Elle consiste à savoir de quoi l’on dépend, pourquoi on l’accepte, ce que cette dépendance apporte et comment on pourrait en sortir.

Construire un projet personnel ou un prototype devient alors une sorte de laboratoire. On peut y essayer une architecture, provoquer des erreurs, modifier une hypothèse, mesurer les conséquences et recommencer sans exposer immédiatement une organisation entière aux résultats de l’expérience.

L’IA rend aujourd’hui ces laboratoires beaucoup moins coûteux.

Cette logique rejoint aussi la notion de souveraineté numérique pragmatique, qui consiste moins à prétendre tout maîtriser qu’à distinguer ce qui peut être délégué de ce qui doit rester contrôlable, documenté et réversible.

Du projet personnel à la mémoire collective

Reste une étape essentielle : transformer cette expérimentation en connaissance durable. C’est là que le Knowledge Management cesse d’être un terme abstrait pour redevenir une pratique extrêmement concrète.

Si chaque projet recommence de zéro, si les mêmes erreurs sont reproduites et si les décisions restent enfermées dans une conversation avec une IA, l’apprentissage existe peut-être pour l’individu, mais il se diffuse mal. À l’inverse, conserver les décisions d’architecture, les incidents, les raisons d’un changement, les procédures qui ont fonctionné, celles qui ont échoué et les critères utilisés pour arbitrer constitue progressivement une mémoire réutilisable.

Un projet nourrit alors le suivant.

La mauvaise décision de cache rencontrée hier devient une vérification automatique demain. L’interface mobile ratée sur un premier projet devient une contrainte de conception sur le suivant. Une restauration difficile devient une procédure testée. Une dépendance découverte trop tard devient un contrôle d’architecture. Une réponse erronée d’un modèle devient une règle exigeant une source ou une validation humaine.

À mesure que ces apprentissages sont formalisés, l’IA elle-même peut les réutiliser. Elle ne travaille plus seulement à partir de connaissances génériques apprises ailleurs, mais dans un environnement où l’organisation a progressivement documenté ses propres règles, ses propres erreurs et ses propres arbitrages.

C’est peut-être là que se trouve le lien le plus intéressant entre IA et Knowledge Management : l’IA accélère l’expérimentation, tandis que le KM empêche que l’expérience produite par cette accélération disparaisse.

Sans KM, on peut construire plus vite et oublier tout aussi vite. Avec lui, chaque projet peut devenir une couche supplémentaire de connaissance. L’article sur IA et pensée complexe complète cette lecture : documenter les interactions et les rétroactions permet de comprendre comment le système se transforme au fil des usages, pas seulement comment chaque composant fonctionne isolément.

Cette logique rejoint également la manière dont Kachouri aborde l’intelligence économique : transformer une accumulation de signaux en décisions documentées, relier les sources, conserver les hypothèses et garder la possibilité de revenir sur un arbitrage lorsque le contexte change.

Ma lecture

Ce qui change avec l’IA n’est donc pas seulement notre capacité à produire. C’est le nombre d’expériences que nous pouvons nous permettre de tenter.

Un projet qui aurait demandé plusieurs mois peut parfois être prototypé en quelques jours. Une technologie inconnue peut être explorée sans suivre au préalable plusieurs semaines de formation. Une personne peut se confronter à des domaines qu’elle n’aurait probablement jamais abordés seule. Cette accélération ouvre une possibilité considérable, à condition de ne pas confondre l’assistance avec la compétence.

Construire DimaReady, AfterMachine ou n’importe quel autre petit outil n’a d’intérêt, dans cette perspective, ni parce qu’il faudrait absolument posséder sa solution, ni parce que développer soi-même serait intrinsèquement supérieur à acheter. L’intérêt réside dans le processus : poser un problème, tenter une réponse, rencontrer ses limites, comprendre pourquoi elle échoue, la corriger et conserver ce qui a été appris.

À force de projets, une sorte de capital invisible se constitue. Il n’est pas seulement dans le code produit, mais dans les réflexes acquis, les questions que l’on pense désormais à poser, les erreurs que l’on repère plus tôt et les choix que l’on sait mieux expliquer.

L’IA peut considérablement accélérer cette accumulation. Le Knowledge Management lui donne une mémoire.

Cette logique d’apprentissage par essais, documentation et retours d’expérience nourrit aussi Complexiance, un projet en cours consacré aux rapports entre complexité, intelligence artificielle et sciences.

Après les forteresses, il nous faut donc peut-être aussi préserver des ateliers : des endroits où l’on peut encore démonter, essayer, se tromper et comprendre.

Car dans un monde où produire devient de plus en plus facile, comprendre ce que l’on produit pourrait devenir la compétence la plus difficile à automatiser.