DEV Community: BANGA

L'IA ne remplace pas les développeurs — elle dissout ce qui les unissait

BANGA — Tue, 09 Jun 2026 18:11:44 +0000

Lundi matin, Libreville. Ndong ouvre le dépôt avant même son café. Le sprint
prévoyait qu'il code trois endpoints cette semaine — le backend, son métier
depuis sept ans. Ils sont déjà là. Commités pendant le week-end. Signés
Mavoungou, le frontend de l'équipe. Avec l'IA.

Le code compile. Les tests passent. Ndong n'est pas en colère. Mais une question
sourde s'installe : suis-je encore nécessaire sur ce projet ?

J'ai vu cette scène se rejouer dans plusieurs équipes, ici et ailleurs dans
l'écosystème francophone. On la résume toujours pareil : « l'IA va remplacer les
développeurs. » C'est faux. Et ce qui se passe vraiment est bien plus intéressant.

L'IA n'a pas supprimé des postes — elle a supprimé l'interdépendance

Avant, collaborer n'était pas qu'une vertu. C'était une nécessité de structure.
Ndong avait besoin de Mavoungou, et l'inverse était vrai. Personne ne pouvait
couvrir le terrain de l'autre. Cette dépendance fabriquait de la coopération
presque mécaniquement.

L'IA dissout cette nécessité. Et en la dissolvant, elle met au jour quelque chose
d'inconfortable :

Une bonne partie de ce qu'on appelait « esprit d'équipe » n'était parfois
qu'une dépendance technique déguisée en fraternité.

Les équipes qui resteront soudées après l'IA, c'est qu'elles l'étaient déjà pour
de vrai.

La division silencieuse

Le danger n'est pas la machine qui remplace l'humain. C'est plus sournois :

L'IA ne te remplace pas directement. Elle donne à un collègue — ou à un chef
qui code — de quoi justifier que tu n'es plus indispensable.

« Pourquoi garder cette personne si je produis 80 % de son travail avec l'IA ? »
La question a l'air rationnelle. Elle ne l'est qu'en surface. Mais elle suffit à
faire glisser une culture du « comment réussit-on ensemble ? » vers un « comment
je prouve que je réussis seul ? ».

Le piège des 20 %

Les 80 % que l'IA te sort ont l'air complets. Ça compile, ça ressemble au travail
d'un expert. Mais les 20 % qui manquent, c'est exactement là que vit l'expertise :

les cas limites que personne n'avait vus venir ;
les décisions d'architecture qu'on paie trois ans plus tard ;
le métier : pourquoi le client Airtel et le client Moov n'ont pas la même logique de réconciliation ;
et surtout : savoir quand l'IA se trompe.

Celui qui met son collègue de côté ne voit pas ces 20 % — justement parce que les
80 % visibles sont convaincants. À court terme, le remplacement a l'air rationnel.
À long terme, il se paie en dette technique. Le genre qu'on rembourse en prod, un
samedi soir, quand le système lâche et que c'est toi qu'on appelle.

La vraie question

« Est-ce que l'IA va remplacer les développeurs ? » La question est usée, et un
peu paresseuse. La vraie, celle qui décidera de l'avenir de nos équipes — à
Libreville comme à Douala ou à Dakar :

L'IA va-t-elle détruire la base réelle de notre collaboration, ou nous forcer à
la reconstruire sur autre chose que la simple dépendance technique ?

La réponse ne dépend pas de la machine. Elle dépend de nous.

J'ai développé l'anatomie complète de cette « division silencieuse » — la nuance
honnête (l'IA n'a rien inventé, elle a juste baissé le coût d'entrée de la
tentation), et comment reconstruire une collaboration choisie plutôt que
subie — dans l'essai original :

👉 Lire l'essai complet sur ban.ga →

Et dans votre équipe : l'IA vous rapproche-t-elle, ou commence-t-elle déjà, en
silence, à vous diviser ?

Spring Native + Cloud Run : cold-start 18, RAM 3, facture à 0 FCFA

BANGA — Tue, 26 May 2026 08:25:31 +0000

Cet article est la version condensée de mon retour d'expérience complet sur ban.ga — config Maven -Pnative détaillée, registrar RuntimeHintsRegistrar pour la console H2, pipeline PowerShell de 200 lignes, et chaque piège décortiqué.

23h47, un dimanche soir à Libreville

Screenshot WhatsApp d'une dev fictive : sa fintech crash silencieux sur l'OTP en prod.

Cold-start Spring Boot sur Cloud Run : 3 740 ms.

Lundi matin, première vraie facture GCP. Quelques milliers de FCFA — pour une dev qui paye son cloud avec sa bourse de fin d'études, c'est un choc.

MOUSSAVOU, l'héroïne fictive que je trimballe d'article en article, vient de découvrir le truc à la dure. Tu peux ranger ton code en DDD + Hexagonal + Spring Modulith pendant six mois. Si ta JVM met près de 4 secondes à booter, les utilisateurs reçoivent leur OTP avant que /verifier ne soit prêt à le valider. Re-saisie. Re-cold-start. Re-perte.

Le calcul économique qui pique

C'est là que ça devient désagréable. Un cold-start de 3,8 secondes, c'est 3,8 secondes de vCPU et de RAM facturées par Cloud Run, qu'il y ait une transaction qui aboutisse au bout ou pas. Chaque utilisateur qui timeout retry. Chaque retry réveille une nouvelle instance, donc un nouveau cold-start.

Sortons la calculette. 200 utilisateurs le matin × 3 retries × 3,8 s :

= 2 280 vCPU-secondes brûlées
  avant qu'une seule transaction n'aboutisse

Plus 182 GB-secondes de RAM, pour la même raison. Le min-instances=0 protège la facture la nuit. Il ne fait rien contre les cascades d'échec le matin.

Le bench

J'ai recompilé MboloPay (mini mobile money open source) en natif avec GraalVM. Même code Java 25. Compilation différente. Chiffres bruts mesurés le 16 mai 2026 sur Spring Boot 4.0.2, Liberica NIK 25, Hibernate 7.2.1, H2 in-memory :

Étape	JVM Java 25	Natif GraalVM	Gain
Boot → Tomcat init	1 207 ms	36 ms	×33
Hikari pool startup	559 ms	65 ms	×8.6
JPA init	774 ms	14 ms	×55
JPA → Tomcat 8080	875 ms	76 ms	×11.5
Total « Started in »	3 740 ms	205 ms	×18,2
RAM résident	~250 Mo	~80 Mo	÷3
Build CI	~10 s	7-12 min	×12 (compromis)

La ligne qui fait mal : JPA init passe de 774 ms à 14 ms (×55). Hibernate fait énormément de réflexion pour mapper entités → tables. Le AOT processing pré-calcule ce mapping à la compilation. Le runtime n'a plus qu'à brancher.

Comment ça marche, sans la magie

Spring AOT fait le travail à la compilation. Trois mécanismes empilés :

Closed-world analysis — GraalVM considère que ton application est fermée. Aucune classe ne sera ajoutée au runtime. À partir du main(), il suit toutes les références, marque les classes utilisées, jette le reste.
Génération de code direct — Spring Boot 4 inclut un plugin Maven, spring-boot-maven-plugin:process-aot, qui s'exécute avant la compilation native. Il lit ta config, simule le démarrage, génère du code Java qui remplace la réflexion runtime par des appels directs.
Native image — GraalVM compile ce code direct en exécutable natif (ELF sous Linux, .exe sous Windows). Plus de JVM au runtime. Plus de JIT. Plus de classpath scan.

📝 Note de terminologie. « Spring Native » était à l'origine un projet incubator séparé (le module spring-native, 2021-2022). Depuis Spring Boot 3 (novembre 2022), ce support a été intégré directement au core Spring Boot. Le nom « Spring Native » reste largement utilisé par habitude.

Le point clé : ton code Spring ne change pas. @RestController, @Service, @Repository, @Transactional, tout marche. Ce qui change, c'est le quand : ce que Spring fait normalement au démarrage de la JVM, il le fait maintenant au moment du mvnw -Pnative. Le runtime n'a plus rien à apprendre, il sait déjà.

Activer le profil natif tient en 6 lignes

C'est la partie qui surprend toujours quand je la montre :

<build>
    <plugins>
        <plugin>
            <groupId>org.graalvm.buildtools</groupId>
            <artifactId>native-maven-plugin</artifactId>
        </plugin>
        <plugin>
            <groupId>org.springframework.boot</groupId>
            <artifactId>spring-boot-maven-plugin</artifactId>
        </plugin>
    </plugins>
</build>

Pas de version explicite (gérée par spring-boot-starter-parent). Pas de config custom. Tu lances :

./mvnw -Pnative native:compile

Ou pour produire directement une image Docker :

./mvnw -Pnative spring-boot:build-image

Spring Boot délègue à Paketo Buildpacks (builder paketobuildpacks/builder-noble-java-tiny). Pas de Dockerfile. Le buildpack détecte le mode natif, télécharge GraalVM, compile, et produit une image OCI minuscule prête à pousser sur Artifact Registry.

Les 5 pièges qui m'ont coûté 2 jours

Piège 1 — La console H2 ne marche plus

http://localhost:8080/h2-console te renvoie une page blanche en natif. La servlet H2 utilise de la réflexion dynamique non hint-ée par Spring AOT.

Solution honnête : dev en JVM standard (./mvnw spring-boot:run), prod en natif. Si tu veux vraiment la console en natif, il faut écrire un RuntimeHintsRegistrar custom (squelette complet sur ban.ga) — quelques dizaines de lignes, à construire incrémentalement en réagissant aux ClassNotFoundException qui pop dans les logs Cloud Run. Plan une demi-journée.

Piège 2 — Spring Boot DevTools silencieusement ignoré

Tu as ajouté spring-boot-devtools au pom.xml. En JVM, hot-reload. En natif, ignoré sans erreur. Pas de log. Juste pas de hot-reload.

C'est logique : DevTools repose sur un classloader custom qui recharge les classes à chaud. Un binaire natif n'a pas de classloader. Tu ne peux pas hot-reloader du code machine.

Piège 3 — Les erreurs AOT bloquent le build

Le AOT processing tourne avant la compilation native. Si ton code a une erreur que l'AOT détecte (bean qui dépend d'une classe absente, circularité, config invalide), le build s'arrête. Aucun binaire ne sort.

[ERROR] Failed to execute goal org.springframework.boot:spring-boot-maven-plugin:4.0.2:process-aot
[ERROR] Caused by: java.lang.IllegalStateException: Failed to read candidate component class

C'est un faux ami : tu crois que c'est un problème natif, c'est en réalité un problème Spring détecté plus tôt qu'à la normale. Méthode debug : assure-toi d'abord que ./mvnw spring-boot:run démarre sans warning. Si la JVM démarre proprement, l'AOT démarrera aussi neuf fois sur dix.

Piège 4 — Liberica NIK ≠ Liberica JDK

Le grand classique qui fait perdre une demi-journée. Tu as installé Liberica JDK 25. Tu lances ./mvnw -Pnative native:compile. Tu obtiens :

native-image is not installed in your JAVA_HOME

Tu as installé la JDK Liberica 25, pas le NIK (Native Image Kit). La JDK seule ne contient pas native-image. Il te faut Liberica NIK 25, une distribution séparée qui inclut JDK + GraalVM + native-image.

Sous Windows, prévois aussi Visual Studio Build Tools (charge de travail « Développement Desktop en C++ ») — GraalVM Native Image utilise cl.exe (le compilateur MSVC). Lance la compilation depuis le « x64 Native Tools Command Prompt for VS 2022 ».

Piège 5 — `docker-credential-gcr` obligatoire sous Windows

Sur macOS et Linux, gcloud auth configure-docker installe correctement un helper. Sur Windows, il configure un helper qui pointe sur docker-credential-gcloud.exe… qui n'existe pas dans le PATH. À la fin de 10 minutes de build :

Cannot run program "docker-credential-gcloud": CreateProcess error=2

Il faut installer docker-credential-gcr séparément, l'ajouter au PATH, et :

docker-credential-gcr configure-docker --registries=<region>-docker.pkg.dev

Et ne pas oublier gcloud auth application-default login (ADC) en plus de gcloud auth login. Ce sont deux mécanismes d'authentification distincts. Sans les deux, push échoue avec auth: "invalid_grant" — après 10 minutes de build. Rageant.

Quand NE PAS faire du natif

Soyons honnêtes. Le natif n'est pas la solution à tout.

Tu changes ton code 30 fois par jour — early-stage produit, sprint design-prod-design. Le build natif de 7-12 minutes en CI va te rendre fou. Reste sur JVM standard, déploie en 2 minutes, garde tes itérations courtes.
Ton service tourne 24/7 sans jamais scale à zéro — trafic continu, instance jamais froide. Le cold-start n'est jamais payé. Pire : après warm-up JIT, la JVM peut être 10-20 % plus rapide en débit que ce qu'AOT a prédit à la compilation. Le natif gagne sur les workloads serverless / intermittents, pas sur les workloads stables.
Tu utilises massivement de la réflexion dynamique ou des libs tierces non Spring — tu peux y arriver, mais le coût d'ingénierie devient significatif. Mesure avant.

Résultat MboloPay

Facture revenue à 0 FCFA / mois tant que la démo reste sous les 2 millions de requêtes du free tier GCP. min-instances=0. Cold-start mesuré : 205 ms. Sur un OTP fintech, c'est la différence entre une transaction qui passe et une transaction perdue.

Pour aller plus loin

Cet article est la version condensée. Sur ban.ga/posts/spring-native-cloud-run/, tu trouveras :

Le RuntimeHintsRegistrar complet pour la console H2 (et pourquoi c'est « faisable mais pénible »)
Le pipeline PowerShell de ~200 lignes qui orchestre git → bump → build natif → push → deploy → smoke-test
La config gcloud run deploy détaillée avec les bons paramètres --concurrency / --cpu / --memory pour le natif
Pourquoi min-instances=1 « pour éviter les cold-starts » est généralement une erreur quand tu es déjà en natif

Le repo MboloPay est ouvert sur GitHub : github.com/bangaromaric/mbolopay. La démo tourne sur mbolopay.banga.ga (Cloud Run, min-instances=0, cold-start le matin, 200 ms le reste du temps).

Et vous ? Vous l'avez tenté en prod ? Quel piège vous a fait perdre le plus de temps ?

Merci à Yannick Serge Obam pour sa relecture exigeante qui a rendu l'article plus juste.

MOUSSAVOU apprend DDD : le guide pratique du dev qui veut écrire du code qui tient

BANGA — Sun, 17 May 2026 09:02:48 +0000

Comment DDD, l'architecture hexagonale et Spring Modulith te permettent d'utiliser Claude, ChatGPT et Copilot sans laisser l'IA générer un monstre — étude de cas MboloPay, mini mobile money open source en français

Il est 23h17 à Libreville. MOUSSAVOU relit pour la troisième fois la PR que son lead vient de rejeter. PayApp, la fintech où elle a été embauchée il y a dix-huit mois, doit livrer demain matin l'intégration avec Orange Money. Pourtant elle a fait les choses bien — elle a demandé à Claude de l'aider, copié les meilleures réponses Stack Overflow, ajusté avec Copilot. Et un simple changement — accepter aussi les nouveaux numéros à 9 chiffres en plus des 10 actuels — fait quand même exploser 47 tests dans 12 fichiers qui n'ont rien à voir.

Validation Spring dans le AbonneController (générée par ChatGPT il y a six mois). Regex copiée-collée dans trois services (Copilot a complété, elle a dit oui). Méthode setNumeroTelephone() qui contrôle parfois (un Stack Overflow qu'elle a oublié de finir d'adapter). Le numéro circule en String partout dans le code. L'IA a livré 1 000 lignes en trois mois. Personne — pas même Claude — ne sait plus où poser cette satanée nouvelle règle.

Si cette scène te parle — si tu as déjà ouvert un UserService.java de 800 lignes dans une fintech à Dakar, Lomé ou Yaoundé — ne ferme pas cet onglet. Dans 15 minutes, tu vas connaître trois patterns qui auraient évité à MOUSSAVOU son insomnie : DDD, Architecture Hexagonale, Spring Modulith. Tu vas les voir en action sur un projet open source ancré dans notre écosystème : MboloPay (mbolo veut dire "bonjour" en Fang, langue gabonaise), un mini service de mobile money écrit en français, avec Airtel Money et Moov Money comme opérateurs, et une démo live qui te laisse explorer l'architecture en mouvement.

Spoiler : ton problème n'est pas que tu utilises l'IA. Ton problème est que tu lui fais confiance pour des choses qu'elle ne peut pas faire. L'IA exécute. C'est toi qui dois architecter.

Pas de théorie poussiéreuse. Du concret. On commence par comprendre pourquoi le code d'MOUSSAVOU s'est emmêlé — parce que tant qu'on ne nomme pas le problème, on tourne en rond.

1. Pourquoi un Spring Boot classique finit en spaghetti

Spring Boot t'apprend trois sigles dès la première semaine : @RestController, @Service, @Repository. Trois couches techniques empilées comme un sandwich. Sur un CRUD simple, ça marche. Sur l'intégration Orange Money de MOUSSAVOU, ça craque.

Pourquoi ? Parce que ces couches ne disent rien du métier. Quand MOUSSAVOU veut savoir où mettre la règle « un numéro Airtel commence par +24107 et un Moov par +24106 », elle a quatre candidats légitimes :

Le controller, via @Valid sur le DTO.
Le service, via une vérification manuelle dans creerAbonne().
L'entité JPA, via @Pattern Bean Validation.
Un @PrePersist listener Hibernate.

Réponse classique dans la vraie vie : les quatre, en même temps, sans coordination. C'est ce qu'on appelle l'anemic domain model (modèle de domaine anémique) : tes entités sont des sacs de getters/setters sans comportement. La logique métier se disperse comme du sucre versé sur une table. Et le jour où la règle change, tu passes 6 heures à chasser les copies.

⚠️ Et l'IA dans tout ça ?

En 2026, ce que je viens de décrire n'arrive plus malgré l'IA — ça arrive à cause d'elle. ChatGPT, Claude, Copilot sont incroyables pour produire du code qui compile. Mais si tu ne sais pas quelle architecture tu vises, l'IA te livre 800 lignes de UserService aussi vite que tu peux les copier-coller. L'IA n'a aucune opinion sur l'architecture par défaut — elle reproduit le pattern le plus fréquent dans son corpus d'entraînement, qui est précisément le sandwich @RestController / @Service / @Repository que tu as vu sur 10 000 tutos.

Plus vite, donc. Mais plus profondément en spaghetti 🍝

💡 L'astuce ? Ne plus penser en couches techniques. Penser en domaines métier. Et faire en sorte que la règle « un numéro Orange Money valide ressemble à ça » n'ait qu'un seul endroit où vivre. Spoiler : ce n'est pas dans le controller.

C'est exactement ce que DDD propose. Allons voir.

2. DDD — Modéliser le métier, pas la technique

DDD (Domain-Driven Design, conception pilotée par le domaine) part d'une idée simple : ton code doit refléter le métier, pas la mécanique technique. Quatre concepts à connaître. Quatre analogies pour les ancrer.

2.1 Bounded Context = département d'une entreprise

Imagine une grande boîte de distribution à Abidjan. Le service commercial parle de « client » : un prospect qu'il faut convaincre. Le service comptabilité parle de « client » aussi : un compte qu'il faut facturer. Le service livraison ? Encore « client » : une adresse où amener le colis. Trois départements, trois définitions différentes du même mot. Et c'est très bien comme ça.

Un Bounded Context (BC, contexte délimité) c'est exactement ça : un périmètre où un vocabulaire métier est cohérent. À l'intérieur du BC, « client » veut dire UNE chose. À la frontière, on traduit.

MboloPay a trois bounded contexts :

identite — connaît les abonnés. Pour lui, un abonné a un nom, un numéro de téléphone gabonais, une date d'inscription.
portefeuille — connaît les portefeuilles. Pour lui, un abonné est juste un identifiant qu'il transporte sans rien savoir d'autre.
shared — un mini module ouvert qui contient ExceptionDomaine, racine de toutes les exceptions métier.

Chaque BC vit dans son propre paquet Java. Aucun n'importe les classes internes de l'autre. Comment ils communiquent alors ? On y vient, c'est la magie de Spring Modulith. Patience.

2.2 Aggregate = la racine et ses branches

Dans un BC, certaines classes sont plus importantes que d'autres. Elles sont des Aggregate Roots (racines d'agrégat) — les troncs d'arbres métier. Tu veux toucher une feuille ? Tu passes par la racine. Toujours.

Dans MboloPay, Abonne est un Aggregate Root du module identite. Portefeuille est un Aggregate Root du module portefeuille. Tu ne crées jamais un Abonne avec new Abonne() suivi de 12 setters. Tu utilises une factory :

@AggregateRoot
public class Abonne {
    // ... champs privés finals

    public static Abonne creer(NomGabonais nom, NumeroTelephoneGabonais numero) {
        // les invariants s'appliquent ICI, à la naissance
        return new Abonne(AbonneId.nouveau(), nom, numero, Instant.now(), true);
    }

    // PAS de setNom(...), PAS de setNumero(...)
}

Pourquoi c'est révolutionnaire ? Parce qu'un Abonne, dès qu'il existe, est valide. Pas de phase « à moitié construit, j'attends d'appeler le setter suivant ». Pas de risque qu'un junior pressé oublie un setActif(true). La règle métier vit dans la factory, pas éparpillée dans 10 endroits.

Tu te dis sûrement : « OK mais on perd la flexibilité des setters ». Réponse : oui. Et c'est précisément le but.

Un Aggregate Root sans ses invariants, c'est comme un kiosque mobile money qui prend l'argent sans noter qui a déposé combien. Techniquement opérationnel, statistiquement catastrophique.

Petit test IA : demande maintenant à Claude ou ChatGPT « crée une classe Java Abonne avec nom et numéro de téléphone ». Tu reçois 90 % du temps : class Abonne { private String nom; public void setNom(...) }. Modèle anémique. Setters publics. Aucun invariant.

Reformule : « crée un Aggregate Root jMolecules pour Abonne, avec factory creer(), champs finals, et invariants appliqués à la construction ». L'IA te génère exactement ce qu'on vient de voir, en 10 secondes.

La différence n'est pas dans l'IA. Elle est dans ton vocabulaire.

2.3 Value Object = identité par la valeur, pas par la référence

Maintenant le vrai changement de mentalité — celui qui va régler une bonne partie de l'insomnie de MOUSSAVOU.

Un Value Object (VO) est une classe qui représente une valeur, pas une chose. Un billet de 5000 FCFA et un autre billet de 5000 FCFA sont interchangeables : tu te fiches de leur numéro de série, ce qui compte c'est leur valeur. Donc Argent(5000) est égal à Argent(5000), peu importe quel objet Java se cache derrière.

MboloPay a une foule de VOs. Les plus parlants :

AbonneId — encapsule un UUID. Pas un String. Un AbonneId.
PortefeuilleId — pareil mais distinct. Tu ne peux pas confondre les deux.
Argent — un montant en FCFA. Validation à la construction : pas de montant négatif.
NumeroTelephoneGabonais — un numéro qui garantit le format E.164 gabonais et l'opérateur (Airtel ou Moov).
NomGabonais — un nom non vide, capitalisé, sans caractères exotiques.

Voici l'idée de NumeroTelephoneGabonais (extrait simplifié, vérifie le vrai code sur GitHub) :

@ValueObject
public record NumeroTelephoneGabonais(String valeur, OperateurMobile operateur) {
    public NumeroTelephoneGabonais {
        Objects.requireNonNull(valeur);
        if (!valeur.matches("\\+241[067]\\d{7}")) {
            throw new NumeroNonAutoriseException(valeur);
        }
        // operateur déduit du préfixe Airtel/Moov
    }
}

Maintenant regarde cette signature de méthode :

public void transferer(AbonneId from, AbonneId to, Argent montant);

Tu peux ? Tu ne peux pas appeler transferer(montant, from, to) par erreur. Le compilateur Java refuse. Avec des String et long partout, tu aurais pu envoyer 1000 FCFA à un numéro de téléphone, ou pire — un identifiant client à la place du montant — et te demander pourquoi la prod est en feu un vendredi soir. bolooooh

C'est ce qu'on appelle le Types Driven Development : les erreurs métier deviennent des erreurs de compilation. MOUSSAVOU, qui peste contre ses 47 tests cassés, aurait préféré que ces 47 tests soient remplacés par UN compilateur qui dit non. C'est exactement ce que les VOs offrent.

Et c'est ICI que ça devient intéressant avec l'IA. Une fois que tu connais les VOs, tu peux dire à Claude « refactore cette classe pour remplacer chaque String par un Value Object typé ». Il le fait en une minute. C'était sans toi 2 jours de refactor. Avec toi qui ne connais pas les VOs, c'était 0 jour — parce que tu n'aurais jamais demandé.

(Oui, je sais. Encore une analogie. C'est qu'on est dans un article pédagogique. Subis.)

2.4 Domain Event = annonce publique dans l'entreprise

Reprends ton entreprise au Gabon. Le service RH embauche quelqu'un. Que se passe-t-il ?

Les badges préparent un badge.
La paie ouvre un dossier salaire.
L'IT crée un compte mail.

Tout ça en réaction, sans que les RH appellent chaque service à la main. Comment ? Une annonce publique : « NDONG MENGUE a été embauchée le 15 mai. » Chaque service écoute, chacun fait son boulot. Personne ne dépend frontalement de personne.

C'est un Domain Event : un fait métier qui s'est produit, qu'on annonce, et que d'autres modules peuvent écouter.

MboloPay a EvenementAbonneCree, publié par identite quand un abonné est créé. Le module portefeuille l'écoute et crée automatiquement un portefeuille à 0 FCFA pour ce nouvel abonné.

public record EvenementAbonneCree(AbonneId abonneId, Instant survenuLe) { }

Trois lignes. Un record immuable. Aucune annotation Spring. C'est un fait métier, pas un message technique. C'est l'identite qui annonce, et c'est le métier qui parle.

Tu vois où je veux en venir ? Le module portefeuille ne connaît pas le module identite au sens classique. Il connaît juste un événement — un nom dans un vocabulaire commun. Demain, on peut remplacer identite par un service externe sans toucher portefeuille.

C'est exactement la promesse de DDD : modulariser par le métier, pas par la technique.

3. Architecture Hexagonale — Le cœur et ses prises

Maintenant qu'on a nos agrégats, nos VOs et nos events, il reste UNE question : où on les met physiquement dans le code ?

3.1 L'idée fondatrice

L'architecture hexagonale (aussi appelée Ports & Adapters) répond : le domaine est au centre. Tout autour, des adaptateurs qui le connectent au monde extérieur — HTTP, base de données, message broker, UI, terminaux de paiement, tout ça.

Imagine un cœur. Au centre, ton domaine métier (Abonne, Portefeuille, leurs règles). Tout autour, des prises électriques. Chaque prise (adapter) peut être débranchée et remplacée sans toucher au cœur. Tu testes le cœur avec une fake prise (un repo en mémoire). Tu déploies en prod avec une prise JPA. Tu envisages une prise gRPC pour le mobile — tu la branches.

Tu ris ? Attends de voir la règle absolue.

3.2 Ports vs Adapters

Le domaine ne demande pas ce dont il a besoin avec des classes concrètes. Il déclare des interfaces :

Port in : interface d'un cas d'usage. Exemple : CreerAbonneUseCase. Le monde extérieur l'appelle.
Port out : interface dont le domaine a besoin pour fonctionner. Exemple : DepotAbonne (un repository), PublieurEvenements (un publisher).

Le domaine ne sait PAS qui implémente ces interfaces. Il dit « j'ai besoin de sauvegarder un Abonne ». C'est l'infrastructure qui répond : « OK, moi je le sauvegarde en JPA » (ou en mémoire pour les tests, ou en HTTP pour un microservice futur).

Règle d'or à marteler trois fois : dans MboloPay, domain/port/in/ et domain/port/out/ ne contiennent QUE des interfaces Java. Aucune classe concrète. Aucune dépendance Spring. C'est vérifié par un test ArchUnit qui casse le build si tu glisses une classe. On y revient au §5.

3.3 Les 4 couches MboloPay

Chaque module suit la même structure (ouvre src/main/java/ga/banga/mbolopay/identite/ sur le repo pour vérifier) :

identite/
├── domain/                 # ZÉRO framework. Le cœur.
│   ├── model/              # Abonne, AbonneId, NomGabonais, NumeroTelephoneGabonais
│   ├── event/              # EvenementAbonneCree (record)
│   ├── exception/          # NumeroDejaUtiliseException, NumeroNonAutoriseException
│   ├── port/in/            # CreerAbonneUseCase (interface)
│   ├── port/out/           # DepotAbonne, PublieurEvenements (interfaces)
│   └── service/            # logique métier pure
├── application/
│   └── service/            # CreerAbonneService — orchestration POJO
└── infrastructure/
    ├── primary/            # AbonneController (REST, ENTRE)
    └── secondary/          # DepotAbonneJpa, transactions, publishers (SORT)

Et le mieux ? Dans la démo en ligne — https://mbolopay.banga.ga/ — active le mode pédagogique depuis /profil, puis le slow-mo. Crée un abonné. Tu verras l'opération traverser ces 4 couches en direct, avec un curseur lumineux qui glisse de Primary → Application → Domain → Secondary. C'est rare qu'un projet pédagogique te laisse voir l'architecture en mouvement. Profites-en.

3.4 La règle absolue

Infrastructure dépend du Domaine. Jamais l'inverse.

Si tu vois import org.springframework.* dans une classe sous domain/, c'est un bug. Si tu vois @Entity sur un Aggregate Root, c'est un bug. Si tu vois @Service sur un service d'application, c'est presque un bug — MboloPay rend ces services 100 % POJO et ajoute la transactionnalité par un décorateur infrastructure. Le domaine reste pur, framework-free, testable sans Spring.

Demande à l'IA « sépare ce code en 4 couches hexagonales : primary, application, domain, secondary, avec ports in et out dans le domain ». L'IA le fait. Bien. Vite. Mais elle ne te dira jamais « tiens, il faudrait peut-être appliquer le pattern hexagonal ici » si tu ne le sais pas déjà — c'est ton job à toi.

Tu trouves ça extrême ? Attends de voir comment Spring Modulith assemble plusieurs hexagones.

4. Spring Modulith — Assembler les bounded contexts proprement

4.1 Module = Bounded Context dans le monolithe

Spring Modulith te permet d'avoir plusieurs bounded contexts dans le même monolithe Spring Boot, avec des règles strictes vérifiées au runtime. Pas de microservices, pas de packaging Maven multi-module — juste des paquets Java avec des frontières déclarées et un test qui s'assure que personne ne triche.

C'est l'entre-deux idéal pour 90 % des projets : tu profites de la simplicité d'un monolithe (un seul JAR, une seule DB, des transactions ACID) tout en gardant la modularité d'un système distribué. Sans les emmerdes du réseau, du déploiement, et des transactions distribuées que personne ne sait vraiment debugger un samedi.

4.2 Trois mécanismes à connaître

@ApplicationModule sur le package-info.java racine du module — déclare le type (OPEN, CLOSED, NESTED) et les dépendances autorisées :

@ApplicationModule(allowedDependencies = {"shared", "identite :: events"})
package ga.banga.mbolopay.portefeuille;

Traduction : le module portefeuille peut dépendre de shared (entièrement) et de la named interface events du module identite. Pas du reste. S'il essaie d'importer identite.domain.model.Abonne, le test échoue.

@NamedInterface sur un sous-paquet — l'expose à des modules sélectionnés. Le paquet identite.domain.event est annoté @NamedInterface("events") dans son package-info.java. C'est la porte publique d'identite vers les autres modules. Le reste du module est invisible de l'extérieur.

@ApplicationModuleListener — un listener cross-module qui s'exécute dans une transaction propre. Voici l'écouteur côté portefeuille :

@Component
class EcouteurEvenementAbonne {
    private final CreerPortefeuilleUseCase creerPortefeuille;

    @ApplicationModuleListener
    void on(EvenementAbonneCree evt) {
        creerPortefeuille.executer(new CommandeCreerPortefeuille(evt.abonneId()));
    }
}

Trois annotations, deux mondes parfaitement isolés. Et le code reste lisible.

4.3 Le moment « OHHH »

Tu réalises ? portefeuille ne sait absolument rien de Abonne. Il connaît juste un événement et un identifiant. Demain, on extrait identite en microservice ? On change le listener pour écouter Kafka au lieu d'un event Spring local. Le reste est intact.

C'est ça, la promesse tenue de DDD + Hexagonal + Modulith réunis. Et c'est ça que MOUSSAVOU cherchait depuis 18 mois sans savoir le nommer.

Un dernier mot sur l'IA : Claude, ChatGPT, Copilot connaissent parfaitement Spring Modulith. Les annotations, les listeners, les Named Interfaces — ils te génèrent tout ça parfaitement. Ce qu'aucun de ces outils ne peut faire pour toi : décider où passent les frontières entre tes bounded contexts. Cette décision est purement métier. Elle vient de ta compréhension du problème, pas de l'IA. Et c'est précisément la décision la plus importante de ton architecture.

5. jMolecules et jSpecify — Les deux helpers qui changent tout

5.1 jMolecules : rendre DDD lisible à la machine

jMolecules est une mini bibliothèque qui fournit des annotations DDD : @AggregateRoot, @Identity, @ValueObject, @DomainEvent, etc. Aucune magie runtime — c'est juste du marquage déclaratif.

Avantages concrets :

Le code dit exactement ce qu'il est. @AggregateRoot class Abonne se lit en une seconde.
Tu peux écrire des tests d'architecture qui se basent dessus.
Des plugins (IntelliJ, autres outils) reconnaissent la sémantique et te guident.

5.2 jSpecify : null-safety modernisée

jSpecify est l'évolution de @Nullable/@NonNull en standard moderne supporté par Eclipse, IntelliJ, et bientôt javac. MboloPay annote ses paquets avec @NullMarked, ce qui veut dire : tout est non-null par défaut, sauf si explicitement marqué @Nullable.

Conséquence pour MOUSSAVOU : moins de NPE en prod, plus de retours Optional<T> invasifs partout, plus de bug silencieux « le numéro est null ». C'est gratuit, c'est moderne, c'est non-invasif. Tu peux l'adopter dans ton prochain projet ce soir.

6. Et les tests, dans tout ça ?

Tu as compris la théorie. Mais qu'est-ce qui empêche un junior pressé de tout casser le vendredi à 17h ?

Trois suites de tests, qui cassent le build à la moindre violation :

HexagonalArchitectureTest (ArchUnit, 18 règles). Vérifie qu'aucune classe du domaine n'importe Spring, JPA, Jackson ou Jakarta Validation. Vérifie que domain/port/in|out ne contiennent QUE des interfaces. Vérifie que toutes les exceptions métier héritent de ExceptionDomaine. Vérifie que les @RestController vivent UNIQUEMENT dans infrastructure/primary/web/.
ModularityTests (Spring Modulith). Vérifie la structure modulaire, les allowedDependencies déclarées dans les package-info.java, l'absence de cycles entre modules. Génère même un diagramme PlantUML automatiquement dans target/spring-modulith-docs/.
Tests unitaires métier classiques sur les VOs et Aggregates.

Le truc essentiel ? Ces règles sont vérifiées par des tests qui CASSENT le build. Si demain MOUSSAVOU importe org.springframework.* dans domain/, sa PR ne passe pas la CI. L'architecture est devenue exécutable. C'est la différence entre « on a une convention » et « on a une garantie ». Ton lead dort mieux la nuit. Toi aussi.

Pour voir, clone le repo et lance :

./mvnw test -Dtest=HexagonalArchitectureTest,ModularityTests

15 secondes pour valider que ton architecture tient debout. Imbattable.

💡 En 2026 ces tests deviennent ton meilleur garde-fou contre l'IA. Quand ChatGPT te génère un code qui marche mais qui glisse un import org.springframework.* dans le domaine pour gagner du temps, ton CI s'écroule. Tu vois le bug. Tu redresses. Sans HexagonalArchitectureTest, tu n'aurais rien vu — et ton code aurait dérivé en six mois.

7. L'IA dans tout ça — 3 règles d'or pour les juniors en 2026

Si tu es arrivé·e jusqu'ici, tu as compris le fond. Reste un sujet qu'on ne peut plus esquiver en 2026 : comment utiliser l'IA SANS qu'elle détruise ton architecture.

Tu utilises probablement Claude, ChatGPT ou Copilot tous les jours. Moi aussi. Sans eux, MboloPay aurait pris deux ans au lieu de huit mois. Mais pendant ces huit mois, j'ai appris une chose que personne ne dit assez fort : l'IA n'a pas d'opinion sur l'architecture. Elle exécute ce que tu lui demandes. Si tu lui demandes mal, elle exécute mal — vite.

Trois règles d'or, durement apprises :

7.1 Apprends l'architecture AVANT de l'utiliser pour produire de l'architecture

L'IA est l'assistant le plus brillant que tu auras jamais. Mais c'est un assistant. Il accélère. Il n'oriente pas. Si tu lui demandes « fais-moi une appli de mobile money », il te génère un MobileMoneyService de 600 lignes qui marche. C'est toi qui dois lui dire « isole un bounded context identite et un bounded context portefeuille, communique par événement de domaine ».

Sans cette phrase, tu obtiens un monstre. Avec, tu obtiens MboloPay.

7.2 Donne le vocabulaire métier exact

Ce que Claude/ChatGPT/Copilot ne savent pas, c'est ton domaine. Mais ils savent EXACTEMENT comment écrire un Aggregate Root, un Value Object, une factory, un Domain Event, un @ApplicationModuleListener. Le vocabulaire technique, ils l'ont avalé pendant leur entraînement.

Ton job : leur donner ce vocabulaire enrichi du tien. Au lieu de « valide le numéro de téléphone », écris « crée un Value Object NumeroTelephoneGabonais avec validation E.164, opérateur Airtel/Moov détecté depuis le préfixe, et exception métier NumeroNonAutoriseException qui hérite de ExceptionDomaine ». L'IA livre. Parfait. En 30 secondes.

7.3 Verrouille avec des tests d'architecture

L'IA peut changer d'avis au prochain prompt. Tu lui as dit hier de respecter les couches hexagonales ; demain elle glissera un @Service dans le domaine parce que ce sera plus court. Tu ne verras pas tout.

Tes 18 règles ArchUnit et tes ModularityTests sont des garde-fous non-négociables. Ils s'en fichent que le code soit de toi ou de Claude — si la règle est violée, le build casse. C'est ce qui empêche ton archi de pourrir silencieusement à chaque sprint.

💡 La phrase à retenir : en 2026, le vrai super-pouvoir n'est plus de savoir CODER. C'est de savoir QUOI demander à l'IA, et de comprendre ce qu'elle te rend. Tout le reste de cet article t'a donné ce vocabulaire.

8. À toi de jouer

Quatre mini-exercices, du plus simple au plus formateur. Compte 30 minutes pour les quatre :

Ouvre la démo à https://mbolopay.banga.ga/. Active Mode pédagogique dans /profil. Crée un abonné avec un numéro Airtel (+24107XXXXXXX). Repère les badges Q/C qui apparaissent et le flash de l'événement EvenementAbonneCree.
Active le slow-mo depuis le même /profil. Fais un dépôt de 5000 FCFA. Observe l'overlay qui traverse les 4 couches Hexa. Identifie quel composant est dans la couche Application, lequel est dans Domain, lequel est dans Secondary.
Va sur GitHub : https://github.com/bangaromaric/mbolopay. Ouvre Argent.java. Liste les invariants appliqués au constructeur. Bonus : que se passe-t-il si tu passes un montant négatif ? Et un montant null ?
Lance les tests d'architecture localement :

   git clone https://github.com/bangaromaric/mbolopay.git
   cd mbolopay
   ./mvnw test -Dtest=HexagonalArchitectureTest

Puis va dans n'importe quelle classe domain/ et ajoute un import org.springframework.stereotype.Service;. Relance le test. Regarde le build mourir avec un message d'erreur précis. Ressuscite-le en supprimant l'import. Ressens le pouvoir.

L'épreuve de l'IA. Ouvre Claude ou ChatGPT. Tape : « Crée une classe Java pour modéliser un numéro de téléphone gabonais. » Note ce que tu reçois. Puis tape : « Refais-le comme un Value Object jMolecules @ValueObject avec validation E.164 (+241[067]\d{7}), opérateur Airtel/Moov détecté depuis le préfixe, et exception métier NumeroNonAutoriseException qui hérite de ExceptionDomaine. » Compare. Toute la différence est dans ton vocabulaire. C'est ce que tu viens d'apprendre.

9. Conclusion + Ressources

Récap en cinq lignes — à retenir avant le prochain prompt que tu enverras à Claude :

DDD = on modélise le métier, pas la technique. Bounded Contexts, Aggregates, Value Objects, Domain Events.
Hexagonal = le domaine est au centre. Tout autour, des adaptateurs interchangeables. Le domaine reste framework-free.
Spring Modulith = plusieurs Bounded Contexts dans un monolithe, avec frontières vérifiées au runtime.
jMolecules = annotations qui rendent DDD lisible à la machine (et à tes collègues).
jSpecify = null-safety moderne, non-invasive, gratuite.

Ce que tu fais maintenant ? Tu clones MboloPay, tu lis le code, tu lances les tests, tu casses une règle volontairement pour voir, tu la répares. Ensuite, tu prends ton prochain projet perso (un mini blog, un gestionnaire de tâches, ton agrégateur de bourses universitaires) et tu essaies UN seul de ces patterns dessus. Les Value Objects. C'est le plus rapide à essayer, c'est ce qui te marquera le plus vite.

Pas tout d'un coup. Ne sois pas MOUSSAVOU qui passe deux nuits blanches à refactor tout son legacy. Sois MOUSSAVOU lundi matin : elle a appliqué un VO sur le numéro de téléphone, son lead a souri sur la PR, et elle a dormi le soir.

⚠️ Une nuance d'honnêteté pour finir : DDD/Hexagonal/Modulith ne sont pas la bonne réponse pour tous les projets. Pour un CRUD pur avec 3 entités et 0 règle métier, c'est de l'over-engineering. Ces patterns brillent quand le métier est riche, quand l'équipe grandit, quand le projet doit vivre 5+ ans. La fintech de MOUSSAVOU coche les trois cases. Le tien probablement aussi, sinon tu ne lirais pas cet article.

En 2026, savoir coder ne suffit plus — l'IA le fait. Savoir demander à l'IA et comprendre sa réponse, c'est ce qui te distingue. Toutes les notions de cet article (Bounded Context, Aggregate, Value Object, Port, Adapter, Named Interface) sont précisément le vocabulaire qui permet ce dialogue de qualité. Garde-les. Pratique-les. Sans elles, l'IA va plus vite — mais elle te conduira au précipice plus vite aussi.

Ressources

Démo MboloPay : https://mbolopay.banga.ga/
Repo GitHub : https://github.com/bangaromaric/mbolopay
Livres : Domain-Driven Design (Eric Evans), Implementing Domain-Driven Design (Vaughn Vernon), Get Your Hands Dirty on Clean Architecture (Tom Hombergs).
Docs en ligne : jmolecules.org, jspecify.dev, docs.spring.io/spring-modulith.

Bonne route. Et mbolo si tu publies ton projet — partage le lien, j'irai lire.

Article rédigé en pensant à tous les MOUSSAVOU qui codent tard le soir dans les fintechs naissantes du continent, avec ou sans l'aide de Claude, ChatGPT ou Copilot. MboloPay est volontairement éducatif et open source — utilise-le, fork-le, casse-le, améliore-le, et publie ton propre article si l'envie te prend.

Auteur du projet MboloPay : BANGA Romaric.