Et si chaque requête envoyée à votre assistant IA ne consommait pas l’énergie d’un vol Paris-New York, mais celle d’une simple tasse de thé ? C’est le pari de l’initiative « Intelligence per Watt » lancée par EnterpriseDB (EDB). Plutôt que de continuer à gonfler la puissance des GPU, EDB propose de s’attaquer à la source du problème : l’inefficacité de la couche données. Parce qu’au fond, à quoi bon disposer du modèle le plus puissant du monde si l’infrastructure qui l’alimente tourne à plein régime et surtout pour rien ?
EDB, qui est un acteur historique de l’écosystème PostgreSQL depuis 2006, ne cherche pas ici à faire du « greenwashing » à la mode. En accompagnant des institutions critiques (dont des banques, hôpitaux, administrations …) le groupe a compris une chose essentielle. Qui est que la souveraineté technologique ne se résume pas à l’indépendance vis-à-vis d’un cloud étranger. Elle passe aussi par la capacité à opérer ses propres systèmes sans dépendre d’une débauche de ressources matérielles qu’on ne contrôle pas toujours.
La donnée, ce chaînon manquant de l’efficacité
Alors que le marché se focalise sur l’optimisation des modèles de langage eux-mêmes, EDB s’intéresse à ce qui se passe juste en amont, c’est à dire l’indexation, la recherche, la transformation. Prenons le RAG (Retrieval-Augmented Generation), cette technique où l’IA va puiser des informations dans votre base documentaire. Traditionnellement, la recherche vectorielle nécessaire pour trouver les bons documents est une purge pour la mémoire et les processeurs.
Les nouveaux benchmarks de la plateforme EDB Postgres AI montrent que cette opération peut être accélérée de 5 à 12 fois. Encore mieux ? Là où il fallait autrefois 1 To de RAM pour traiter un milliard de vecteurs, 128 Go suffisent désormais. C’est le passage du bulldozer électrique au vélo de course. Le résultat est là mais l’empreinte énergétique fond comme neige au soleil.
Ce standard « Intelligence per Watt » ne repose pas sur de vagues promesses, mais sur une boucle de rétroaction très logique :
- Mesurer : il s’agit de quantifier le coût énergétique réel de chaque unité d’intelligence produite. EDB s’appuie sur une méthodologie validée par Incendium Consulting pour auditer les workflows complexes (agents, RAG, systèmes multi-agents).
- Optimiser : l’objectif est de réduire la demande en calcul, stockage et réseau à chaque étape. Dans un pilote mené avec un opérateur télécom mondial, cette approche a permis de réduire la consommation de tokens de 57%.
- Gouverner : c’est le point critique. Avec l’émergence des agents autonomes (Agents IA Vs IA Agentique) qui créent des bases et des index à la vitesse de la machine, le risque de prolifération incontrôlée est majeur. Sans une gouvernance fine, l’efficacité technique disparaît sous le poids de la dette technique.
C’est là que le lien avec les réseaux autonomes devient pertinent. Plus les systèmes IA gagnent en autonomie, plus ils génèrent de requêtes, de bases éphémères, de transformations de données en temps réel. Sans gouvernance fine au niveau du data layer, cette prolifération peut vite devenir ingérable, tant sur le plan technique qu’énergétique.
Une architecture ouverte plutôt qu’une boîte noire
Derrière ces principes, les résultats publiés sont concrets. Une étude indépendante (effectuée par Incedium Consulting) sur trois grandes institutions financières a montré une réduction allant jusqu’à 94% du nombre de cœurs de calcul nécessaires. À la clé, une baisse de 87% des émissions carbone, soit l’équivalent théorique de 33 000 voitures retirées de la circulation.
Ces données démontrent que performance et sobriété ne sont pas contradictoires. Dans le secteur des data centers, où la demande énergétique pourrait doubler d’ici 2030, chaque watt économisé devient un indicateur de performance économique autant qu’écologique. Les entreprises les plus avancées dans l’adoption de l’IA sont d’ailleurs celles qui exigent le plus de leur « data layer », comprenant que c’est là que se joue la rentabilité réelle.
Pour éviter de tomber dans le piège des solutions propriétaires opaques, EDB mise sur sa plateforme unifiée qui combine transactions, analytique et IA, tout en restant fidèle à PostgreSQL. L’ouverture est le mot d’ordre et les outils de mesure (comme l’Efficiency Calculator) sont à la disposition de tous.
Pour ceux qui se demandent par où commencer, rassurez-vous : EnterpriseDB a pensé l’expérience de bout en bout. La plateforme est disponible en version communautaire open source, avec des options enterprise pour les environnements critiques. La documentation est claire et progressive, les benchmarks sont publics et reproductibles, et la communauté PostgreSQL commence déjà à s’emparer du sujet. L’intégration avec les outils existants est fluide, que vous utilisiez des frameworks d’agents comme LangChain ou LlamaIndex, des plateformes d’orchestration comme Kubernetes, ou des solutions de monitoring comme Prometheus. Tout est expliqué sans jargon inutile, avec des exemples concrets pour les secteurs réglementés comme la finance, la santé ou l’énergie.
Adopter cette démarche demande évidemment une certaine expertise technique, mais elle offre en retour une maîtrise totale. Contrairement aux modèles de « boîte noire » qui promettent des miracles sans expliquer comment, EDB joue la transparence. Chaque organisation est libre d’auditer l’impact de ses propres agents, d’adapter les métriques à son contexte métier et de construire des systèmes qui ne sacrifient pas la planète sur l’autel de la performance.
La sobriété comme nouveau standard
Si l’on veut que l’IA soit autre chose qu’une bulle technologique à court terme, elle devra nécessairement devenir plus légère. Pas seulement parce que c’est plus responsable, mais parce que c’est la seule façon de la rendre soutenable à grande échelle. L’approche « Intelligence per Watt » pose cette question simple : pourquoi faire compliqué quand on peut faire intelligent ?
Pour les entreprises cela va permettre de choisir entre continuer à construire des systèmes gourmands qui dépendent de la puissance brute, ou miser sur une architecture de données plus fine et finalement beaucoup plus performante. Ce n’est pas le chemin le plus rapide au démarrage, mais c’est le seul qui permette d’avancer sans se laisser dépasser par ses propres coûts d’infrastructure.
Liens supplémentaires :
