Pourquoi les usines logicielles échouent

ou : le harnais ne suffit pas

Mise à jour – la version talk de cet article est disponible sur YouTube : https://www.youtube.com/watch?v=Ib5GBkD555M

On dirait bien qu'on fait des boucles maintenant

Nous sommes tous en concurrence pour mettre le codage IA en production. On a beaucoup parlé d'ingénierie des boucles, et la sagesse populaire veut qu'on devrait probablement écrire plus de boucles.

StrongDM a écrit sur son usine logicielle sans intervention humaine où aucun humain ne lit le code et aucun humain n'écrit le code.

Le récit se résume à peu près à ceci :

1. Vous êtes le goulot d'étranglement.
2. Les modèles sont assez bons.
3. Le code est gratuit.
4. Il suffit de livrer plus de choses.

Ryan Lopopolo d'OpenAI a écrit à ce sujet en février et a donné une conférence en avril sur l'usine logicielle d'OpenAI, Symphony.

Ces gens sont tous vraiment très intelligents et j'ai énormément de respect pour eux. Mais l'interprétation la plus cynique ici serait de considérer cela comme une excuse de plus pour injecter plus d'argent de VC dans le canon à contenu médiocre.

Eh ben... ça avance

Notre ami Mario s'est levé à l'AI Engineer Europe et nous a suppliés de ralentir – parce que des entreprises qui n'ont aucune raison d'avoir des pannes dues aux bévues d'agents de codage, eh bien... ont des pannes dues aux bévues d'agents de codage.

Comme Matt Pocock l'a dit, les bases de code se dégradent plus vite que jamais auparavant.

Je n'ai pas réussi à trouver de données/résultats définitifs de StrongDM sur le déroulement de cette usine sans intervention humaine. Le bulletin d'information contient quelques mises à jour éparses entre février et juin de cette année. edit – il y a une discussion avec l'équipe sur Hacker News le 23 juillet – on dirait qu'on pourrait avoir une mise à jour plus formelle bientôt !

Les gens de Faros AI ont publié un rapport : depuis que nous2 avons tous adopté ces outils de codage IA en janvier et février, la qualité des revues de pull request a considérablement baissé.

• Plus de commentaires, des commentaires plus longs, et des tonnes de PR fusionnées sans aucune revue.
• Les incidents sont en forte hausse.
• Les bugs par développeur sont en forte hausse.

Ce rapport est plus un signal de corrélation qu'une preuve irréfutable (oui, j'ai choisi ce mot exprès, ne me lancez pas sur la prose de Claude), et tout l'intérêt de cet article est de se méfier des données bâclées, mais ça semble directionnellement valide d'après ce que j'ai vu.

"Vous le tenez mal" (non, ce n'est pas ça)

Beaucoup de gens vous diront que c'est un problème de compétence – que si vous n'obtenez pas de bons résultats, c'est de votre faute.

Mais quelle que soit la façon dont vous choisissez de... euh... le tenir, je vous garantis qu'on vous dit que si la maximisation des tokens ne fonctionne pas pour vous, c'est un problème de compétence. Il vous suffit de dépenser plus de tokens. Lâchez prise sur la lecture du code. Et si vous commencez tout juste, je vous promets que ça fait partie de la progression. Je pensais comme ça l'été dernier aussi.

Malheureusement pour mon ego, des bêtises que j'ai décidé de dire sur "comment mieux le tenir" ont été enregistrées et totalisent maintenant environ un million de vues sur YouTube. Je n'essaie pas de me vanter ici, je partage cela uniquement pour établir que j'explore en profondeur les meilleures façons d'utiliser les agents de codage depuis très longtemps maintenant, et que j'ai découvert certaines choses que beaucoup d'autres ont trouvées vraiment utiles.

• Advanced Context Engineering for Coding Agents
• No Vibes Allowed – Solving Hard Problems in Complex Codebases
• Everything We Got Wrong About RPI

Bref, La promesse de tout ce bavardage en ligne "utilisez juste plus de tokens" qu'on a dû endurer est, succinctement : avec suffisamment d'ingénierie du harnais, on peut obtenir le meilleur des deux mondes :

• 10 à 100 fois plus rapide,
• haute qualité, et
• personne n'a jamais à faire cette chose que nous détestons tous appelée revue de code

Tout ce que nous avons à faire, c'est configurer plus de linters et saupoudrer quelques mots magiques comme "revue antagoniste" sur suffisamment de bots de revue de PR, et notre logiciel se construira joyeusement tout seul sans incident.

Ce n'est pas un problème de compétence

Ce que je vais essayer de vous convaincre, c'est qu'aucune quantité d'ingénierie du harnais ou de maximisation des boucles ne peut résoudre ce qui est fondamentalement un problème d'entraînement de modèle.

Pour comprendre cela, j'ai dû creuser la façon dont les modèles de codage sont réellement entraînés et évalués – à la fois du côté RLVR et du côté des benchmarks.

Dans cet article, je vais passer en revue :

1. Les usines logicielles remontent à 1968, comment ont-elles évolué, et comment l'IA les a-t-elle changées ?
2. Pourquoi les modèles peuvent générer des montagnes de contenu médiocre malgré d'excellents résultats aux benchmarks (même les tout nouveaux benchmarks "frontière")
3. Malgré cela, vous pouvez avancer assez vite sans mettre le feu à votre base de code

Je vais essayer de couper à travers le battage médiatique de chaque nouveau plugin de compétences qui émerge quotidiennement et la pandémie de conseils de psychose IA et de maximisation des tokens, et parler en termes généraux des types de choses qui fonctionnent sans faire référence à une compétence ou un cadre particulier.

Version vidéo : cet article est basé sur (et développe) mon keynote à l'AI Engineer World's Fair 2026.

Merci à @addyosmani, @CyrusNewDay, @HamelHusain, @zeeg, @dillon_mulroy, @nayshins, et @jeffreyhuber pour leurs retours sur cet article.

Une parenthèse : ça n'a rien à voir avec le vibe coding

Addy Osmani a démêlé cette chose qui mérite d'être soulignée :

Un développeur qui fait du vibe coding sur un projet secondaire qu'une douzaine de personnes utiliseront un jour, et une équipe qui maintient un système d'entreprise vieux de dix ans pour un trimestre de plus, ne partagent presque aucune contrainte digne d'être mentionnée, et la plupart des conseils en circulation sont en fait l'un de ces deux personas qui dicte à l'autre comment vivre.

Si vous aimez le vibe coding, s'il vous plaît, continuez à vibrer. Je fais encore beaucoup de vibe coding pour plein de choses, mais je maintiens aussi beaucoup de logiciels en production (et via HumanLayer, j'aide des milliers d'autres ingénieurs à faire de même), donc le reste de cet article s'adresse aux personnes qui résolvent des problèmes difficiles dans des bases de code complexes.

J'entends souvent le mot brownfield pour parler de cette scission. Historiquement, cela désignait un truc Java vieux de dix ans, mais au rythme auquel on peut livrer maintenant, on a l'impression qu'une base de code construite par un agent commence à montrer des signes de faiblesse après peut-être trois à six mois – on commence à ralentir, et la façon d'aborder l'ajout de nouvelles choses doit changer.

Une brève histoire de l'usine logicielle

J'ai construit et étudié des usines logicielles toute ma carrière, mais je ne l'ai appris que récemment : le terme remonte à une conférence de l'OTAN en 1968 – la même qui nous a donné le "génie logiciel".

Le seul autre élément que je trouve super intéressant depuis lors est que le Département de la Défense des États-Unis a écrit un PDF de 31 pages sur la façon dont le DoD doit commencer à mieux utiliser Jenkins ou quelque chose comme ça.

L'usine logicielle de 2022

Définissons notre "usine logicielle" autour de 2022, juste avant l'IA. Dans une usine logicielle typique :

• Les gens décident quoi construire – ingénieurs, chefs de produit, direction qui pilote la vision
• Ça va dans un tracker – Linear, Jira, peu importe : une machine à états de ce qui doit se passer
• Quelqu'un attrape un ticket et le construit – fait probablement quelques tests manuels/automatisés en même temps
• Pull request – vérifications automatisées, un humain révise le code, peut-être que quelqu'un le télécharge pour le tester
• Quelque chose ne va pas ? Retour en arrière vers "quelqu'un construit la chose"
• Livraison en prod – et ça entre en contact avec les utilisateurs
• Ajout de la surveillance – il existe toute une industrie construite autour du fait de réveiller un ingénieur à 3h du matin quand quelque chose casse
• Les utilisateurs se plaignent – demandent des choses, trouvent des bugs, soumettent des demandes de fonctionnalités → retour à l'équipe pour ajouter au tracker

Et ainsi de suite. On n'a même pas encore abordé l'IA, et il y a déjà plusieurs boucles dans cette image.

Aligner en amont

Il y a une chose que les équipes ont comprise il y a des décennies : construire prend des heures ou des jours, et la revue aussi.

Donc on charge le travail en amont – la planification, les propositions d'architecture, la planification de sprint – ensemble, en équipe. Cela signifie :

• moins de rework, parce qu'on s'est alignés avant que quiconque n'écrive du code
• moins de temps à relire chaque ligne, si vous avez déjà lu une PR longue mais bien faite, vous savez à quelle vitesse la revue va quand c'est presque parfait

Nous reviendrons là-dessus plus tard – regardons ce qui se passe quand on introduit le codage agentique dans l'équation.

L'usine logicielle agentique

Maintenant, chaque entreprise et sa mère –

• Ramp
• Stripe
• WorkOS
• Brex

a passé le plus clair de cette année à expliquer comment elle a construit une usine à agents qui livre de l'ordre de 75% de son code.

L'usine agentique ressemble principalement à un remplacement de "quelqu'un construit la chose" → "un agent construit la chose" – il y a des trucs comme l'orchestration, un harnais, un bac à sable, un modèle, l'utilisation de l'ordinateur, etc. Je ne vais pas entrer dans les détails là-dessus car franchement, j'en ai marre d'en lire et je suis sûr que vous aussi.

Quand l'agent construit la chose :

• La construction passe de quelques heures ou jours à quelques minutes ou heures.
• La revue prend toujours des heures ou des jours. Un humain doit encore lire le code et tester le changement. La revue est donc maintenant le goulot d'étranglement.

Alors vous accélérez aussi la revue :

• Revue de code agentique, pour détecter le style, les bugs, la sécurité.
• Tests de régression agentiques, pour le sonder de l'extérieur avec des navigateurs et l'utilisation de l'ordinateur, et peut-être vous envoyer une jolie petite vidéo quand c'est fini

La revue est plus rapide maintenant, mais c'est probablement toujours le goulot d'étranglement. Mais on peut faire plus de boucles.

Ensuite, vous pouvez peut-être acheminer les incidents dans l'usine. Au lieu de réveiller quelqu'un à 3h du matin, il se réveille avec une PR qui le résout peut-être déjà.

On peut aussi acheminer les retours des utilisateurs dans l'usine. Les gens demandent des choses, ça se construit.

À ce stade, le travail se résume à deux questions : combien pouvez-vous mettre dans la file d'attente, et à quelle vitesse pouvez-vous revoir et tester ce qui en sort ?

Ce qui nous amène à l'usine logicielle sans intervention humaine.

L'usine logicielle sans intervention humaine

Dan Shapiro a inventé ce terme et Simon Willison a écrit sur l'implémentation de StrongDM – où on ne lit plus le code.

Vous regardez votre belle usine logicielle. Elle est gâchée par cette fichue étape de revue de code et vous vous dites : vous savez quoi, cette histoire où un humain lit chaque changement ? Non merci.

Alors vous l'abandonnez, et vous mettez l'effort ailleurs :

• Investir dans les tests et laisser l'agent tester son propre travail
• Investir dans les bacs à sable et l'orchestration
• Investir dans la revue automatisée
• Investir dans la surveillance
• Investir dans le déploiement
• Investir dans la collecte de signaux de feedback des utilisateurs

Et maintenant, le travail se résume vraiment à une seule question : combien de choses peut-on demander à l'agent de construire ? Quelle part de l'océan voulons-nous faire bouillir ?

Ça va très bien se passer (non, pas du tout)

Je vais avancer quelque chose de potentiellement controversé : l'usine sans intervention humaine ne fonctionne pas.

Voyons pourquoi les usines logicielles échouent.

On a essayé

En juillet 2025, nous sommes passés en mode sans intervention humaine. Juste lire les specs et les tickets, des agents en arrière-plan pour tous les trucs petits/moyens, le package complet.

Si vous avez essayé ça sérieusement pendant quelques mois, vous savez déjà comment ça se termine. Vous trouvez au moins un problème suffisament coriace que l'agent ne peut pas résoudre – même avec votre prompting et vos workflows les plus avancés.

• Vous faites des recherches approfondies, conscientes du contexte, en rassemblant toutes les bonnes parties dans la zone intelligente pour que le modèle les analyse
• Vous faites essayer à l'agent de reproduire le problème de 10 façons différentes

Finalement, vous devez vous résigner et aller fouiller dans la base de code que vous avez arrêté de lire il y a trois mois, en essayant de comprendre ce qui est cassé.

Et pendant ce temps-là :

• Votre site était en panne.
• Vos utilisateurs étaient furieux.
• Et vous, si vous êtes comme moi, étiez misérable – à lire tout le code bâclé que vous avez laissé s'infiltrer dans votre système.

La première fois que ça nous est arrivé, je l'ai relativisé. Même si je venais de passer quasiment deux semaines à fouiller dans des spaghettis de Claude, "le risque de downside valait la vélocité". Vers la ~troisième fois en novembre, nous avons décidé qu'il serait plus facile de réécrire à partir de zéro, et mon co-fondateur a passé deux semaines entières dans VS Code (pas même Cursor) à câbler tous les patterns à la main.

Les modèles dégradent la qualité de la base de code avec le temps

Ce à quoi je veux en venir, c'est ceci : les modèles ont une lacune. Ils ne peuvent pas maintenir et améliorer la qualité de la base de code au fil du temps – pas sans un bon niveau de pilotage humain.4

Quand je parle de maintenabilité, je veux dire cette chose spécifique où il devient vraiment, vraiment difficile de modifier une partie de la base de code sans en casser une autre. C'est ce que Martin Fowler appelle la chirurgie au fusil de chasse.

Je ne vais pas en dire beaucoup plus sur la maintenabilité. Il y a un tas de livres que vous pouvez aller lire à ce sujet

• John Ousterhout's A Philosophy of Software Design
• Robert C. Martin's Clean Code
• Martin Fowler's Refactoring

Alors, pourquoi les modèles ne peuvent-ils pas faire de la maintenabilité logicielle ?

"Mais les modèles se sont sûrement améliorés depuis"

À ce stade, vous mourez peut-être d'envie de dire : mais Dex, les modèles se sont sûrement beaucoup améliorés depuis juillet

Ils se sont améliorés – à certains égards. À d'autres, ils sont à peu près les mêmes.

• Résoudre des problèmes ponctuels, ou faire du vibe coding pour un nouveau site marketing ? Oui. Beaucoup mieux.
• Améliorer la qualité de la base de code au fil du temps ? Pas beaucoup mieux, d'après ce que je peux dire.

Je ne peux pas le prouver. Vous non plus. Il n'existe pas de bons benchmarks pour la capacité d'un modèle à maintenir la qualité d'une base de code. (Plus sur où cela va plus tard.)

IL N'EXISTE PAS DE BONS BENCHMARKS pour la capacité d'un modèle à maintenir la qualité d'une base de code

Mais si vous avez travaillé avec des agents de codage pendant un certain temps – et beaucoup de gens publient exactement à ce sujet – vous avez probablement déjà cette sensation : ils ont tendance à empirer les choses avec le temps, et à rendre la base de code plus difficile à utiliser.

Alors, pour comprendre pourquoi cela se produit, je veux prendre du recul sur le premier grand agent de codage.

Claude Code a gagné grâce à l'apprentissage par renforcement dans le harnais

Claude Code est passé de rien à environ 4 milliards de dollars – maintenant quelque chose comme 9 milliards de dollars – de revenus en moins d'un an.

Ce qui est un peu fou, parce qu'il y avait déjà d'excellents agents CLI. aider, cline, codebuff – tous ont précédé Claude Code, tous avec une ingénierie de contexte vraiment géniale intégrée, tous avec le même ensemble d'outils que vous pourriez attribuer à Claude Code : lire, écrire, éditer, grep, bash. Je les ai utilisés. Ils étaient bons. Mais aussi, l'utilisation des outils échouait parfois... vous les regardiez lutter sur la même modification trois fois avant de rouvrir votre éditeur pour le faire vous-même.

L'article SWE-Agent de 2024 explique comment de petits changements dans la forme des outils font des différences notables, par exemple inclure les numéros de ligne dans les résultats de ReadFile, ou changer un outil d'édition de recherche/remplacement à des modifications par plage de lignes.

Puis Claude Code a été lancé et a rapidement décollé. On peut attribuer cela à la distribution, mais l'explication canoniquement acceptée est que Claude Code a gagné parce qu'il était meilleur, et qu'il était meilleur parce qu'Anthropic a entraîné le modèle par RL à l'intérieur du harnais – la première fois qu'un laboratoire a entraîné un modèle contre les outils exacts avec lesquels il allait le livrer. Et il est devenu vraiment, vraiment bon pour appeler ces outils dans une boucle agentique.

C'est une chose de bricoler les définitions d'outils et les évaluations jusqu'à trouver la forme que le modèle préfère – j'ai passé des semaines à faire ça pour divers cas d'utilisation. C'est un jeu différent quand on possède les poids et qu'on peut modifier le modèle lui-même pour qu'il soit meilleur avec un ensemble particulier d'outils.

L'équipe d'OpenAI a donné une conférence en novembre qui a assez bien résumé cela : si vous construisez un harnais mais que vous ne possédez pas les poids et que vous ne pouvez pas entraîner le modèle par RL à l'intérieur, vous serez toujours désavantagé par rapport à une équipe qui possède les deux.

RL pour agent de codage en 60 secondes

J'ai fait pas mal de recherches sur ce sujet et j'ai concocté un tas de visualisations pour essayer d'expliquer les parties qui comptent, mais j'ai découvert que Calvin French-Owen (MTS dans l'équipe Codex, fondateur de Segment) a fait une présentation à AI Council qui a fait un bien meilleur et plus propre travail, donc je vais juste déposer cette animation ici inspirée de ses slides :

Pour rendre un modèle meilleur en codage, vous allez :

1. générer quelques traces d'agent de codage pour résoudre un problème (par ex. corriger mes tests)
2. noter les traces en fonction de certains critères (vérificateur)
3. mettre à jour les poids du modèle pour rendre les bonnes traces plus probables, et les mauvaises traces moins probables

Et ensuite, vous faites cela des millions de fois sur des semaines ou des mois.

La partie "notation" de ces choses a tendance à être capricieusement unidimensionnelle cependant.

Il n'y a pas de pénalité pour une mauvaise conception

Prenez SWE-bench Multilingual. Les tâches sont petites – environ quinze minutes de travail chacune – extraites de dépôts open source comme Redis, jq, et Django. La récompense est un ou zéro basé sur :

• FAIL_TO_PASS – avez-vous corrigé ce qu'on vous a demandé de corriger ?
• PASS_TO_PASS – l'avez-vous fait sans rien casser d'autre ?

En voici une vraie, fastlane__fastlane-19304, de fastlane – un projet Ruby. Son action zip récupère deux paramètres optionnels et appelle .empty? dessus directement, donc dès qu'on omet include et exclude, ça plante :

Le correctif humain qui a résolu ce problème particulier fait deux lignes (mettre des tableaux vides par défaut pour les nils) :

Pendant l'évaluation, le modèle

1. part d'un commit de base – le dépôt extrait au moment juste avant que ce correctif ne soit intégré
2. le rapport de bug – dans ce cas 'zip_command': undefined method 'empty?' for nil:NilClass

L'agent part et écrit du code basé sur le problème. Il ne voit pas le correctif de référence ni le correctif de test qui sert de correcteur :

Ensuite :

1. On garde le correctif qu'il a produit, puis
2. On jette toutes les modifications qu'il a apportées aux fichiers de test (on a déjà attrapé un modèle en train de commenter silencieusement le test défaillant ou d'intégrer un mock qui rend le test inutile)
3. On applique le correctif de test du benchmark par-dessus, et
4. On exécute toute la suite : les tests zip existants (PASS_TO_PASS) plus le nouveau (FAIL_TO_PASS) pour voir s'ils passent tous les deux

Parenthèse – Les benchmarks ne sont pas des vérificateurs – en fait, ils doivent être tenus à l'écart les uns des autres (ne vous entraînez pas sur le test, etc.) – je veux surtout dire par là la forme de "juger la qualité d'une trace d'agent de codage" et ses limites.

La façon dont le modèle est arrivé à une réponse correcte n'a pas d'importance. Si les tests passent, on gagne, mais il n'y a aucune pénalité pour l'érosion de la maintenabilité de la base de code.

il n'y a aucune pénalité pour l'érosion de la maintenabilité de la base de code

C'est comme ça qu'on obtient des try/catch autour de tout :

Vérifier la qualité est des ordres de grandeur plus difficile que "les tests ont-ils réussi"

Exécuter les tests vous donne un résultat clair de succès ou d'échec en ~secondes. C'est pourquoi le RL peut exécuter des millions de boucles pour optimiser chaque génération de modèle.

Mais la fonction de coût d'une mauvaise architecture se mesure en semaines, mois, voire années. Elle se produit la première fois que quelqu'un ouvre ce fichier pour un changement d'une ligne et se rend compte qu'il ne peut pas le faire en une ligne – que quelqu'un a un peu trop vibré, et maintenant nous devons faire la même modification à onze endroits et espérer que rien ne casse silencieusement trois fichiers plus loin.

Les tests vous donnent un retour en quelques secondes, mais la fonction de coût d'une mauvaise architecture se mesure en semaines, mois, voire années

La mauvaise conception est la seule chose que les benchmarks d'aujourd'hui ne peuvent pas évaluer. Et je sais, je sais, RL != Benchmarks, mais si c'était résolu dans le RL, je suis à peu près sûr que cela commencerait à se refléter aussi dans la conception de nos benchmarks.

En tout cas, personnellement, je ne fais confiance à aucune amélioration sur les benchmarks d'aujourd'hui comme indicateur que les modèles sont soudainement bons pour ne pas bâcler votre base de code.

La frontière s'améliore, lentement

Bien sûr, beaucoup de gens intelligents travaillent là-dessus. Mon point n'est pas que c'est impossible, c'est que le battage médiatique dépasse la discipline.

Quelques efforts que je pense être orientés dans la bonne direction :

• SWE-Marathon (Abundant AI) : tâches d'environ 400 heures comme "cloner tout Excel, chaque fonctionnalité" – avec un canal de récompense composé au lieu d'un simple bit succès/échec
• DeepSWE (Datacurve) : grandes tâches sur des dépôts OSS qui n'ont jamais été réellement construites dans le monde réel, donc par construction elles ne peuvent pas déjà se trouver dans l'ensemble d'entraînement (résout la contamination, mais pas la qualité)
• Frontier Code (Cognition) : tâches multi-PR, et une astuce intelligente qui évalue la qualité de manière déterministe – elle pénalise le modèle pour avoir écrit des tests qui n'échouent pas sur le code d'avant le correctif (si vous n'avez jamais entendu parler des tests de mutation, vous allez vous régaler5). Elle exécute également un modèle juge sur le diff pour vérifier les règles de qualité du code.

Mais un modèle qui juge la qualité ne peut aller que jusqu'à un certain point.

En fait, il n'est pas difficile d'imaginer que si un modèle pouvait distinguer de manière fiable le bon code du mauvais, il aurait peut-être écrit la bonne version dès le départ. Le RL a besoin d'un oracle rapide et fiable, et nous n'en avons pas encore pour la maintenabilité.

si un modèle pouvait distinguer de manière fiable le bon code du mauvais, il aurait peut-être écrit la bonne version dès le départ, mais la maintenabilité n'a pas d'oracle rapide, donc nous ne pouvons pas la récompenser pendant le RL.

Bien sûr, plus d'agents de révision et plus de tokens aident -- ils relèvent le niveau plancher, en attrapant les bêtises.

Mais ils ne déplacent pas le plafond, car le plafond est ce que nous avons réussi à enseigner au modèle en RL, et le bon design est ce que nous ne savons toujours pas lui apprendre.

Donc, je ne parierais toujours pas ma base de code sur l'un d'eux. Mais ce sont les premières évaluations que j'ai vues qui essaient même de noter la maintenabilité au lieu de s'arrêter à succès/échec.

En aparté Peut-être qu'un futur modèle comprendra cela et nous pourrons arrêter. Si vous voulez lancer des prompts à l'aveuglette jusqu'à ce que GPT-7 sorte et voir ce qui se passe, faites-vous plaisir -- mais que la leçon amère aille au diable, nous avons des problèmes à résoudre maintenant, et je vais vous expliquer comment nous faisons.

Rallumer les lumières

Aujourd'hui, j'ai appris que les articles Twitter ont une "limite de médias", ce qui signifie que le reste de ceci va dans un article de la deuxième partie - restez à l'écoute.