Une entreprise où l'IA écrit le code et le contenu
Ce qui marche vraiment quand ce sont des agents IA qui font le travail. Et là où ça coince encore.
Dans mon environnement, aujourd'hui l'IA écrit vraiment le code et le contenu. Pas comme une démo de conférence. En production, chaque jour, sur des choses qui ont des utilisateurs et une deadline.
Ce n'est pas magique. C'est un outil avec des règles. Et la plupart des gens ne connaissent pas ces règles, alors soit ça ne marche pas pour eux, soit ils y croient aveuglément. Les deux sont faux.
À quoi ça ressemble en pratique
Je ne dicte pas les étapes à l'IA. Je dicte le résultat. Je dis ce qui doit apparaître et comment je reconnaîtrai que c'est fini. L'agent se fait un plan, touche aux fichiers, lance des commandes, tombe sur une erreur et se corrige tout seul. Pendant ce temps, je tiens le cap et je contrôle le résultat.
Pour le contenu, ça marche pareil. Je n'écris pas le prompt "écris un article". Je donne un rôle, un contexte, une tâche, un format et des critères de qualité. La différence entre une phrase et cinq lignes, c'est la différence entre du remplissage générique et un texte qui part directement.
Un agent n'est pas un miracle, c'est un outil avec des règles
Quand vous donnez à un agent un grand objectif sans limites, il livre quelque chose qui a l'air fini et ne l'est pas. Les développeurs disent que l'IA cache ses jouets sous le lit. Ça a l'air rangé, jusqu'à ce que vous regardiez sous le lit.
C'est pourquoi je calibre la taille de l'objectif selon la confiance et le risque. Faible confiance et fort impact de l'erreur veulent dire un objectif plus petit et une laisse plus courte. Forte confiance et faible risque veulent dire que je le lâche pour longtemps. Ce n'est pas un choix binaire entre micromanagement et foi aveugle. C'est une calibration.
Une porte honnête, sinon ça ne marche pas
La chose la plus importante de tout le setup n'est pas le modèle. C'est une porte capable de tomber. Pour le code, c'est un test, un linter, une exécution réelle. Pas un second modèle qui lit le code et dit "ça a l'air bon". Celui-là n'a pas lancé le code.
J'ai une règle : c'est fini seulement quand une vraie porte passe. Pas quand le modèle acquiesce. Pas quand ça a l'air bon à l'écran. Quand un test capable de dire non passe.
Une boucle n'est honnête que dans la mesure où sa porte l'est. Si la porte ne tombe jamais, ce n'est pas une porte, c'est un tampon.
La vérification avant la confiance
Comme couche de contrôle peu coûteuse, je fais une revue cross-model. Un modèle termine, un second, avec un contexte neuf, le vérifie et cherche les faiblesses que le premier a manquées. Ça attrape le raisonnement et les exigences manquantes, vite et pour pas cher.
Mais pour les choses qui peuvent vraiment casser la production, ça ne suffit pas. Là, il faut une exécution réelle. La profondeur de la vérification suit l'impact de l'erreur. Un faible risque se règle par une revue d'un second modèle. Un fort risque demande une exécution.
Ce qu'il faut en retenir
Les agents IA font aujourd'hui un vrai travail. Pas parce que le modèle est intelligent, mais parce qu'autour de lui se tient un environnement : un résultat clairement défini, une porte honnête et une vérification proportionnée au risque.
Qui construit cet environnement accélère avec l'IA. Qui ouvre juste un chat et espère obtient un texte qui a l'air malin et ne mène nulle part. La différence n'est pas dans l'outil. Elle est dans la façon dont vous le branchez.