AfroCode Lab

🎯 J'ai décidé de rester full Dart, et voici pourquoi.

Très prochainement je vais commencer le développement d'une application pour mon projet très ambitieux. Je compte construire quelque chose qui apporte vraiment un plus dans notre société. J'ai plusieurs idées en tête mais je n'ai pas encore pris la décision finale sur laquelle je vais retenir.

Par contre le choix technique, lui, est déjà arrêté. Le backend sera en Serverpod.

Serverpod c'est un framework backend écrit entièrement en Dart. Le framework a un ORM intégré pour PostgreSQL, il a un système de migrations, authentification prête à l'emploi, cache, WebSockets pour le temps réel, et surtout la génération automatique du code client. Je définis mes modèles une seule fois et Serverpod génère les classes correspondantes côté serveur et côté Flutter, avec une sécurité de types de bout en bout.

Alors pourquoi pas Supabase, que j'utilise pourtant sur mes autres projets ?

Parce que ce n'est pas le même besoin. Supabase c'est un backend as a service(qu'on appelle un BaaS) . Avec lui Vous configurez, et ensuite vous branchez, ça marche vite. C'est excellent quand vous voulez livrer rapidement à un client qui se moque complètement de savoir ce qui tourne derrière.

Mais sur un projet ambitieux, la logique n'est pas la même. Je dois pouvoir défendre chaque décision technique devant un jury. Expliquer mon architecture backend, pourquoi tel endpoint fonctionne comme ça, comment j'ai géré l'authentification, comment les données circulent. Avec Supabase, une bonne partie de ces réponses se résume à "la plateforme le fait pour moi". Ce n'est pas suffisant pour un travail à défendre.

Ensuite parce qu'avec une logique métier complexe, Supabase montre ses limites. Vous finissez par écrire vos règles dans des fonctions PostgreSQL et des edge functions en TypeScript. Donc concrètement vous sortez déjà de Dart, vous jonglez entre trois environnements différents, et votre logique métier se retrouve éparpillée entre le client Flutter, la base de données et des fonctions serverless. Sur un projet qui doit tenir plusieurs mois, ça devient difficile à maintenir et surtout difficile à expliquer proprement.

Avec Serverpod je garde tout au même endroit. Un seul langage du widget jusqu'à la requête SQL. Ma logique métier vit dans le backend, là où elle doit vivre, écrite dans le langage que je maîtrise déjà.

Et il y a une raison plus personnelle aussi. Je veux être vraiment autonome comme développeur Flutter. Capable de construire mon propre backend de bout en bout, sans dépendre uniquement d'une plateforme tierce qui peut changer ses tarifs, ses limites ou ses conditions du jour au lendemain.

Je précise quand même une chose pour éviter les malentendus. Je ne dis pas que Supabase est mauvais. Je continue de l'utiliser et je le recommande sans hésiter sur des projets où la vitesse de livraison compte plus que le contrôle total. Ce sont deux outils pour deux situations différentes.

Ici mon besoin c'est le contrôle et la compréhension complète de ce que je construis. Donc Serverpod.

Et bien sûr je vais tout documenter ici en build in public. Les décisions d'architecture, les blocages, les moments où Serverpod va me surprendre en bien ou me poser des difficultés inattendues. Rien de filtré.

Alors Abonne-toi à AfroCode Lab pour suivre ce projet depuis le début 🔔

Ton application vibe-codée avec l'IA comporte probablement ces problèmes. Et le pire, c'est que tu ne les vois pas.

Parce que le vibecoding a un défaut que la programmation classique n'a pas. Quand ça compile et que ça s'affiche à l'écran, tu crois que c'est fini. Alors qu'en réalité ce qui te manque, c'est justement tout ce qui ne se voit pas.

Et les chiffres qui sortent depuis le début de cette année sont assez brutaux.

Une étude de Veracode sur plus de 100 modèles de langage a trouvé que 45% du code généré par l'IA introduit des vulnérabilités du top 10 OWASP. Et ce taux n'a pas bougé entre 2025 et début 2026, malgré tous les progrès annoncés sur les benchmarks de performance. Les modèles codent mieux, mais pas plus sécurisé.

Escape. tech a scanné plus de 1400 applications vibe-codées en production. 65% avaient des problèmes de sécurité, 58% contenaient au moins une vulnérabilité critique, avec plus de 400 secrets exposés et 175 cas de données personnelles accessibles publiquement, y compris des informations bancaires.

Et Georgia Tech suit le phénomène en temps réel avec son projet Vibe Security Radar. Six CVE attribuées à du code généré par IA en janvier 2026. Quinze en février. Trente-cinq en mars. Les chercheurs estiment que le vrai chiffre est cinq à dix fois plus élevé, parce que la plupart des outils ne laissent aucune trace identifiable dans les commits.

Mais celui qui devrait vraiment vous parler, à vous qui utilisez Supabase, c'est le CVE-2025-48757.

Lovable générait des schémas Supabase sans activer les Row Level Security. Résultat, sur un scan de 1645 applications construites avec l'outil, les chercheurs ont trouvé 303 endpoints vulnérables répartis sur 170 applications. Soit environ 10% de la plateforme, avec des bases de données ouvertes en lecture à n'importe qui sur internet.

Vous voyez le problème ? Les RLS, c'est une couche de sécurité que vous devez activer et configurer explicitement. L'IA a généré une application qui fonctionnait parfaitement en apparence. Le formulaire marchait et Les données s'affichaient.

Sauf que n'importe qui pouvait lire toute la base.

Et quelqu'un qui ne comprend pas ce qu'est une politique RLS ne peut pas repérer ce trou. Il ne sait même pas qu'il devrait chercher quelque chose.

C'est exactement ça le vrai problème du vibecoding. Ce n'est pas que l'IA écrit du mauvais code. C'est qu'elle écrit du code qui fonctionne, ce qui donne une fausse confiance totale à quelqu'un qui n'a pas les moyens de vérifier ce qui manque.

Et là je vais préciser une chose, parce que je ne veux pas qu'on me fasse dire ce que je n'ai pas dit.

J'utilise Claude Code tous les jours. Ces chiffres ne disent pas d'arrêter d'utiliser l'IA. Ils disent que l'IA génère par défaut du code fonctionnel, pas du code sécurisé, et que quelqu'un doit combler cette différence.

Un développeur qui maîtrise ses fondamentaux sait qu'il faut activer les RLS, valider les entrées côté serveur, ne jamais laisser une clé API dans le code client. Il demande explicitement ces choses à l'IA, et surtout il vérifie qu'elles sont bien là.

Un vibecodeur absolu ne le sait pas. Donc il ne le demande pas. Et l'IA ne le propose pas spontanément.

L'étude la plus parlante là-dessus vient de Carnegie Mellon. Sur des tâches réelles, seulement une solution générée sur dix était à la fois fonctionnelle et sécurisée. Et ajouter des consignes de sécurité dans le prompt ne réglait pas le problème.

Donc non, ça ne se corrige pas juste avec un meilleur prompt. Ça se corrige avec quelqu'un qui sait ce qu'il regarde.

Vous avez déjà audité la sécurité d'un projet généré par IA ? 👇

Abonne-toi à AfroCode Lab pour la suite 🔔

Si vous décidez de faire de la programmation votre profession, arrêtez de déambuler entre plusieurs langages.

Choisissez-en un et maîtrisez-le vraiment.

Vous avez quelqu'un qui a des notions en Python, en JavaScript, en PHP, un peu de Java aussi parce qu'il a suivi trois tutoriels dessus. Sur le papier ça impressionne.

Mais dans les faits il ne maîtrise rien. Il connaît la syntaxe de base de chaque langage et rien de plus. Il peut écrire une boucle et déclarer une variable partout, mais il n'a jamais poussé assez loin dans un seul écosystème pour comprendre ce qui se passe vraiment en dessous.

Alors quand il trouve un vrai projet, il est incapable de le porter jusqu'au bout. Il est incapable de choisir une architecture parce qu'il n'en a jamais appliqué une sérieusement. Incapable de déboguer une erreur qui sort des cas classiques du tutoriel. Incapable d'optimiser quoi que ce soit parce qu'il ne connaît pas les mécanismes internes de son langage. Et incapable de dire au client combien de temps ça va prendre, parce qu'il n'a jamais mesuré son propre rythme sur une technologie précise.

Il commence, il galère, et à la Fin il abandonne. Et au lieu de se remettre en question il retourne apprendre un nouveau langage en pensant que le problème venait du précédent.

Alors bossez sur un seul écosystème. Vraiment à fond. Jusqu'à connaître ses forces, ses limites, ses pièges, ses bonnes pratiques, et surtout jusqu'à avoir livré de vrais projets avec.

Moi c'est ce que j'ai fait avec Dart et Flutter(je suis un full Dart). J'ai arrêté de regarder ailleurs pendant longtemps. Et ce que ça m'a donné, c'est une profondeur que je n'aurais jamais eue en survolant cinq technologies en même temps.

Maintenant je vais nuancer, parce que je ne veux pas qu'on me fasse dire ce que je n'ai pas dit.

Se spécialiser ne veut pas dire s'enfermer à vie. Ça veut dire aller assez profond une première fois pour comprendre les concepts qui sont vraiment universels. L'architecture. La modélisation. La gestion d'état. Les patterns. Ces choses-là ne sont pas liées à un langage. Une fois que vous les possédez dans un écosystème, apprendre un deuxième langage devient beaucoup plus rapide, parce que vous n'apprenez plus que la syntaxe.

C'est exactement l'inverse de commencer par cinq syntaxes sans jamais posséder les concepts.

Il n'y a pas de bonne ou de mauvaise technologie. Il y a juste des développeurs qui vont assez profond pour en tirer quelque chose, et d'autres qui restent en surface partout et n'arrivent nulle part.

Choisissez la vôtre. Et restez-y assez longtemps pour qu'elle vous rende ce que vous y avez investi.

Vous, vous êtes concentré sur une seule technologie ou vous touchez encore à tout ? 👇

Abonne-toi à AfroCode Lab pour la suite 🔔

Flutter et React Native, à eux deux, c'est plus de 80% de toutes les applications cross-platform du monde.

Ça équivaut à Huit applications sur dix dans le monde. Ensuite Tout le reste se partage les miettes.

Et quand on regarde ce chiffre de près, on comprend quelque chose d'important sur l'état réel du marché aujourd'hui.

Flutter tourne autour de 46% des développeurs cross-platform,

React Native autour de 35%.

Derrière eux, Kotlin Multiplatform monte fort avec une adoption passée d'environ 7% en 2024 à 18% en 2025,
NET MAUI reste cantonné aux entreprises déjà sur l'écosystème Microsoft, et Ionic continue doucement de reculer. Xamarin, lui, est en fin de vie.

Le débat cross-platform contre natif est terminé. Il n'existe plus. La question n'est plus de savoir si on peut construire des applications sérieuses avec un seul code, la réponse est oui depuis longtemps, et le marché a tranché massivement.

La vraie question maintenant c'est laquelle des deux correspond à votre situation. Votre équipe vient du web et maîtrise React ? React Native est un excellent choix. Vous voulez une interface identique partout, du mobile au desktop en passant par le web, avec un seul langage ? Flutter.

Et si vous modernisez une application native existante sans vouloir tout réécrire, regardez sérieusement du côté de Kotlin Multiplatform.

Il n'y a pas de vainqueur universel. Il y a le bon choix selon votre contexte, votre équipe et votre projet.

Mais une chose est sûre, choisir de rester uniquement en natif pur aujourd'hui, sans raison technique précise derrière, c'est se compliquer la vie volontairement.

Vous êtes dans quel camp, Flutter, React Native ou autre chose ? 👇

Abonne-toi à AfroCode Lab pour la suite 🔔

En matière de cross-platform, Flutter reste numéro un.

Vous savez qu'aujourd'hui, pour développer une application, vous avez globalement trois chemins possibles.

Le natif pur d'abord. Vous utilisez soit le Kotlin ou Java pour Android, et Swift pour iOS. Avec du native pure vous avez les Performances maximales, et surtout l'accès total aux API du système, mais le souci est que vous avez deux codebases séparées, parfois deux équipes ou deux compétences à maintenir en parallèle. Chaque fonctionnalité, vous la développez deux fois.

Le cross-platform ensuite. Vous avez des technologies comme React Native, Flutter, Kotlin Multiplatform. Ici c'est Un seul code, plusieurs plateformes ciblées.

Et le web progressif(PWA ) enfin, où votre application vit dans le navigateur avec toutes les limites que ça implique côté accès matériel.

Alors pourquoi je continue de dire que Flutter domine dans la deuxième catégorie ?

D'abord parce qu'il est le seul à réellement tenir la promesse "un seul code, partout". Android, iOS, web, Windows, macOS, Linux. Avec Flutter cesyt Une seule commande de compilation et votre solution existe ailleurs. J'en ai fait l'expérience concrètement, compiler la version web d'un projet mobile ou web en desktop en quelques secondes, sans réécrire une seule ligne.

Ensuite parce que Flutter contrôle son propre moteur de rendu. Il ne dépend pas des composants natifs de chaque plateforme, il dessine tout lui-même. À la fin vs aurez votre interface identique au pixel près sur Android et sur iOS,web et même desktop, et vos animations tournent de façon stable sans dépendre de ce que chaque système veut bien vous offrir. Sur des applications riches en animations, c'est encore aujourd'hui ce qui se fait de mieux en cross-platform.

Et surtout que Dart compile en code machine natif ARM et x64 pour la production. Pas d'interprétation à l'exécution, du vrai code natif qui parle directement au processeur.

Maintenant je vais être honnête, parce que je ne veux pas tomber dans le fanatisme aveugle.

il n'y a pas de vainqueur universel. Il y a le bon choix selon votre contexte.

Mais si votre besoin c'est une seule équipe, une seule base de code, une interface cohérente partout, et la possibilité de livrer sur mobile, web et desktop sans changer d'écosystème, alors Flutter reste devant. Et c'est exactement le contexte de la majorité des projets sur lesquels on travaille ici.

Un seul cerveau. Six plateformes. Zéro duplication de travail.

Vous êtes sur quoi de votre côté, Flutter, React Native ou KMP ? 👇

Abonne-toi à AfroCode Lab pour la suite 🔔

Beaucoup de développeurs Flutter ne savent même pas qu'on peut écrire tout son backend en Dart.

Et pourtant Dart dispose d'un écosystème mature, avec plusieurs options sérieuses selon ce que tu construis. Le problème c'est que personne n'en parle vraiment dans nos communautés francophones. On a tendance à sauter directement sur Firebase ou Supabase sans jamais se demander si on pourrait pas juste rester dans le langage qu'on maîtrise déjà.

Alors voilà le tour complet des technologies backend en Dart aujourd'hui.

👉 D'abord il y a Shelf

C'est la brique fondamentale, maintenue directement par l'équipe Dart elle-même. Un système de middleware modulaire où tu construis tout toi-même. Le routeur, l'authentification, la gestion des erreurs, tout est à assembler à la main.

C'est bas niveau, tu contrôles absolument tout, mais tu écris aussi absolument tout. Si tu veux comprendre en profondeur comment fonctionne un serveur HTTP, c'est parfait. Pour livrer un projet client rapidement, c'est beaucoup de travail pour rien.

👉Dart Frog

Créé par Very Good Ventures, construit par-dessus Shelf. C'est un peu l'Express.js du monde Dart, minimaliste et rapide.

Sa particularité c'est le routing basé sur les fichiers, exactement comme Next.js. Tu crées un fichier dans le dossier routes, tu exportes une fonction onRequest, et ton endpoint existe. Ta structure de dossiers définit directement tes URLs.

Il ne t'impose aucune base de données. MongoDB, PostgreSQL, Firebase, tu branches ce que tu veux. Et parce qu'il est léger, il démarre très vite, ce qui le rend excellent pour du serverless sur Cloud Run par exemple.

👉 Ensuite Serverpod, le framework complet

Là on change de catégorie. Serverpod ce n'est pas juste un framework HTTP, c'est un framework full-stack complet.

ORM intégré pour PostgreSQL, système de migrations, authentification prête à l'emploi, cache Redis, WebSockets pour le temps réel, et surtout la génération automatique du code client. Tu définis tes modèles une seule fois, et Serverpod génère les classes correspondantes côté serveur et côté Flutter, avec une sécurité de types de bout en bout.

Bref, si tu veux Une API simple, quelques endpoints, tu veux garder ta liberté totale sur la base de données ? Dart Frog.

Une application complète avec authentification, temps réel, données synchronisées entre serveur et client Flutter ? Serverpod.

Tu veux comprendre les fondations ou tu as un besoin très spécifique que rien ne couvre ? Shelf.

Et ce qui reste vrai dans les trois cas, c'est que tu ne quittes jamais Dart. Même langage, même logique, même écosystème de packages, du widget jusqu'à la requête SQL.

C'est pour ça que je vais construire mon prochain gros projet avec Serverpod, et documenter tout ici. Parce qu'être vraiment autonome comme développeur Flutter, ça passe aussi par savoir construire son propre backend au lieu de dépendre uniquement de plateformes tierces comme supabase ou firebase.

Vous avez déjà testé l'un de ces trois ? 👇

Abonne-toi à AfroCode Lab pour la suite 🔔

❌Utilisez correctement les réseaux sociaux❌

Sur ces plateformes, des millions de personnes nous lisent et analysent ce que nous publions. Chaque phrase, chaque prise de position, chaque contenu partagé passe sous le regard de gens qu'on ne connaît même pas, qui se font une opinion de nous rien qu'à travers ça.

Moi personnellement, environ un million de personnes voient mes publications chaque mois.

Un million, ce n'est pas rien. C'est un million de regards différents, un million de jugements possibles, un million d'occasions de construire ou de détruire une crédibilité qu'on met des mois à bâtir.

Plusieurs personnes m'écrivent chaque jour. En moyenne une vingtaine par jour. Certains pour demander de l'aide sur leurs projets. D'autres pour des questions sur la monétisation Facebook. D'autres encore pour des partenariats, ou pour rejoindre une formation.

Et tout ça prouve une seule chose, la force réelle des réseaux sociaux quand on les utilise avec intention. Ce n'est pas juste un endroit où on poste pour se défouler ou suivre une tendance du moment. C'est un espace public où ta réputation professionnelle se construit, publication après publication, souvent sans que tu t'en rendes compte sur le moment.

Alors réfléchissez chaque fois avant de publier, parce que vos publications peuvent vous ouvrir des portes que vous n'auriez jamais imaginées, tout comme elles peuvent vous en fermer si vous les prenez à la légère.

Si vous me suivez depuis longtemps, vous pouvez témoigner que je n'ai jamais improvisé ce que je partage ici. Chaque post technique, chaque prise de position, chaque anecdote personnelle, c'est réfléchi, parce que je sais qui me lit et ce que ça représente derrière.

Alors la prochaine fois que vous hésitez à publier quelque chose, ou au contraire que vous publiez sans réfléchir juste pour "faire du contenu", posez-vous la question. Qu'est-ce que ça dit de moi, et qui est en train de me lire en ce moment même ?

Si vous avez lu jusqu'à la fin. Je serai heureux si vous laissez un petit 👍

Et surtout abonne-toi à AfroCode Lab si tu veux continuer à apprendre à construire une vraie présence en ligne 🔔

l'IA va remplacer les architectes 🥱

StatelessWidget et StatefulWidget, c'est la toute première décision que tu prends quand tu crées un widget Flutter. Et beaucoup de débutants la prennent au hasard, sans vraiment comprendre ce qui doit guider ce choix.

Un StatelessWidget c'est un widget qui ne change jamais tout seul une fois construit. Donc Tu lui donnes des données au moment de sa création, il les affiche, point final. Si ces données changent, c'est le parent qui doit reconstruire le widget avec les nouvelles valeurs. Le widget lui-même n'a aucune mémoire interne, aucun état à gérer.

Un simple texte, une icône, un bouton dont le comportement dépend uniquement de ce qu'on lui passe en paramètre, c'est typiquement un StatelessWidget. Il naît, il affiche, il ne bouge plus tant que personne ne le reconstruit depuis l'extérieur.

Un StatefulWidget par contre a une mémoire. Il possède un objet State associé qui peut changer dans le temps, indépendamment du parent. Et quand tu appelles setState à l'intérieur, Flutter sait qu'il doit reconstruire ce widget précis pour refléter le nouvel état.

Une checkbox qu'on coche. Un compteur qui s'incrémente. Un champ de texte qui garde ce que l'utilisateur tape. Tout ce qui doit se souvenir de quelque chose et réagir à une interaction directe, c'est un StatefulWidget.

Parfois il y a Des développeurs qui mettent tout en StatefulWidget par réflexe, même des widgets qui n'ont strictement rien à mémoriser. Et dans ce cas précis, Flutter garde en mémoire des objets State inutiles, et parfois ça complique la lisibilité du code pour rien et les performances suivent la même pente si le projet grandit sans discipline.

Genre, vous comprenez vous, un écran entier qui doit se reconstruire en entier juste parce qu'une seule checkbox tout en bas a changé d'état ?

C'est pourtant ce qui arrive quand tu poses ton setState trop haut dans l'arbre, sur tout l'écran au lieu de l'isoler juste sur le petit widget concerné. Tout ce qui est en dessous repart, même les parties qui n'ont strictement rien à voir avec ce changement. Et sur un widget mal structuré, un setState mal placé peut déclencher ça un peu partout, difficile à tracer quand le projet grossit.

La question à te poser à chaque fois que tu crées un widget, c'est simple. Est-ce que ce widget a besoin de se souvenir de quelque chose et de changer par lui-même après sa construction ? Si la réponse est non, StatelessWidget, toujours. Si la réponse est oui, StatefulWidget.

Et avec Riverpod ou un autre gestionnaire d'état, tu remarqueras que la majorité de tes widgets redeviennent des StatelessWidget, parce que l'état vit ailleurs, dans un provider, pas dans le widget lui-même. Le StatefulWidget devient alors l'exception, pas la règle.

Vous saviez déjà faire clairement la différence entre les deux ? 👇

Abonne-toi à AfroCode Lab pour plus de contenu sur Flutter 🔔

Le métier de développeur n'existe plus. (C'est le PDG de Mistral qui l'a dit)

Le 12 mai dernier, devant l'Assemblée nationale française, Arthur Mensch, cofondateur et patron de Mistral AI, a lâché une phrase qui a fait le tour du web tech.

"Aujourd'hui, les ingénieurs chez Mistral n'écrivent plus de lignes de code. Vous n'êtes plus un artisan, vous êtes un manager."

Et il a ajouté : "des gains de productivité qui donnent le vertige, jusqu'à dix ou vingt fois plus vite quand on travaille seul".

Le patron de la première licorne française de l'IA, auditionné devant des députés, qui affirme que ses propres ingénieurs ne codent quasiment plus. Les agents IA s'en occupent. Le développeur passe du rôle d'artisan à celui de manager qui oriente, vérifie, corrige.

Depuis que j'ai entendu ça, et pas mal d'autres sorties similaires venant d'autres grands noms de l'IA, je me suis remis en question sérieusement. Et j'ai compris qu'il fallait vraiment réformer ma manière de penser mon métier.

Je ne suis plus ce développeur d'avant qui passait des heures à taper chaque ligne à la main, fier de la quantité de code produit dans une journée. Ce temps-là est en train de se refermer, doucement mais sûrement.

Je trouve qu'écrire du code devient de plus en plus secondaire dans ce qui définit un bon développeur.

Les IA le font vraiment très bien, souvent mieux et plus vite que moi sur des tâches d'exécution pure. Et ce que vous devez comprendre c'est que le rôle d'un développeur ne s'est jamais vraiment limité à écrire du code. Le code, c'est juste un aspect, une conséquence visible d'une réflexion plus large. Et aujourd'hui l'IA gère cet aspect-là très bien.

La posture à adopter maintenant, c'est celle du manager technique dont parle Mensch. Celui qui comprend le problème en profondeur, qui découpe la tâche intelligemment, qui vérifie que ce que l'IA produit tient réellement debout, et qui sait intervenir quand ça part dans le mur.

Mais je ne dis pas que ça ne sert plus à rien d'apprendre à coder. Je pense plutôt qu'il faut apprendre en réfléchissant sur comment on architecture, comment on modélise, comment on structure un problème avant même de penser à l'exécution. Ces bases-là, c'est justement ce qui te permet de devenir un bon manager de tes propres agents IA, et pas quelqu'un qui subit leurs résultats sans pouvoir les évaluer. Ce que font certains vibecodeurs

Donc penser que l'IA va tuer le métier de développeur, c'est se tromper de diagnostic. Elle ne tue pas le métier. Elle tue une seule façon de l'exercer, celle où la valeur se mesurait à la vitesse de frappe. La vraie question aujourd'hui, ce n'est plus est-ce que tu sais coder. C'est est-ce que tu sais penser assez juste pour diriger une IA qui, elle, code déjà très bien.

Vous en pensez quoi, Mensch a raison ou il exagère la situation ? 👇

Abonne-toi à AfroCode Lab pour la suite 🔔