Ce que vous ne trouverez pas dans ce blog

Dans le chapitre précédent, j'ai décrit ce que ce blog peut vous apporter. Des notes prises en cours de route. Des échecs présentés sans fard. Une façon de repartir avec les éléments qui vous parlent, même si tout ne s'applique pas à votre situation. J'ai essayé d'être honnête sur ces points.

Dans ce chapitre, je décris l'autre face.

Ce que vous ne trouverez pas ici, et où s'arrêtent les limites de ce blog. J'aurais pu ne pas l'écrire — on pourrait se dire « si c'est pour lire ce qui manque, pourquoi continuer ? » C'est d'ailleurs pour cela que j'ai placé ce chapitre après le précédent. Mais ne pas le dire ne me semblait pas juste. Il est plus facile d'accepter les limites quand on a d'abord une idée de ce qu'on peut obtenir.

Pas de recettes applicables dès demain

C'est le point sur lequel je veux être le plus direct.

Vous ne trouverez pas ici de formule du type « 5 étapes pour commencer à l'utiliser demain ». Je peux écrire des notes sur la façon dont j'ai conçu un système faisant fonctionner plusieurs agents IA (ici : des programmes autonomes qui exécutent des tâches) ensemble. Mais je ne peux pas affirmer : « si vous reproduisez exactement ces étapes, ça fonctionnera chez vous ». On n'en est pas encore là.

Par exemple : j'ai testé un système dans lequel un agent IA était chargé de vérifier le travail d'un autre. Au stade de la conception, je pensais que la cohérence serait assurée. Mais une fois en fonctionnement réel, l'agent chargé de la vérification a interprété les instructions à sa façon en cours d'exécution, et le résultat ne correspondait pas à ce que j'avais prévu. J'écris cet échec tel quel. Pourquoi c'est arrivé, comment j'ai tenté de corriger, et quels problèmes restaient encore après la correction. C'est ce type de notes que j'accumule ici.

Lire ces notes pour en retirer ce qui peut s'appliquer à votre situation — c'est tout à fait possible. En revanche, si vous cherchez une recette finie qui fonctionne directement dans votre environnement, ce blog sera probablement un peu en décalage avec vos attentes.

Pas de modèles à copier-coller

Ce que je viens de dire rejoint le point suivant, mais pour aller un peu plus loin : il n'est pas dans mes intentions de publier des fichiers tout prêts du type « copiez ceci, configurez cela, et ça tourne ».

Pour deux raisons.

La première : le comportement varie considérablement selon les environnements. Même conçu avec la même approche, le système nécessaire change selon la version des outils utilisés, la taille de l'équipe, ou ce qu'on cherche à automatiser. Je ne peux pas prétendre avoir quelque chose d'assez universel pour que vous l'utilisiez tel quel.

La deuxième : transmettre un modèle sans la réflexion qui l'accompagne risque de mettre la personne qui l'utilise en difficulté. Quand on construit un système de vérification par un agent IA, il faut d'abord clarifier ce qu'on fait confiance et ce qu'on remet en question. Sans cela, on se retrouve avec un système qui semble faire une vérification, mais dont le contenu est creux. Donner le modèle sans la façon de penser qui va avec, c'est ce genre de situation qu'on crée. Repartir avec la réflexion en lisant les notes sera, je pense, plus utile sur la durée.

Pas d'explications sur les outils ni d'actualités

Je n'écrirai pas d'articles expliquant pas à pas comment utiliser tel ou tel outil. Les informations du type « quelles fonctionnalités propose cet outil » ou « qu'est-ce qui a été ajouté récemment » ne font pas partie du périmètre de ce blog.

Les outils liés à l'IA évoluent vite. Une explication de manipulation devient obsolète en quelques mois. Garder une trace de pourquoi la conception a pris telle forme a plus de valeur dans la durée, parce que cette réflexion reste pertinente même quand les outils changent. C'est sur ce point que je concentre les notes.

Des noms d'outils apparaissent dans les notes, mais uniquement pour donner du contexte. Ce ne sont pas des articles de présentation de ces outils.

Pas de révélation sur l'identité derrière ce blog

Il me semble important de le préciser aussi.

Je ne publierai pas d'informations personnelles sur qui écrit ce blog. Ni mon nom, ni mon visage, ni mon parcours. Si Structure Log est utilisé comme identité pour ce blog, ce n'est pas uniquement pour préserver un anonymat. C'est aussi parce que je préfère que vous lisiez ces notes comme un journal de conception — ce qui a été mis en place, ce qui s'est passé — plutôt que comme le témoignage d'une personne en particulier.

Je n'attends pas que vous accordiez votre confiance en vous disant « cette personne est impressionnante, donc ça vaut la peine ». Je n'attends pas non plus que vous écartiez les notes en vous disant « cette personne est débutante, ça ne m'est pas utile ». Ce qui compte, c'est de regarder ce que contiennent les notes et de juger par vous-même si cela peut s'appliquer à votre situation.

Ne pas savoir qui se cache derrière ne devrait pas poser de problème pour la lecture.

Lire en connaissant les limites

J'ai décrit quatre points — ce que vous ne trouverez pas ici.

Pas de recettes immédiatement applicables. Pas de modèles à copier-coller. Pas d'explications sur les outils ni de veille sur l'actualité. Pas d'informations sur l'identité de l'auteur.

Certains se demanderont peut-être : « alors, pourquoi lire ? » Pourtant, la raison pour laquelle je publie ces notes, c'est que suivre un processus de conception en cours — avec ses étapes, ses erreurs, ses ajustements — a une valeur différente de celle de recevoir un résultat fini. Le fait que des échecs soient inclus, le fait que le travail soit encore en cours, peut parfois créer chez le lecteur ce sentiment de « peut-être que je pourrais essayer aussi ». C'est du moins ce type de connexion que je cherche à établir.

Connaître les limites à l'avance, c'est ce qui permet, je crois, de recevoir plus simplement ce que ce blog peut vraiment vous apporter.

À partir du chapitre suivant, j'entre dans les notes concrètes : quelles conceptions j'ai testées, et ce qui s'est passé.