> For the complete documentation index, see [llms.txt](https://weekly-essay.mikey.wang/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://weekly-essay.mikey.wang/fr/2026/w38-everything-can-be-engineered.md).

# W38-Tout peut faire l’objet d’une démarche d’ingénierie

Plusieurs travaux récents m’ont fait ressentir de plus en plus nettement que l’IA change ma façon de traiter les problèmes complexes.

Auparavant, au-delà d’un certain degré de complexité, je n’avais souvent d’autre choix que d’y consacrer davantage d’attention. Retenir la configuration, tenir la documentation, réexpliquer le contexte, puis enquêter en cas d’erreur. Même quand je savais qu’un programme pouvait résoudre le problème, construire et entretenir un système n’en valait pas forcément la peine.

Aujourd’hui, je suis plus enclin à en faire un projet d’ingénierie.

Consigner les faits et les règles, confier les opérations répétitives aux programmes, ajouter des vérifications aux changements, conserver l’historique et les possibilités de retour en arrière. Puis étendre cette base quand un nouveau besoin apparaît.

Ces méthodes existent depuis longtemps. **L’IA réduit leur coût de mise en œuvre et de maintenance, rendant rentables de nombreux projets qui ne l’étaient pas auparavant.**

## D’une configuration de proxy à un projet maintenable

Le premier exemple est la configuration du proxy de mon Mac.

Au départ, il s’agissait simplement de permettre à quelques applications d’accéder correctement au réseau. Avec l’augmentation des besoins sont venus l’aiguillage par site, l’accès direct au réseau de l’entreprise, les différences d’environnement entre ligne de commande et applications de bureau, ainsi que les mises à jour et les migrations entre appareils.

Chaque intervention isolée restait assez simple. Mais l’accumulation des règles rendait leur entretien de mémoire difficile. Une fois un problème résolu, je pouvais finir par oublier pourquoi la configuration avait été choisie, sans savoir ce que toucherait la modification suivante.

J’ai fini par rassembler cette solution dans un dépôt privé.

Il contient des modèles de configuration, des règles d’aiguillage, des scripts de génération et de vérification, ainsi que des guides de restauration, de maintenance et de dépannage. On peut prévisualiser avant de modifier, sauvegarder avant d’installer et revenir en arrière en cas de problème. La migration vers un autre Mac suit aussi des étapes et des critères de validation explicites.

J’ai déjà réalisé cette migration sur un autre ordinateur, ce qui a confirmé l’efficacité et la rapidité de la solution. Le processus qui exigeait auparavant des vérifications et des réglages manuels successifs peut désormais suivre les règles et procédures du dépôt. La réutilisabilité de ce projet a donc été éprouvée en pratique.

Pour moi, le changement est de pouvoir enfin traiter cette configuration comme un système à entretenir dans la durée. Quand j’ajoute une application ou modifie une règle, je sais où intervenir, comment vérifier et comment retrouver ce qui a été fait auparavant.

**La complexité existe toujours, mais elle a désormais un emplacement et un mode de traitement explicites.**

## L’équipe d’agents elle-même demande une démarche d’ingénierie

Mon deuxième exemple est l’équipe d’agents que je fais fonctionner depuis quelque temps.

Quand on travaille seul avec un ou deux agents, il suffit généralement de dialoguer avec eux et de leur attribuer des tâches.

Mais pour répartir différents travaux entre plusieurs rôles et leur permettre de s’organiser et de collaborer face à des problèmes complexes, il faut des règles de fonctionnement explicites.

Qui décompose les tâches, qui implémente, qui relit, comment se transmet le travail et qui reprend en cas de problème : tout cela doit être prévu. Ajouter des tâches automatiques à l’équipe ou au projet exige aussi de gérer leur déclenchement et leur exécution. Par exemple, détecter automatiquement les changements de code pour effectuer une revue de PR, ou projeter automatiquement le contenu approprié dans les sous-dépôts après une fusion dans le dépôt d’intégration.

Ces besoins ont progressivement dépassé la simple maintenance manuelle de quelques prompts. J’ai donc organisé les rôles des agents, les règles de collaboration et les tâches automatiques dans un projet que l’on peut gérer, exploiter et étendre en continu.

Les responsabilités, les règles de collaboration et les stratégies d’exécution sont conservées dans le dépôt. Celui-ci déclare l’état attendu de l’équipe ; les outils de synchronisation vérifient les écarts avec l’état en fonctionnement. Les changements peuvent être prévisualisés, puis leur conformité contrôlée après application.

Je peux ainsi ajuster l’équipe en continu sans devoir la réassembler à chaque fois.

**Une collaboration réussie peut devenir une règle commune à tous les rôles concernés.**

De même, un problème révélé par un échec peut entrer dans la configuration et les vérifications, et servir de base au travail suivant.

Je commence à traiter l’équipe d’agents comme un système à exploiter et à faire évoluer. La capacité des modèles n’en est qu’une composante. Les limites des rôles, les transmissions de tâches et les modes de validation demandent eux aussi des améliorations continues.

## Donner une version commune au contexte de travail de l’équipe

Le troisième exemple est le MVP de déclaration fiscale en cours.

Nous développons ce projet dans le dépôt d’intégration de BFO. Documents produit et architecture, contrats d’interface, spécifications de validation, code frontend et backend, et outils des agents entrent dans le même dépôt pour constituer une base de version commune.

**Je veux parvenir à une façon de travailler où la documentation est du code et le code est le produit.**

Quand une règle produit change, les documents, contrats, implémentations et critères de validation associés peuvent être modifiés et relus ensemble. Nous pouvons revenir à une version donnée pour voir quelles étaient les exigences, comment le code les réalisait et selon quels critères on jugeait leur conformité.

Auparavant, ces éléments étaient souvent dispersés entre documents, conversations et mémoires individuelles. La collaboration entre rôles obligeait à les transporter et à les expliquer sans cesse. Le produit expliquait, le développement interprétait, puis les tests reconstituaient. Après une évolution du besoin, il fallait encore vérifier que chacun possédait la même version.

Le dépôt d’intégration fournit une référence commune à ce travail.

Il ne supprime pas les différences de compréhension entre personnes, mais peut réduire le coût de recherche d’informations, de vérification des versions et de répétition du contexte. Les discussions portent sur des changements précis, et leurs conclusions ont un endroit où être conservées.

L’IA peut elle aussi lire ces matériaux. À la réception d’une tâche, elle peut chercher le contexte à travers les besoins, les contrats, l’implémentation et les tests, sans dépendre entièrement des informations apportées sur le moment dans la conversation.

Ce MVP est encore en cours et ses bénéfices à long terme restent à vérifier. Mais j’accorde une importance particulière aux itérations quotidiennes qui suivront. Si ces actifs sont entretenus avec le produit, chaque cycle peut laisser une base plus complète au suivant.

**Le travail déjà accompli peut continuer à réduire le coût du travail futur.**

## Faits et présentation dans la gestion financière

Le quatrième exemple n’existe pas encore : c’est mon projet de gestion des finances personnelles et des investissements.

Je conserve actuellement dans Google Drive des documents de revue hebdomadaire, mensuelle et trimestrielle des finances familiales, et j’observe régulièrement les marchés.

Je compte organiser progressivement ces activités dans un projet privé : situation financière de la famille, actifs d’investissement, canaux d’investissement, observations de marché et comptes rendus des revues périodiques.

**Ce qui m’attire le plus ici est de séparer la source des faits de leur mode de présentation.**

Auparavant, choisir un tableur, un document ou un diaporama revenait souvent à penser immédiatement à la forme finale de l’information. L’outil de présentation pouvait facilement dicter l’organisation des données.

À l’avenir, je veux d’abord entretenir un registre de base avec des sources, des dates et des versions, puis produire une présentation adaptée à la question posée.

Pour voir la structure du patrimoine, générer un graphique. Pour effectuer une revue mensuelle, produire un rapport. Pour comprendre un changement, interroger l’historique. Toutes ces présentations partiraient des mêmes données et pourraient être vérifiées à leur source.

Je n’aurais ainsi plus à réorganiser les faits pour chaque présentation. Graphiques et rapports pourraient être générés et ajustés à tout moment ; l’entretien à long terme porterait surtout sur l’exactitude, l’exhaustivité et l’actualité des informations de base.

Cela fait aussi évoluer ma compréhension de l’ingénierie. Un projet peut porter des faits, des règles et des traces de décisions, puis générer selon les besoins des interfaces que les personnes peuvent lire et utiliser.

## L’IA facilite l’amortissement de l’investissement d’ingénierie

Ces exemples ont un point commun. Ils ont tous accumulé une certaine complexité et exigent tous un entretien continu.

Auparavant, je n’aurais pas nécessairement voulu en faire des projets. Écrire des scripts, compléter la documentation, vérifier et entretenir les outils demandent un investissement. Beaucoup de besoins personnels sont trop modestes pour couvrir ce coût, et finissent par rester manuels.

L’IA réduit cet investissement.

Quand organiser la configuration, écrire des scripts, ajouter des tests et entretenir la documentation coûte moins cher, j’accepte de traiter davantage de problèmes par l’ingénierie. Configuration de proxy, collaboration entre agents, contexte de travail de l’équipe, et même finances familiales entrent dans ce périmètre.

**La fiabilité exige toujours des mécanismes concrets.**

Il faut vérifier les faits, valider les changements, détecter les échecs et pouvoir revenir en arrière si nécessaire. L’IA peut aider à créer et à entretenir ces mécanismes, mais elle ne les remplace pas.

C’est sur cette base que je me sens plus confiant pour ajouter des capacités. **Le système peut traiter davantage de problèmes sans exiger une augmentation proportionnelle de ma mémoire et de mon attention.**

Une conviction devient de plus en plus claire pour moi : tout peut faire l’objet d’une démarche d’ingénierie.

Plus précisément, **dès qu’un problème comporte une partie que l’on peut décrire, calculer et vérifier explicitement, je peux chercher à l’organiser en un projet maintenable dans la durée.**

Le jugement et les arbitrages restent humains, mais l’organisation de l’information, l’exécution et les retours qui les entourent peuvent s’améliorer continuellement.

Face à un problème complexe, je pensais d’abord à l’énergie qu’il me demanderait. Aujourd’hui, je commence par me demander si je peux lui construire un système qui continuera à grandir.