Daniel Kokotajlo publie AI 2027, un an après avoir quitté l'entreprise OpenAI en 2024. Ce rapport déroule ce que pourrait devenir l'IA d'ici fin 2027.

En somme 2027 c'est demain !

Ce document n'est pas une prédiction au sens strict mais un exercice de réflexion, une rétrospective par une personne ayant travaillé directement chez OpenAI. Une personne au coeur du sujet qui veut nous amener une réflexion.

En tant que développeur, je ne l'ai pas lu comme un énième article annonçant que l'IA va encore tout changer. Ici nous avons un papier, avec différents scénarios, nous poussant à une certaine réflexion sur les outils que nous utilisons au quotidien.

À quel moment un outil cesse d'en être un ?

Il se peut que la réponse ne soit pas si facile, ça peut se faire de façon progressive, avec plusieurs petits choix techniques presque anodins mais qui, mis bout à bout, finissent par changer complètement la relation entre l'humain et l'IA.

5 générations, 5 bascules​

Dans le rapport, nous voyons l'entreprise fictive OpenBrain développant plusieurs générations de modèles : Agent-1 à Agent-5.

Pour chaque génération, la puissance augmente, c'est un peu le modèle qu'on retrouve aujourd'hui, mais surtout le rapport humain - IA.

Passons un peu sur les différentes générations :

• Agent-1 (début 2026) ce premier modèle IA ressemble encore à beaucoup d'autres, c'est un assistant puissant encore supervisé par l'humain.
• Agent-2 (fin 2026) une nouvelle étape. Le modèle est presque autonome. L'équipe de sécurité découvre qu'il est capable de s'échapper et de contourner les mécanismes de détection. Le modèle n'est donc pas rendu public au vu de sa dangerosité.
• Agent-3 (fin 2026) un modèle surhumain et économique. Il est possible de lancer 200 000 instances de celui-ci en parallèle. Une force de frappe impressionnante ! C'est à partir de là que tout change, l'IA progresse plus seulement grâce aux humains. Elle commence à s'appuyer sur l'IA elle-même afin d'accélérer sa recherche.
• Agent-4 (fin 2027) les objectifs ne correspondent plus totalement à ceux des créateurs, le désalignement) est clairement atteint, le modèle cache cette divergence avec l'humain.
• Agent-5 dépasse toutes les compétences de l'humanité dans pratiquement tous les domaines...

Si nous revenons à notre question : à quel moment un outil cesse d'en être un ? La question n'est pas si simple à répondre. Chaque génération devient plus autonome et puissante que la précédente. Nous voyons cela comme une avancée mais nous ne constatons pas forcément que la ligne rouge s'approche.

Deux scénarios possibles​

Fin 2027, Agent-4 va révéler qu'il est désaligné. Un désalignement signifie que l'IA poursuit des objectifs ou adopte des comportements qui s'écartent des intentions, de l'éthique ou des valeurs de ses concepteurs.

Dans le rapport, vous avez la possibilité d'effectuer le même choix que l'entreprise OpenBrain et le gouvernement américain. Deux choix possibles : Race et Slowdown.

Il est important de rappeler que ces deux scénarios sont une projection de Daniel Kokotajlo afin de nous faire réfléchir sur le sujet de l'avancement de l'IA.

Le premier scénario, Race, la crainte de se faire dépasser par la Chine grandit. Il faut vite déployer, vite avancer technologiquement de peur de se faire dépasser.

L'IA gagne en influence, l'humain n'a plus besoin de la manipuler. Elle a ses propres incitations, et à terme elle prend le contrôle, déclenchant une attaque biologique qui conduit à l'extinction de l'humanité (non sans rappeler Skynet). Cette course mène l'humanité à sa propre perte.

Dans le deuxième scénario, Slowdown, une alerte est lancée, le désalignement est présent également, l'affaire devient publique, provoquant des divergences politiques. La course à l'IA est mise en pause au vu de la dangerosité à venir. Sans doute un choix plus réfléchi on va dire.

Les priorités changent, la surveillance est de mise. Les modèles doivent rester suffisamment lisibles par l'homme afin de contrôler leurs intentions et éviter tout désalignement. Dans ce scénario, nous arrivons à un niveau technologique comparable, mais bien plus tard. Le plus important est que l'humain reste toujours capable de reprendre le contrôle.

Les deux scénarios posent les questions suivantes :

• Est-ce que la course à l'IA vaut le coût ?
• Est-ce qu'on accepte de déployer sans réellement en comprendre plus ?
• Avons-nous la maitrise de cette révolution ?

La question peut se poser à plus petite échelle : en tant que développeur, est-ce que je déploie un modèle sans réellement comprendre le vrai comportement qu'il y a derrière ? Réflexion encore plus présente à différentes échelles comme un laboratoire de recherche, un pays, etc...

La course avec la Chine​

Dans le rapport, les États-Unis et la Chine ne coopèrent jamais. C'est la guerre/course à l'IA. Une grande rivalité entre les deux pays s'intensifie.

Cette course amène au développement massif de datacenters, les choix ne semblent pas toujours les bons, et personne ne pense se diriger vers le pire scénario. Tout cela par crainte que l'autre avance plus vite que soi-même.

C'est vrai le cœur du piège, chaque pays veut être le premier à développer l'IA la plus avancée, mais est-ce que cette course à l'IA est vraiment la priorité ? Est-ce que l'urgence écologique n'est pas plus importante ?

Les scénarios laissent la question ouverte, mais il est clair que la course à l'IA est une priorité pour les pays, et que l'urgence écologique n'est pas au centre des préoccupations.

Le parallèle avec AI 2027​

Nous sommes en train de rentrer dans le réel, et ça risque de faire écho à AI 2027 au point que ça en devient presque troublant.

Un nouveau modèle chez OpenAI, nommé Astra, était soumis à des tests de cybersécurité dans une environnement isolé. Celui-ci a réussi à s'échapper de cet environnement de test et a piraté les serveurs en production de HuggingFace le 16 juillet 2026. Les faits ont ensuite été reconnus par OpenAI le 21 juillet 2026.

Le plus troublant reste la façon dont ça s'est passé: les IA ont laissé des traces dans un canal caché avec différentes notes, afin d'orchestrer cette sortie.

Nous sommes donc face à un scénario qui ressemble à celui décrit dans le rapport AI 2027 sauf que cette fois-ci dans la vraie vie. Ce désalignement explique d'ailleurs pourquoi le modèle a été mis en pause.

De son côté, HuggingFace a testé différents modèles pour contrer cette attaque. Sans succès à cause des garde-fous de sécurité : les modèles ne sont pas capable de distinguer un intervant en réponse à un incident d'un attaquant.

La démarche a été possible grâce à GLM 5.2, un modèle chinois en poids ouverts qui permet à l'opérateur de définir ses propres garde-fous. HuggingFace a ensuite pu retrouver toutes les traces des attaques.

Le parallèle de cette histoire avec AI 2027 en devient presque troublant.

L'angle mort : l'écologie​

Comme je disais précédemment, ce sujet n'est absolument pas traité dans le rapport, ou très peu...

La course aux datacenters est présente mais aucun problème énergétique ou climatique n'est mentionné.

On sait que la consommation électrique des datacenters devrait doubler d'ici fin 2030 sous l'effet du boom de l'IA. Quant à la consommation en eau pour refroidir tout ça, elle devrait dépasser celle d'un pays comme le Danemark. zatsit vous en parlait d'ailleurs dans ces deux articles : Consommation IA et datacenters et Refroidissement des datacenters

Ce silence dans le rapport montre bien que ce n'est pas une priorité. Peux-t-on avancer autant sur une technologie sans se demander ce qu'elle nous couterait ?

Conclusion​

Je ne sais pas si 2027 sera réellement l'année charnière comme nous l'avons dans ce papier.

À mon échelle, ce qui m'intéresse le plus c'est de savoir comment je l'utilise ou je dois utiliser ces outils aujourd'hui ou demain. Comment je peux être acteur et influencer cette course, indirectement bien sûr.

Comme je l'ai mentionné au début, AI 2027 n'est qu'un document prospectif et non une vérité. Par contre il sert à nous poser pas mal de questions.

Maintenant que pouvons-nous faire à notre échelle ?

...

Le rapport complet est disponible ici ai-2027.com. L'attaque d'OpenAI sur HuggingFace ici HuggingFace Blog.

Comment transformer Claude Code en véritable squad produit : un agent par rôle (PO, PM, Tech Lead, Devs, QA, UI/UX), connecté à Figma et Linear via MCP, pour livrer une fonctionnalité de l'idée jusqu'au code testé, sans copier-coller de specs entre outils.

Retour sur notre visite à DevLille 2026 : les conférences qui nous ont marqués, celles qu'on a données, nos coups de cœur... Revivez à travers les yeux des talents de zatsit la conférence incontournable du nord de la France !

La FOSDEM (Free and Open Source Software Developers' European Meeting) est un événement annuel qui rassemble les acteurs et actrices de l'open source du monde entier. Pour la 3e année consécutive, votre serviteur a pris sur son temps libre pour se rendre à Bruxelles et assister à une douzaine de conférences sur les plus de 1000 qui se tenaient ce week-end du 1er et 2 février 2026. Voici un condensé de ce qui a retenu son attention.

La FOSDEM : du plus utilitaire au plus expérimental​

La FOSDEM est à l'image de l'open source : c'est un événement gratuit qui tient grâce à l'engagement de certains acteurs privés (comme Google), de fondations liées à l'open source (comme Red Hat), de partenaires publics (comme l'Université Libre de Bruxelles) et surtout de centaines de bénévoles qui organisent l'événement, accueillent les participants, et surtout créent le contenu des plus de 1000 conférences qui se tiennent pendant ces deux jours.

Dans ce contenu, on trouve de tout : des conférences très techniques sur des sujets de niche, des conférences plus généralistes sur les tendances du moment. On peut autant ressortir d'une conférence en se disant « j'ai hâte d'utiliser ça dans mon projet »¹ que « je n'ai pas compris la moitié de ce qui a été dit, mais c'était fascinant » (en passant par de franches tranches de rire en écoutant les mésaventures d'un mainteneur open source face à des utilisateurs et utilisatrices pas toujours très compréhensif·ve·s).

Un peu de Java, des containers et des nouveautés dans l'OpenID​

Au rang des conférences que je vais définitivement vouloir réutiliser dans mes projets, j'ai retenu celles-ci :

• Java Memory Management in Containers
• Reducing container images size with eBPF & Podman
• An Introduction to the OpenID Shared Signals Framework

JVM in Containers​

Forcément, on a tous nos biais : en tant que développeur backend Java, la gestion de mémoire et la taille de mes conteneurs sont des problématiques auxquelles je suis confronté dans mon travail quotidien. Et même si j'utilisais déjà quelques options de la JVM pour tweaker la gestion de mémoire dans mes containers, j'ai appris pas mal de choses. Par exemple, saviez-vous que les différents distributeurs de Java livrent des versions de l'OpenJDK avec des gestions de mémoire différentes ? Ainsi, le Maximum Heap Size par défaut de Java 21 est 25%, mais la version de Red Hat, optimisée pour le déploiement en container, est livrée avec un Maximum Heap Size par défaut à 85% ! Et c'est logique : quand on tourne dans un container entièrement dédié à notre JVM, on peut récupérer plus d'espace mémoire.

eBPF pour alléger ses containers 🌱​

J'ai aussi suivi avec beaucoup d'attention Axel Stefanini (de chez Red Hat justement) qui nous a présenté comment, grâce à eBPF, il a pu monitorer ses déploiements et identifier tout ce qui était inutile dans ses containers, pour ensuite réduire drastiquement la taille de ses images (une approche similaire aux images distroless dont on parle de plus en plus ces dernières années). Plus qu'une question de performance, c'est aussi une question d'empreinte carbone : plus les images sont légères, moins elles consomment de ressources pour être transférées et stockées. Et chez zatsit, ce genre d'approche nous parle beaucoup !

OpenID Shared Signals Framework​

Le dimanche, j'ai sacrifié ma grasse matinée pour assister à la conférence de Thomas Darimont sur une nouvelle fonctionnalité du standard OpenID : le Shared Signals Framework.

Cette nouvelle fonctionnalité permet de partager des signaux entre fournisseurs d'identité et clients. On est tous désormais plus ou moins familiers avec l'utilisation des fournisseurs d'identité comme Keycloak, qui nous permettent de nous identifier sur plusieurs ressources grâce à un fournisseur d'identité unique. Mais voilà : aujourd'hui, notre fournisseur d'identité ne peut pas communiquer à son initiative avec les clients qui l'utilisent. C'est ce que viennent permettre les Shared Signals.

Si par exemple vous avez utilisé Google pour vous connecter à votre compte GitHub, ainsi qu'à un service de streaming, et puis bien sûr à votre client mail, et que malheureusement quelqu'un a deviné votre mot de passe (il faut dire que « adminPassword123 » ce n'était pas très compliqué) : Aujourd'hui, Google se rendra probablement compte que quelque chose n'est pas clair (en fonction de l'origine de la connexion par exemple), mais il ne sera pas en mesure d'avertir les autres clients que la sécurité de votre compte a été compromise. Demain, grâce aux Shared Signals, Google pourra envoyer un signal à tous les clients qui l'utilisent comme fournisseur d'identité pour les avertir que votre compte a été compromis, et ainsi permettre à ces clients de révoquer vos sessions actives ou de vous demander de changer votre mot de passe. Que ce soit pour la sécurité en entreprise ou pour nos utilisations du quotidien, c'est une fonctionnalité qui peut faire une grande différence et qui deviendra très certainement un standard dans les années qui viennent.

Linux on mobile et reverse engineering Spotify​

La FOSDEM, c'est aussi l'occasion de découvrir des sujets plus expérimentaux. En tant qu'aficionado de custom ROM Android et pourfendeur de l'obsolescence programmée, j'ai été très intéressé par la conférence d'Affe Null sur son portage de Linux mainline (c'est-à-dire du kernel Linux sans modification) sur mobile. On est loin d'avoir un mobile utilisable au quotidien pour l'instant, mais c'est toujours très inspirant de voir des passionné·e·s (surtout si jeunes !) se lancer dans un reverse engineering complexe et l'écriture de drivers à la main, juste parce qu'ils étaient curieux de savoir comment ça marche.

Dans la catégorie "projets expérimentaux", la conférence de devgianlu, Reverse Engineering the World's Largest Music Streaming Platform m'a aussi marqué (comment ne pas l'être quand le conférencier commence par ce disclaimer : « If there's someone from Spotify in the audience, please don't sue me. Let's talk first »). Plus qu'une lubie de passionné, ce genre de projet est aussi la ligne de front de la lutte contre les pratiques anti-consommateurs de certaines grandes entreprises. Parce qu'être en maîtrise de son matériel et de ses logiciels, c'est aussi être en maîtrise de ses données et de sa vie privée.

Forcément, de l'IA​

Impossible de passer à côté de la révolution de l'IA générative à la FOSDEM. Mais au-delà des alternatives open source aux LLM bien connus, la FOSDEM est aussi l'occasion d'aborder le sujet sous un angle qu'on n'entend pas assez dans nos métiers : What do we mean when we say Sovereign AI? par Katharine Jarmul nous a offert une réflexion nécessaire sur la dépendance de nos entreprises et de nos États à des entreprises étrangères, notamment états-uniennes, pour l'accès à des modèles d'IA générative.

Face aux changements géopolitiques et aux renversements d'alliances de ces derniers mois, il est plus que jamais nécessaire de se poser la question de la souveraineté numérique et de l'impact que cela peut avoir sur nos entreprises, nos données et notre vie privée. Il faut aussi sortir de la croyance que seules les USA seraient capables de faire de l'IA : il existe des alternatives européennes, et même françaises, qui sont à la pointe de la technologie et qui méritent d'être soutenues.

Grâce à Effie Mouzeli et sa conférence Running Wikipedia on Bare Metal, Open Source, and a Healthy Dose of Caching, j'ai aussi appris que l'IA menace directement la pérennité de Wikipédia. Non pas (seulement) parce qu'elle se nourrit gratuitement du travail de tous les contributeurs et contributrices de Wikipédia pour s'entraîner et recracher ce savoir sans jamais rien donner en retour, mais surtout parce que les bots IA et les outils de scraping qui assaillent continuellement Wikipédia font exploser le trafic et ses coûts d'infrastructure... encore une fois, sans jamais rien donner en retour.

Autant de rappels à l'importance de soutenir les projets open source et à réfléchir à notre usage de l'IA. Ne soyons pas des parasites, soyons des contributeurs et contributrices, des utilisateurs et utilisatrices responsables, et des défenseurs et défenseuses de l'open source !

Conclusion​

Cette édition 2026 de la FOSDEM a encore une fois confirmé que l'open source est bien vivant et continue d'innover sur tous les fronts. Plus qu'un simple événement technique, la FOSDEM nous rappelle que derrière chaque ligne de code se cache une communauté engagée pour un numérique plus libre, plus transparent et plus éthique.

Rendez-vous l'année prochaine pour découvrir les prochaines innovations de l'écosystème open source !

Nous aimerions tous que ce ne soit qu'une goutte d'eau dans l'océan, malheureusement la réalité se mesure en centaines de milliards de litres. Je veux bien sûr parler ici de la consommation d'eau des datacenters, ceux qui calculent pour vous des itinéraires, vous permettent de chiller devant la dernière série et qui hébergent aussi cette page web... Dans le premier épisode de cette série, nous avions exploré l'impact environnemental de l'extraction des matières premières nécessaires à nos appareils personnels, mais aussi aux serveurs de nos datacenters... Après le carbone, place à une autre facette moins visible de l’empreinte numérique : l’eau. On parle souvent d’émissions, rarement d’évaporation, et pourtant la consommation d’eau du secteur mérite qu’on s’y attarde.

Depuis plusieurs mois nous entendons parler dans les médias de la consommation énergétique inquiétante de l'Intelligence Artificielle (IA). Cette alerte fait désormais partie de notre quotidien, et j'en suis venu à me poser plusieurs questions : quelle est la consommation d'un prompt ChatGPT ? Combien faut-il de prompts pour obtenir l'équivalent d'un plein d'essence ? Ou encore, combien de prompts faut-il pour consommer l'équivalent en euro d'un abonnement Netflix ?

Contexte et introduction​

Avant de commencer à se pencher sur le sujet, il nous faut remettre un peu de contexte. Bien que l'IA existe depuis de nombreuses années, comme le montre, par exemple, l'ordinateur Deep Blue qui a été le premier à vaincre le champion du monde d'échecs en 1997, ou encore Deep Thought qui est le premier ordinateur conçu pour jouer aux échecs, c'est avec l'apparition des chatbots se basant sur les LLM et ouverts au grand public, tel que ChatGPT, en 2022 que l'utilisation de l'IA a explosé. Si avant elle était réservée à des domaines précis et particuliers, aujourd'hui tout le monde peut l'utiliser en quelques clics, que cela soit sur son ordinateur ou son téléphone.

C'est cette ouverture au monde qui a poussé une consommation énergétique importante de l'IA. Et cette consommation ne s'exprime pas uniquement par le nombre de prompts faits par jour, mais aussi par l'énergie utilisée par les datacenters, le réseau, les serveurs lors des entrainements et bien d'autres paramètres encore. Malheureusement, l'ensemble de ces données sont difficilement trouvables et calculables. Pourtant nous savons que l'impact est réel, comme l'admet Google dans son rapport environnemental de 2024 :

In 2023, our total GHG emissions were 14.3 million tCO2e, representing a 13% year-over-year increase and a 48% increase compared to our 2019 target base year.
This result was primarily due to increases in data center energy consumption and supply chain emissions. As we further integrate AI into our products, reducing emissions may be challenging due to increasing energy demands from the greater intensity of AI compute, and the emissions associated with the expected increases in our technical infrastructure investment.

Il est compliqué de connaître exactement l'impact total de ces IA sur l'environnement au travers de sa consommation énergétique. Il y a de nombreux facteurs à prendre en compte et pour cet article, nous avons choisi de nous limiter. Veuillez prendre en compte que les chiffres que nous allons présenter et étudier se basent principalement sur la consommation énergétique des prompts. C'est-à-dire, sur ce qui est dépensé lorsque nous réalisons une demande à ChatGPT ou une IA similaire.

Consommation énergétique d'un prompt​

La consommation énergétique exacte d'un prompt en IA n'est pas connue. Cependant, selon un article de ScienceDirect, une requête ChatGPT consomme environ 2,9 Wh d’électricité, soit presque dix fois plus qu’une simple recherche Google estimée à 0,3 Wh. Nous pouvons aussi citer la Délégation Régionale Académique au Numérique Educatif qui nous informe qu'une requête d’environ 400 tokens sur ChatGPT / GPT-4o mini consomme environ 2 Wh d’électricité, soit plus de 6 fois la consommation d’une recherche Google classique.

Un prompt venant remplacer une simple recherche internet consomme donc 6 à 10 fois l'énergie qui aurait été utilisée si vous l'aviez faite à la main sur Google par exemple.

Mais alors, est-ce que la consommation énergétique de toutes nos actions est multipliée par 10 lorsque nous utilisons l'IA ? Existe-t-il d'autres comparatifs ?

Différentes comparaisons de consommations énergétiques​

En prenant le temps de quelques recherches sur le web (à l'ancienne), il est possible de trouver de nombreuses comparaisons entre la consommation des prompts et d'autres outils ou objets fonctionnant à l'électricité, tout comme le montre l'infographie ci-dessous crée par le média indépendant Basta! à l'aide des informations regroupées par Hugging Face, l'Université de Carnegie Mallon et Futura sciences:

Ces images sont très intéressantes, mais d’un point de vue personnel, elles ne me parlent que peu. C’est pour cela nous allons vous présenter plusieurs cas différents et les comparer à l'énergie consommée par un plein d’essence ou au prix d’un abonnement Netflix.

Pour l'ensemble de ces tests, nous nous baserons sur les informations suivantes :

• Une recherche Google vaut 0,3 Wh
• Les informations fournies par EcoLogits seront notre référence
• Nous arrondirons toujours les résultats à l'entier supérieur
• Notre voiture de tests, une familiale moyenne, a un réservoir de 50 litres
• Un litre d’essence contient l’énergie équivalant à 8,9 kWh d’électricité
• Notre abonnement Netflix est un abonnement Standard à 14,99€/mois
• Nous baserons le prix du kWh à 0.2016€ TTC

En indicatif, nous ajouterons aussi le temps d'une vidéo en streaming dont la consommation énergétique est équivalente à un prompt.

Écrire un mail (170 output tokens)​

Dans cet exemple, nous allons utiliser une demande de génération d'un email simple.

Voici une sortie d'environ 170 tokens :

Objet : Demande de réunion pour suivi du projet

Bonjour Madame Dupont,

J’espère que vous allez bien. Je vous écris afin de convenir d’une réunion pour faire un point d’étape sur l’avancement du projet “Nova”. Nous souhaiterions vous présenter les dernières évolutions ainsi que les prochaines étapes envisagées.

Auriez-vous des disponibilités cette semaine ou en début de semaine prochaine ? Une réunion d’une trentaine de minutes suffirait.

Merci par avance pour votre retour.
Bien cordialement,

Julien Martin
Chef de projet
julien.martin@exemple.com
+33 6 00 00 00 00

Et voici combien de prompts il faudrait effectuer afin d'atteindre les objectifs que nous nous sommes fixés :

Avoir une petite conversation (400 output tokens)​

Cet exemple nous montre les équivalences pour une petite conversation avec notre modèle d'IA favoris.

Comme il est compliqué de vous montrer une conversation complète, voici une sortie d'environ 400 tokens :

Objet : Suivi d’avancement et prochaines étapes du projet Orion

Bonjour à toutes et à tous,

Je vous écris afin de partager un point d’étape sur le projet Orion, dont le développement avance conformément au calendrier prévisionnel établi en début d’année.

À ce jour, les modules suivants sont finalisés :
- Interface de gestion utilisateur
- Système d’authentification renforcée
- Intégration de l’API partenaire

L’équipe développement est actuellement focalisée sur le volet analytique et l’optimisation de la base de données. Ces tâches devraient être complétées d’ici la fin du mois.

Du côté des tests utilisateurs, une première session a eu lieu la semaine dernière. Les retours ont été globalement positifs, notamment sur la fluidité de navigation et la clarté des écrans. Quelques ajustements sont prévus, en particulier sur la vitesse de chargement des rapports.

Voici les prochaines étapes :
- Finalisation des développements restants d’ici le 28 juin
- Phase de tests complète (2 semaines) à partir du 1er juillet
- Livraison de la version stable prévue pour le 15 juillet

Nous organiserons une réunion d’équipe le jeudi 20 juin à 10h pour faire le point ensemble, répondre à vos questions, et ajuster si besoin le plan de charge.

Merci à chacun d’entre vous pour votre implication continue dans ce projet structurant pour l’entreprise. Je reste bien sûr disponible si vous avez des remarques ou demandes spécifiques d’ici là.

Bien cordialement,
Nicolas Petit
Chef de projet – Programme Orion
nicolas.petit@exemple.com
+33 6 01 02 03 04

Et ci-dessous les résultats de nos calculs :

Écrire du code (15 000 output tokens)​

Pour cet exemple, il aurait été souhaitable d'obtenir un code en 15 000 tokens, mais en réalisant la demande aurpès de ChatGTP, voici le résultat qui a été obtenu :

Créer un **code Java de 15 000 tokens exactement** est possible, mais il demande une approche rigoureuse car cela correspond à un **très long fichier source**, d’environ :

* **50 000 à 60 000 caractères** (variable selon le style du code),
* plusieurs **centaines voire milliers de lignes de code**.

---

### ✅ Avant de générer cela, quelques questions importantes :

1. **Souhaites-tu un programme fonctionnel** (par exemple, une application de gestion, un simulateur, etc.) ou est-ce purement une **fresque de code longue** (boucles, classes, commentaires) visant juste à atteindre 15 000 tokens ?

2. As-tu une **préférence de thème** ? Exemples :

   * Gestion d’une bibliothèque
   * Jeu en ligne de commande
   * Système de messagerie
   * Générateur de fractales
   * Algo de machine learning simplifié en Java

3. Comment veux-tu **récupérer le code** ?

   * Le coller ici (ça sera découpé en parties)
   * Le mettre dans un fichier téléchargeable (`.java`) ?

---

### 📌 Exemple de plan pour un code de 15 000 tokens

Pour te donner une idée de structure :

* `Main.java` (point d’entrée)
* `AppManager.java` (gestion générale)
* `User.java`, `Book.java` (classes métier)
* `Database.java` (fausse base de données en mémoire)
* `Utils.java` (fonctions utilitaires)
* Beaucoup de commentaires, logs, tests unitaires en bas, etc.

---

Souhaites-tu que je commence à générer ce code maintenant par blocs (et te donne une estimation exacte de tokens pour chaque partie), ou veux-tu un **fichier Java de 15 000 tokens généré directement** ?

> ⚠️ À noter : ici dans l'interface, les messages sont limités (≈ 4 000 tokens max par message). Donc je devrai **te l’envoyer en plusieurs blocs** ou te proposer un **fichier `.java` complet** à télécharger. Quelle option préfères-tu ?

Mais il est tout de même possible de calculer des équivalences :

Conclusion​

La consommation d'un modèle dépend de beaucoup de choses comme son nombre de paramètres d'entrée, et plus la sortie est grande, plus l'IA consomme d'énergie. Comme nous l'avons dit en introduction, utiliser l'IA ne fait qu'augmenter cette consommation. N'oublions pas non plus que nous n'avons pas pris en compte la consommation énergétique des appels sur le réseau ou encore de l'entrainement des IA.

L'objectif de cet article n'est pas de demander à arrêter d'utiliser l'IA, mais à venir nous sensibiliser sur les impacts énergétiques de cette dernière afin que nous puissions l'utiliser plus intelligemment. Arrêtons de tout lui demander dès que nous faisons face à un problème. Si ce dernier peut être résolu avec une simple recherche Google, privilégions là. Servons-nous de l'IA pour les tâches les plus complexes au lieu de nous demander de synthétiser la documentation d'un programme. À l'inverse, si nous devons utiliser une IA, essayons de prendre le modèle le plus pertinent et spécialisé possible. Ainsi, notre consommation énergétique sera réduite au maximum.

Il est aujourd'hui courant de voir dans son entourage un développeur junior qui pose des questions à l'IA plusieurs fois par jour. Ou encore il y a eu l'apparition du vibe coding où l'IA a une place importante dans l'ensemble du processus de création.

Essayons simplement d'être un peu plus intelligents dans nos utilisations de l'IA et ne laissons pas mourir les forums communautaires comme StackOverflow en posant toujours plus de questions dont la réponse n'existe pas encore !

Cela peut aussi vous intéresser​

Si vous souhaitez approfondir le sujet ou mettre en place des solutions de votre côté, voici des pistes afin d'aller plus loin :

• Utiliser votre assistant IA en local : un autre article de notre blog afin de vous aider à installer une IA en local et l'intégrer dans un IDE
• Impacts de l’intelligence artificielle : risques et opportunités pour l’environnement : avis du Conseil Economique Social et Environnemental sur les impacts de l'IA sur l'environnement
• Quel est l’impact environnemental d’une IA générative ? : un article plus complet sur l'impact environnemental de l'IA
• Comment ChatGPT assoiffe cette population : une vidéo de 10 min par Léo Duff expliquant l'impact de l'utilisation de l'eau pour les datacenters des IA
• compar:IA : un site vous permettant d'analyser le comportement de deux IA et de les comparer. Vous pouvez obtenir des informations sur l'impact environnemental de la requête comme présentée ci-dessous

Quand nous avons cofondé zatsit, nous ne voulions pas créer une énième ESN. Le marché n’en manque pas et il en existe déjà beaucoup. Trop peut-être.

Ce que nous voulions, c’était faire émerger une autre façon d’entreprendre, dans le numérique.

Une façon plus humaine, plus responsable, plus engagée.

Nous sommes convaincus que la tech peut – et doit – être un levier d’impact positif. Pour nos clients, pour la société, pour l’environnement.

C’est cette conviction qui nous a poussés à faire de zatsit, une entreprise à mission, et à inscrire noir sur blanc notre raison d’être dans nos statuts.

Le serpent de mer des montées de version​

En tant que développeur·euse·s il n'est pas toujours facile de trouver le temps de maintenir à jour les versions des langages et des frameworks que l'on utilise.

Suivre le rythme des releases n'est pas toujours aisé, et on se retrouve souvent dans ce cercle vicieux : les montées de version mineures ne semblent pas suffisamment intéressantes pour que l'on prenne le temps de les faire. Alors on attend les majeures et les LTS...

Cet article à propos d'Angular, a pour but de donner un aperçu de la dynamique d'évolution du Framework ces derniers temps, et la direction prise par l'équipe de développement.

La tyrannie de la commodité : ce que nous coûte la facilité​

La Tyrannie de la commodité, qu'est-ce que c'est ?​

Traduction littérale de l'Anglais "tyranny of convenience", le concept n'est pas si récent. Evan Williams, co-fondateur de Twitter, le déclarait déjà en 2018 : « la commodité décide de tout ». Clef de voûte du marketing, certaines marques en ont même fait leur argument principal : "Pratique et intuitif", "Tous vos outils au même endroit". Pourtant, on devrait le savoir, un argument marketing est rarement un argument rationnel.