GalaxIA génératives

L’écosystème des IA génératives ressemble à une nébuleuse où la matière s’agrège, s’enflamme, puis donne naissance à une myriade de planètes encore instables. Dans ce chaos créatif, la vraie question n’est pas de trouver « la meilleure étoile », mais de choisir sereinement sur quelle planète poser ses valises numériques pour un temps donné.

Naissance d’un système solaire d’IA

Depuis quelques années, chaque annonce de modèle ou de service ajoute une nouvelle masse dans cette nébuleuse : modèles fermés ultra‑puissants, alternatives plus frugales, offres spécialisées, outils locaux, API souveraines. Autour de quelques étoiles massives gravitent ainsi des planètes de toutes tailles : copilots pour le code, assistants de recherche, agents autonomes, services d’entreprise.

Dans le monde du développement logiciel, la conférence Tech.Rocks « AI & génération de code : productivité boostée, lucidité en danger » d’Arthur Magne a remis un peu de concret dans tout ce brouillard cosmique : l’IA accélère la frappe au clavier, mais pas magiquement la spécification, les tests, la revue, le delivery. La vraie gravité reste celle des pratiques de craft (TDD, DDD, clean code, Lean) et des architectures solides ; sans elles, l’IA ne fait qu’aider à construire plus vite une dette technique à retardement.

Une cartographie très imparfaite

J’ai eu besoin un matin de prendre du recul et d’établir une cartographie de l’offre en matière d’IA générative à destination du grand public. A partir de quelques données récupérées d’études existantes, j’ai potassé un truc avec le tableur de Bill (j’ai passé plus de temps à la mise en forme qu’à la recherche de vérité sur les données, on en reparle ensuite)

La carte que je propose positionne des bulles, des planètes selon deux forces d’attraction : la qualité / complétude des réponses et la vitesse de production, la taille de la planète représentant le coût, et la couleur son degré de souveraineté. C’est une carte de technicien, focalisée sur les caractéristiques des moteurs eux‑mêmes, pas sur les usages ni sur la viabilité à long terme, et encore moins sur l’éthique ou l’impact sur les métiers.

Pour la rendre un minimum exploitable, je l’ancre dans des situations concrètes : comment ces outils se comportent sur la lecture d’une base de code existante, la rédaction de tests, la revue d’une PR, la préparation d’une spec technique, ou encore sur un sprint complet avec une équipe réelle. Cela permet de comparer des ordres de grandeur (vitesse, qualité perçue, coûts mensuels par équipe) avant d’embarquer tout un produit sur une orbite hasardeuse autour d’un fournisseur donné.

Où atterrir quelques semaines

Dans ce système, l’enjeu n’est pas de trouver une planète définitive, mais un bon camp de base temporaire pour nos explorations. Bruno Latour posait cette question essentielle : « Où atterrir ? » — où voulons‑nous vraiment nous poser, avec quelles dépendances et quelles attachances, plutôt que de flotter dans une globalisation abstraite. Ici, cela revient à décider où l’on accepte de mettre son code, ses données et ses routines quotidiennes pendant quelques jours ou quelques semaines : quelle planète mérite notre confiance, pour combien de temps, et avec quelles portes de sortie prévues.

Ce questionnement rappelle la période du confinement, quand nous proposions des ateliers de « rétro‑confinement » pour relire ce que cette crise révélait de nos organisations, de nos dépendances et de nos marges de manœuvre. De la même manière, un atelier de « rétro‑IA » devient utile : regarder où l’IA crée de nouveaux goulots (revue, QA, prod), à quelles étapes elle apporte réellement de la fluidité (spec, plans techniques, tests, tri des bugs, PRs) et quelles conditions minimales sont nécessaires pour éviter l’amplification du chaos.

Découpler la matière grise du moteur

Les recommandations récentes convergent : il faut découpler la connaissance métier, les processus et les données des moteurs d’IA eux‑mêmes. Le paysage des outils est fragmenté (Copilot, Cursor, Claude, Mistral, Perplexity, etc.), et il va continuer à bouger ; notre job n’est pas de parier sur la planète gagnante, mais de faire en sorte que changer de planète reste possible sans tout reconstruire.

Pour ça, je propose quelques solutions très terre‑à‑terre :

• Cartographier les domaines métiers (DDD, bounded contexts) et rendre explicite qui fait quoi, où se trouvent les invariants et quelles sont les règles vraiment critiques.
• Documenter les architectures fonctionnelles et techniques avec des cartes assez simples pour être discutées par toute l’équipe, mais assez précises pour guider les choix d’outillage et les points de couplage avec les IA.
• Encapsuler les modèles d’IA derrière des interfaces claires (ports/adapters, façades d’API) afin de pouvoir remplacer un modèle ou un fournisseur sans réécrire tout le système, en ne touchant qu’une fine couche d’intégration.
• Traiter les fichiers d’instructions comme une nouvelle forme de code : prompts structurés, règles pour agents, guides Markdown deviennent la « source » de nos systèmes IA, et méritent donc versionnage, revue, tests et maintenance.

Miser sur les planètes vraiment critiques

Dans ce paysage mouvant, les vrais actifs ne sont ni la marque du modèle ni la brillance marketing de l’étoile, mais ce que nous construisons autour : la connaissance du contexte, la maîtrise et la gouvernance des données, la définition explicite des règles métier, et l’architecture qui permet de recâbler le tout. L’IA devient alors un amplificateur : si le contexte est sain, elle amplifie la valeur ; si le système est bancal, elle amplifie le chaos et la dette technique.

C’est là que le « context engineering » prend tout son sens : on ne passe plus ses journées à corriger l’output, mais à soigner l’input, à structurer le contexte, à écrire ce Markdown qui devient notre nouveau langage de programmation pour piloter les IA. Les équipes déjà fortes en craft, en tests, en architecture et en cartographie des domaines prennent une longueur d’avance, parce qu’elles savent quoi confier aux agents, comment les briefer et comment les plier à leurs standards plutôt que l’inverse.

---

Ce billet s’inscrit dans le prolongement direct du post de Laurent Meurisse résumant la conférence Tech.Rocks « AI & génération de code : productivité boostée, lucidité en danger » d’Arthur Magne, qui a servi de déclencheur et de mise en orbite pour ces réflexions très concrètes sur nos choix de planètes IA.

Références :

• Le post Linkedin de Laurent Meurisse sur le Tech.Rocks AI & Génération de code

• La rétro-confinement

• Un podcast 2021 Radia France Où atterrir ?

• Un nouvel atelier Bataille de l’IA de l’assocaition Latitudes, découvert auprès du collectif d’animateurs de la Fresque du Numérique à Toulouse.

Mon prompt initial sur Perplexity.ai

La rédaction de cet article a fait l’objet d’une assistance par l’IA Perplexity. Perplexity est un nom bien trouvé, pour l’état dans lequel nous nous trouvons face à un monde complexe.

Le prompt:

Ecrit un article pour un blog sur les IA génératives, en filant la métaphore de la création d’une étoile et ses amas de matière (grise ou pas) qui finissent pas constituer des planètes. Certaines sont viables d’autres moins, mais qui sait dire l’avenir dans ce tumulte, ce chaos ? Comment faire son choix d’où poser ses valises (et son cerveau) pendant quelques jours ou quelques semaines. Je propose une cartographie de ce nouveau système, ou chaque planète est positionnée selon la “qualité des données et la vitesse de production, le coût financier représenté par la taille de la planète et la souveraineté par la couleur des planètes. Même si c’est une représentation très approximative et non exhaustive. Elle ne représente que les caractéristiques techniques de ces systèmes et ne traite pas des usages et de la viabilité. Aussi bon nombre de recommandations qui émergent sont de découpler d’une part la connaissance métier et les processus et d’autre par les moteurs d’IA afin de pouvoir changer d’infrastructure plus facilement, si celle-ci venait à s’écrouler. L’attention est donc à porter sur la connaissance du contexte, la possession et maîtrise de données, du modèle métier et de modèle de processus, de l’architecture fonctionnelle et technique plutôt que du moteur d’exécution ou de génération de code.

• Une notification du jour qui m’a été poussée par Perplexity (suite à cette conversation) sur les nouvelles découvertes en Astronomie