// green-it

L'écoconception logicielle :
une discipline d'ingénierie.

Réduire l'empreinte numérique ne signifie pas sacrifier la performance. C'est exactement l'inverse : un code sobre est un code mieux conçu.

Le secteur numérique représente aujourd'hui entre 3 et 4 % des émissions mondiales de gaz à effet de serre, soit autant que l'aviation civile. Mais contrairement à d'autres secteurs, le logiciel offre des leviers d'amélioration considérables — souvent sans coût additionnel.

Mon approche Green IT est ancrée dans la pratique : ce n'est pas une case à cocher dans un rapport RSE, c'est une manière de concevoir et d'écrire du code depuis le début.

// principes

Comment j'applique l'écoconception

01

Mesurer avant d'optimiser

On ne réduit que ce qu'on mesure. J'utilise des outils comme GreenFrame, scaphandre, et le Carbon Intensity API pour quantifier l'impact réel des applications avant et après intervention.

02

Éliminer les traitements inutiles

N+1 queries, calculs redondants, données chargées inutilement : une grande partie de la consommation des applications vient de traitements qui n'auraient jamais dû exister.

03

Choisir les bons algorithmes

Un tri O(n²) sur 10 000 éléments consomme 100x plus qu'un O(n log n). La complexité algorithmique a un impact direct sur la consommation CPU et donc énergétique.

04

Optimiser les I/O et la mise en cache

Les accès disque et réseau sont les opérations les plus coûteuses en énergie. Une stratégie de cache cohérente peut réduire drastiquement les transferts inutiles.

05

Concevoir pour la longévité

Le meilleur écran est celui qu'on n'achète pas, le meilleur serveur est celui qu'on garde plus longtemps. Un logiciel bien conçu étend la durée de vie du matériel.

06

Documenter l'impact

Chaque optimisation est documentée avec ses métriques avant/après. Cela permet de prioriser les futures interventions et de démontrer la valeur concrète du travail réalisé.

// exemple concret

De la théorie à la pratique

Un batch Spring Boot de synchronisation tournait chaque nuit — et ne finissait jamais à l'heure. Voici comment on l'a multiplié par 600.

Performance

Avant

  • → Traitement enregistrement par enregistrement (1 requête SQL / ligne)
  • → Débit : ~20 enregistrements / seconde
  • → 15 sessions nocturnes × 8 heures chacune
  • → Synchronisation jamais à jour le matin

Après

  • → 1 requête SQL globale (lecture complète en 30 secondes)
  • → Step Spring Batch multi-threadé, curseur synchronized
  • → Débit : 13 000 enregistrements / seconde (×600)
  • → Le batch s'exécute en une seule nuit

Projet réel — données anonymisées.

SyncBatch.java — avant / après 
// ✗ Avant : 1 requête SQL par enregistrement
for (Long id : repository.findAllIds()) {
    Record r = repository.findById(id); // ×N
    sync(r);
}
// → ~20 rec/s, 15 nuits de 8h

// ✓ Après : curseur SQL + step multi-threadé

// ItemReader : curseur sur toute la table (30 sec)
// read() synchronized — le curseur n'est pas thread-safe
@Override
public synchronized Record read() {
    return cursorItemReader.read();
}

// Step configuré avec un pool de threads
stepBuilderFactory.get("syncStep")
    .<Record, Result>chunk(chunkSize)
    .reader(synchronizedCursorReader)
    .processor(syncProcessor)
    .writer(resultWriter)
    .taskExecutor(threadPoolTaskExecutor)
    .build();
// → 13 000 rec/s, 1 seule nuit

Complexité du code

Avant

  • → Logique de transitions encodée en if/else imbriqués
  • → États implicites dispersés dans le code métier
  • → Impossible de visualiser ou de tester les transitions
  • → Toute nouvelle règle métier = risque de régression

Après — Machine d'état avec stateless4j

  • → États et transitions déclarés explicitement
  • → Logique métier isolée, lisible et testable
  • → Ajout d'un état = 1 bloc de configuration, sans toucher au reste
  • → Diagramme d'états générable depuis le code
SyncStateMachine.java — stateless4j 
// ✗ Avant : transitions implicites
if (status.equals("PENDING")) {
    if (validated) {
        if (hasData) { ... }  // états cachés
    }
}

// ✓ Après : machine d'état avec stateless4j
StateMachineConfig<State, Trigger> cfg =
    new StateMachineConfig<>();

cfg.configure(State.PENDING)
   .permit(Trigger.VALIDATE, State.PROCESSING)
   .permit(Trigger.REJECT,   State.REJECTED);

cfg.configure(State.PROCESSING)
   .onEntry(this::startSync)
   .permit(Trigger.COMPLETE, State.DONE)
   .permit(Trigger.ERROR,    State.FAILED);

StateMachine<State, Trigger> sm =
    new StateMachine<>(State.PENDING, cfg);
sm.fire(Trigger.VALIDATE);

Votre application est-elle plus gourmande qu'elle ne devrait l'être ?

Un audit de 2 jours suffit souvent à identifier 80% des gains potentiels.

Demander un audit Green IT →