Waly

Cloud Resource Manager : provisionner de l'AWS depuis une interface web

2026-04-25T00:00:00Z

Dans le cadre d'un examen de Cloud Computing, j'avais une semaine pour livrer un projet qui touche à AWS. L'énoncé était assez libre — l'essentiel était de démontrer qu'on sait provisionner des ressources cloud. J'aurais pu faire un script shell ou un simple README avec des captures. J'ai préféré construire une vraie interface.

Le projet : une application web qui permet de créer et supprimer des ressources AWS (EC2, S3, RDS) depuis un dashboard, sans jamais toucher à la console AWS. En coulisses, chaque action déclenche un pipeline GitLab CI/CD qui exécute Terraform.

Le repo : gitlab.com/sir-kane/exam-cloud

La stack

Pour l'interface, j'ai choisi Laravel 11 + Filament 3 + Livewire 3. Filament génère un admin panel propre très vite, et Livewire permet de faire des composants réactifs sans écrire de JS. Pour l'infra : Terraform côté IaC, GitLab CI/CD comme moteur d'exécution, et AWS comme target.

Le flux est simple : l'utilisateur remplit un formulaire → Laravel appelle l'API GitLab → un runner CI exécute Terraform → la ressource apparaît dans AWS.

UI Filament → GitLabPipelineService → GitLab API → CI Runner (Terraform) → AWS

Déclencher le pipeline à la demande

Le truc qui m'a plu dans cette architecture, c'est que le pipeline n'est pas déclenché par un push. Il est déclenché par l'application, via l'API GitLab, avec des variables qui décrivent la ressource à créer.

// app/Services/GitLabPipelineService.php
Http::withHeaders(['PRIVATE-TOKEN' => $this->token])
    ->post("{$gitlabUrl}/api/v4/projects/{$projectId}/pipeline", [
        'ref'       => 'main',
        'variables' => [
            ['key' => 'TF_ACTION',       'value' => 'apply'],
            ['key' => 'RESOURCE_TYPE',   'value' => 'ec2'],
            ['key' => 'RESOURCE_NAME',   'value' => 'mon-serveur'],
            ['key' => 'RESOURCE_REGION', 'value' => 'us-east-1'],
            // ...
        ],
    ]);

Dans le .gitlab-ci.yml, le job apply ne s'exécute que si $TF_ACTION == "apply". Pour chaque type de ressource, Terraform reçoit les variables et n'instancie que ce qui est demandé grâce à un count conditionnel :

locals {
  is_ec2 = var.resource_type == "ec2"
  is_s3  = var.resource_type == "s3"
  is_rds = var.resource_type == "rds"
}

resource "aws_instance" "this" {
  count = local.is_ec2 ? 1 : 0
  # ...
}

Un seul terraform apply, trois types de ressources, zéro duplication.

Le piège du state Terraform pour la suppression

C'est là où j'ai passé le plus de temps.

Pour créer une ressource, Terraform est parfait. Pour la supprimer, il y a un problème : le runner GitLab est éphémère. Chaque pipeline repart d'un état vide. Un job terraform destroy sur un state vide ne trouve rien à supprimer — et il ne fait rien.

La solution : pour le destroy, j'abandonne Terraform et j'utilise l'AWS CLI directement. Chaque ressource a été créée avec un tag ResourceId (l'ID en base de l'application). Le job de suppression retrouve la ressource par ce tag et la supprime.

# destroy-ec2
INSTANCE_ID=$(aws ec2 describe-instances \
  --region "$RESOURCE_REGION" \
  --filters "Name=tag:ResourceId,Values=${RESOURCE_ID}" \
            "Name=instance-state-name,Values=running,stopped,pending,stopping" \
  --query 'Reservations[0].Instances[0].InstanceId' --output text)

aws ec2 terminate-instances --region "$RESOURCE_REGION" --instance-ids "$INSTANCE_ID"

C'est moins élégant que du Terraform pur, mais c'est robuste et ça marche indépendamment de l'état du runner.

Deux autres problèmes rencontrés

Les noms de buckets S3 sont globaux. Un nom comme mon-bucket-test peut déjà appartenir à n'importe quel autre compte AWS dans le monde. Pour garantir l'unicité, j'inclus l'Account ID dans le nom :

bucket = "${var.resource_slug}-${data.aws_caller_identity.current.account_id}-${var.resource_id}"

Les identifiants RDS ont des contraintes strictes. AWS refuse tout ce qui n'est pas minuscules + chiffres + tirets. Un nom avec des espaces ou des underscores lève une erreur de validation immédiate. Il faut normaliser le slug côté application avant de l'envoyer au pipeline.

Trois formulaires et un chatbot

L'interface propose deux façons d'arriver au même résultat.

La première : trois formulaires Filament, un par type de ressource (EC2, S3, RDS). Chacun expose les paramètres propres à son type — région et instance type pour EC2, niveau d'accès ACL pour S3, moteur et classe d'instance pour RDS. Formulaire soumis → pipeline déclenché.

La deuxième : un assistant Livewire en mode conversationnel. Même logique, même résultat final, mais l'utilisateur avance étape par étape via des boutons. Il choisit d'abord le type de ressource, puis la région, puis les options spécifiques, et confirme à la fin. Ça ressemble à un chatbot mais il n'y a aucun LLM derrière — juste un composant Livewire avec une machine d'états.

L'idée c'était de proposer une UX plus accessible pour quelqu'un qui ne sait pas ce qu'est un t3.micro, sans dupliquer la logique métier.

Ce que j'en retiens

Ce projet m'a confirmé que GitLab CI/CD peut très bien servir de moteur d'exécution de tâches, pas juste de pipeline de déploiement. Déclencher un pipeline à la demande avec des variables, c'est une approche propre pour orchestrer de l'IaC depuis une application métier.

Le vrai enseignement côté Terraform : le state, c'est tout. Sans state persistant (S3 backend, Terraform Cloud…), le destroy devient un cas à gérer à part. C'est quelque chose que je vais intégrer dès le début sur mes prochains projets.

Pour aller plus loin

Dépôt GitLab : gitlab.com/sir-kane/exam-cloud
Documentation Terraform AWS Provider
API GitLab – Trigger a pipeline

Talk: L'outillage JavaScript au DevFest Yamoussoukro

2025-12-13T00:00:00Z


Date	13 décembre 2025
Lieu	Stade Charles Konan Banny, Yamoussoukro — DevFest Yamoussoukro 2025

J'avais déjà présenté ce talk sur l'outillage JavaScript au DevFest Dakar en janvier. Quand l'opportunité s'est présentée de le faire à Yamoussoukro, j'ai pas hésité.

Faire le déplacement jusqu'en Côte d'Ivoire, c'était l'occasion de rencontrer des communautés de développeurs qu'on ne croise pas habituellement. On parle souvent de la scène tech en Afrique de l'Ouest comme d'un tout, mais chaque ville a sa dynamique propre, ses centres d'intérêt, ses questions. Les échanges qu'on a eus surtout autour du développement Front m'ont autant apporté que le talk lui-même.

J'ai beaucoup aimé cette journée.

Le contenu du talk couvre 4 mécanismes fondamentaux derrière les bundlers modernes (Webpack, Vite, Rollup...) :

Minification — réduire le poids des fichiers en supprimant les commentaires, espaces et en renommant les variables. Un fichier passe de 228 à 98 caractères, le comportement reste identique.

Bundling — concaténer plusieurs modules en un seul fichier pour limiter les requêtes HTTP.

Tree Shaking — supprimer le code non utilisé. Ça ne fonctionne qu'avec des ES modules (exports nommés). L'exemple qui illustre bien : moment.js (~250 Ko) vs day.js (~7 Ko) pour le même usage de dates.

Code Splitting — charger les fichiers à la demande plutôt que tout d'un coup. La primitive native, c'est l'import dynamique :

document.querySelector('button').addEventListener("click", async () => {
  const { hello } = await import("./utils/hello.js");
  console.log(hello("Sir Kane"));
});

Le détail complet de chaque concept est dans le compte rendu du DevFest Dakar.

Pour aller plus loin

Les slides : ouvrir en plein écran
Le code source des démos : github.com/sir-kain/js-tools
Code splitting avec les directives Astro
Bundlephobia — voir la taille d'un package npm

Talk: Le Lazy-Loading (amélioration des perfs)

2025-12-05T00:00:00Z


Date	5 décembre 2025
Lieu	TheCodingMachine · en ligne
Demo	sir-kain.github.io/lazy-loading

Le lazy loading, c'est une technique pour charger efficacement du contenu sur une page web. Ça répond à une seule question : quand charger ? Pas quoi, pas comment — juste quand.

L'idée : ne charger un élément que quand il est sur le point d'être visible. Pas la version "installe cette lib et ça marche", mais la version "voilà ce que le navigateur sait faire tout seul".

Pourquoi s'en préoccuper ?

Une page web charge tout ce qu'elle trouve dans le HTML, même ce qui est à 3 scrolls de distance et que l'utilisateur ne verra peut-être jamais. C'est du réseau gaspillé, du temps de chargement rallongé, et des métriques Lighthouse qui souffrent (FCP, LCP, Speed Index...).

Les images — le cas le plus simple

`loading="lazy"`, c'est tout

La bonne nouvelle, c'est que pour les images, le navigateur fait le travail depuis des années. Un seul attribut suffit :

<img src="mon-image.jpg" alt="a ne jamais oublier" loading="lazy">

Pas de JavaScript. Pas de bibliothèque. Juste un attribut HTML natif, supporté partout. L'image ne sera téléchargée que lorsqu'elle approche du viewport.

La balise `<picture>` : afficher VS bien afficher

L'autre chose que j'ai montrée, c'est la différence entre "afficher une image" et "bien afficher une image". Une <img> basique envoie la même image JPEG à tout le monde — mobile, desktop, connexion lente, écran Retina. C'est rarement optimal.

La balise <picture> permet de laisser le navigateur choisir le meilleur format et la meilleure taille selon le contexte :

<picture>
  <source
    type="image/avif"
    srcset="/image-400.avif 400w, /image-800.avif 800w, /image-1200.avif 1200w"
    sizes="(max-width: 640px) 100vw, (max-width: 1024px) 50vw, 800px"
  />
  <source
    type="image/webp"
    srcset="/image-400.webp 400w, /image-800.webp 800w, /image-1200.webp 1200w"
    sizes="(max-width: 640px) 100vw, (max-width: 1024px) 50vw, 800px"
  />
  <img
    src="/image-800.jpeg"
    srcset="/image-400.jpeg 400w, /image-800.jpeg 800w"
    sizes="(max-width: 640px) 100vw, (max-width: 1024px) 50vw, 800px"
    alt="Description de l'image"
    width="1600"
    height="900"
    loading="lazy"
    decoding="async"
  />
</picture>

Le navigateur descend la liste : si AVIF est supporté, il prend AVIF. Sinon WebP. Sinon JPEG. Il choisit aussi la bonne taille selon la largeur d'affichage. Et loading="lazy" + decoding="async" sur le <img> intérieur restent valides dans ce contexte.

Les contenus lourds — l'IntersectionObserver

Pour tout ce qui n'est pas une image (iframes, composants lourds, vidéos, sections entières), il n'y a pas d'attribut magique. Mais il y a une API native : IntersectionObserver.

Son rôle : détecter quand un élément entre dans le viewport, sans polling, sans événement scroll chronophage.

const observer = new IntersectionObserver((entries) => {
  entries.forEach(entry => {
    if (entry.isIntersecting) {
      // charger ici
    }
  });
}, {
  threshold: 0.5,
  rootMargin: '0px'
});

document.querySelectorAll('.ma-class').forEach(el => {
  observer.observe(el);
});

threshold: 0.5 signifie que le callback se déclenche quand 50% de l'élément est visible. rootMargin permet d'anticiper le chargement avant même que l'élément soit visible (par exemple '200px' pour charger 200px avant l'arrivée dans le viewport).

C'est cette API qui est derrière la plupart des implémentations modernes de lazy loading — y compris dans des frameworks comme Vue, React ou Angular.

La démo

Pour illustrer tout ça, j'ai fait une petite page de démo : sir-kain.github.io/lazy-loading

Deux choses à observer :

Images adaptatives : l'image mobile ne charge que sur mobile, l'image desktop seulement sur desktop — grâce à <picture> et ses <source> avec media queries.
IntersectionObserver en action : chaque section affiche un message dans la console (Partie 1 affichée, Partie 2 affichée...) uniquement quand elle devient visible dans le viewport. Ouvre les DevTools et fais défiler — tu verras les logs apparaître au bon moment.

Pour aller plus loin

Les slides : ouvrir en plein écran
La démo : sir-kain.github.io/lazy-loading
Le code source : github.com/sir-kain/lazy-loading
loading sur MDN
<picture> sur MDN
Intersection Observer API sur MDN
Métriques Lighthouse (FCP, LCP, CLS...)

Talk: Chrome built-in AI APIs

2025-10-25T00:00:00Z


Date	25 octobre 2025
Lieu	FST de l'UCAD, Dakar — Hacktoberfest Galsen Dev

Demo : chrome-ia.netlify.app

Le 25 octobre 2025, Galsen Dev organisait son Hacktoberfest à la FST de l'UCAD. J'ai eu un slot pour présenter quelque chose que je suivais depuis un moment dans ma veille : les APIs IA intégrées directement dans Chrome.

Le sujet a bien résonné dans la salle, alors j'en fais un résumé ici.

Prérequis indispensable : avant tout, il faut rejoindre le Early Preview Program (EPP). Sans ça, les APIs ne sont tout simplement pas disponibles dans le navigateur.

L'idée centrale

Aujourd'hui, intégrer de l'IA dans une app web passe forcément par un serveur : on envoie la requête, le modèle tourne quelque part dans le cloud, la réponse revient. Ça marche, mais ça implique de la latence, des coûts, une connexion internet — et les données de l'utilisateur quittent son appareil.

Ce que Google est en train d'expérimenter, c'est de faire tourner Gemini Nano directement dans Chrome. Pas dans le cloud. Dans le navigateur, sur la machine de l'utilisateur. Avec trois bénéfices immédiats : privé, offline, performant.

La taille exacte du modèle peut varier au fil des mises à jour de Chrome — actuellement environ 4 Go. Pour voir la version installée sur votre machine, rendez-vous sur chrome://on-device-internals.

Ce que j'ai montré

La partie qui a le plus intrigué la salle, c'est la simplicité du code. Appeler un LLM depuis le navigateur, ça ressemble à ça :

const session = await LanguageModel.create({
  expectedInputs: [{ type: "text", languages: ["en"] }],
  expectedOutputs: [{ type: "text", languages: ["en"] }]
});

const response = await session.prompt("Explain quantum computing like I'm five.");

Pas de clé API. Pas de requête HTTP. Le modèle répond directement.

Il y a aussi une Translator API, une Summarizer API, un Language Detector... Autant de fonctionnalités exposées nativement, sans dépendance externe.

Ce qui m'a convaincu que c'est une direction sérieuse : Bluesky l'utilise déjà pour traduire les posts. Thomas Steiner (@tomayac) en a parlé ici.

Ce qu'il faut retenir

C'est encore en early preview, pas activé par défaut. Donc pas question de l'utiliser en prod sans fallback. Mais c'est une direction qui mérite d'être suivie de près, surtout pour ceux qui construisent des apps où la confidentialité et le mode offline comptent.

Sur la standardisation : Google a déjà proposé ces APIs à la communauté web et les a soumises au W3C et au Web Incubator Community Group (WICG) pour discussion. L'objectif à terme est qu'elles fonctionnent dans tous les navigateurs, pas seulement Chrome.

Pour aller plus loin

Les slides : ouvrir en plein écran
Ma démo interactive : chrome-ia.netlify.app (Chrome requis + early preview)
Le code source : github.com/sir-kain/chrome-ia
Rejoindre le programme early preview : goo.gle/chrome-ai-dev-preview-join
Plus de démos officielles à explorer : chrome.dev/web-ai-demos

Talk: L'outillage JavaScript - Les bundler

2025-01-13T00:00:00Z


Date	13 janvier 2025
Lieu	Hôtel Sea Plaza, Dakar — DevFest Dakar

Quand on parle d'outillage JavaScript, on parle souvent de Webpack, Vite, Rollup... sans vraiment savoir ce qu'ils font sous le capot. Au DevFest Dakar, j'ai pris le parti de décortiquer les 4 mécanismes fondamentaux derrière ces outils.

Minification

Objectif : réduire le poids des fichiers à charger par le navigateur.

Le navigateur n'a pas besoin de code lisible. Il n'a besoin que de code fonctionnel. La minification exploite ça en appliquant plusieurs transformations successives :

Suppression des commentaires, espaces et sauts de ligne inutiles
Renommage des variables en noms courts (firstNumber → f)
Réécriture avec des opérateurs plus compacts (ternaires, etc.)

Résultat concret sur un fichier math.js : 228 caractères → 98 caractères, sans changer le comportement.

// Avant (math.js) — 228 chars
export function add(firstNumber, secondNumber) {
  return firstNumber + secondNumber;
}
// Recursivity
export function factorial(number) {
  if (number === 0) {
    return 1;
  }
  return number * factorial(number - 1);
}

// Après (math.min.js) — 98 chars
export function add(f,s){return f+s}export function factorial(n){return n===0?1:n*factorial(n-1)}

Les outils du marché, du plus lent au plus rapide : Terser (JS, 2018), SWC (Rust, 2019), Esbuild (Go, 2020).

"Don't minify what you don't need. Minification without tree-shaking is like compressing a trash can without taking out the garbage." — Philip Walton

Bundling

Objectif : concaténer plusieurs fichiers en un seul.

Un projet JS moderne est découpé en modules. Sans bundler, le navigateur doit faire une requête HTTP par fichier. Le bundling rassemble tout en un bundle.js unique.

// math.js
export const add = (a, b) => a + b

// index.js
import { add } from './math'
console.log(add(2, 3))

// → bundle.js
const add = (a, b) => a + b
console.log(add(2, 3))

Les import/export disparaissent, le code est inliné. Une seule requête réseau au lieu de deux.

Tree Shaking

Objectif : supprimer le code non utilisé.

Le tree shaking, c'est ce qui fait que si tu importes add depuis un fichier qui exporte aussi subtract, seul add se retrouve dans le bundle final. Mais ça ne fonctionne qu'avec des ES modules (exports nommés), pas avec CommonJS.

// ❌ Non tree shakable — exporte un objet entier
// math.js
const math = { add: (a, b) => a + b, subtract: (a, b) => a - b }
export default math
// index.js — importe tout l'objet même si on n'utilise que add
import math from './math'

// ✅ Tree shakable — exports nommés
// math.js
export const add = (a, b) => a + b
export const subtract = (a, b) => a - b
// index.js — seul add est inclus dans le bundle
import { add } from './math'

Un exemple qui parle : moment.js (~250 Ko) vs day.js (~7 Ko) pour le même usage. La différence vient en grande partie du fait que moment.js n'est pas tree shakable.

Code Splitting

Objectif : charger les fichiers à la demande, pas tous d'un coup.

Le bundling crée un seul fichier — mais si ce fichier fait 2 Mo, l'utilisateur le télécharge entier au premier chargement, même pour les parties qu'il ne verra jamais. Le code splitting inverse la logique : on découpe en plusieurs chunks, chargés uniquement quand on en a besoin.

La primitive native, c'est l'import dynamique :

document.querySelector('button').addEventListener("click", async () => {
  const { hello } = await import("./utils/hello.js");
  console.log(hello("Sir Kane"));
});

Le fichier hello.js n'est téléchargé qu'au clic. Avant ça, zéro requête.

Les frameworks ont leurs propres abstractions par-dessus : defineAsyncComponent en Vue, les client: directives en Astro (client:load, client:idle, client:visible...).

Pour aller plus loin

Les slides : ouvrir en plein écran
Le code source des démos : github.com/sir-kain/js-tools
Code splitting avec les directives Astro
Conf de Hubert Sablonnière sur la compression
Bundlephobia — voir la taille d'un package npm
Métriques LCP sur web.dev

Les combinateurs de promesses en JavaScript

2024-08-18T00:00:00Z

Dès qu'on a plusieurs tâches asynchrones à gérer en parallèle, la question se pose : comment les orchestrer ? C'est là qu'interviennent les combinateurs de promesses. JavaScript en fournit quatre nativement, et chacun a un comportement bien précis.

Pour illustrer ça, j'ai construit un petit showcase avec 3 promesses qui se résolvent ou échouent aléatoirement dans un intervalle de 3 secondes. On peut observer en direct ce que chaque combinateur retourne selon les résultats.

Promise.all

Échoue dès qu'une promesse est rejetée. Sinon, retourne un tableau de tous les résultats.

C'est le combinateur "tout ou rien". Si les 3 promesses réussissent, tu récupères leurs 3 résultats dans l'ordre. Si une seule échoue, tu tombes directement dans le catch — peu importe ce qu'ont fait les autres.

const results = await Promise.all([p1, p2, p3]);
// → [résultat1, résultat2, résultat3]
// ou rejet si l'une échoue

À utiliser quand toutes les tâches sont indispensables — par exemple charger les données d'un utilisateur et ses permissions en même temps. Si l'une échoue, il n'y a rien à afficher.

Promise.any

Se résout dès qu'une promesse réussit. Échoue seulement si toutes sont rejetées.

L'inverse de all en quelque sorte. La première promesse qui réussit gagne, les autres sont ignorées. Si toutes échouent, tu reçois une AggregateError qui regroupe toutes les erreurs.

const result = await Promise.any([p1, p2, p3]);
// → le résultat de la 1ère promesse résolue
// ou AggregateError si toutes échouent

Utile pour des stratégies de fallback — par exemple essayer plusieurs sources de données et prendre la première qui répond.

Promise.race

Se résout ou se rejette en fonction de la première promesse qui se termine, qu'elle réussisse ou échoue.

Là où any attend une réussite, race réagit à n'importe quel résultat — succès ou échec. Le premier arrivé l'emporte.

const result = await Promise.race([p1, p2, p3]);
// → résultat ou erreur de la 1ère promesse terminée

Cas d'usage classique : implémenter un timeout. On met en course la vraie requête contre une promesse qui rejette après N secondes — si la requête est trop lente, le timeout l'emporte.

const timeout = new Promise((_, reject) =>
  setTimeout(() => reject(new Error("Timeout")), 5000)
);
const result = await Promise.race([fetchData(), timeout]);

Promise.allSettled

Se résout toujours. Retourne un tableau avec le statut de chaque promesse, succès ou échec.

Contrairement aux autres, allSettled n'abandonne jamais. Il attend que toutes les promesses soient terminées et te donne un bilan complet — ce qui a réussi, ce qui a échoué, et pourquoi.

const results = await Promise.allSettled([p1, p2, p3]);
// → [
//   { status: "fulfilled", value: ... },
//   { status: "rejected", reason: ... },
//   { status: "fulfilled", value: ... },
// ]

C'est le combinateur le plus "safe". Utile quand les tâches sont indépendantes et qu'on veut traiter chaque résultat même en cas d'échec partiel — envoyer plusieurs notifications, ou déclencher des actions en parallèle sans que l'une bloque les autres.

En résumé

Combinateur	Se résout si...	Échoue si...
`Promise.all`	toutes réussissent	au moins une échoue
`Promise.any`	au moins une réussit	toutes échouent
`Promise.race`	la 1ère se termine (succès)	la 1ère se termine (échec)
`Promise.allSettled`	toujours	jamais

Le code source et le showcase interactif sont dispo sur github.com/sir-kain/promise-combinator — la démo permet de rejouer les scénarios pour voir les résultats en conditions réelles.

Waly

Cloud Resource Manager : provisionner de l'AWS depuis une interface web

La stack

Déclencher le pipeline à la demande

Le piège du state Terraform pour la suppression

Deux autres problèmes rencontrés

Trois formulaires et un chatbot

Ce que j'en retiens

Pour aller plus loin

Talk: L'outillage JavaScript au DevFest Yamoussoukro

Pour aller plus loin

Talk: Le Lazy-Loading (amélioration des perfs)

Pourquoi s'en préoccuper ?

Les images — le cas le plus simple

loading="lazy", c'est tout

La balise <picture> : afficher VS bien afficher

Les contenus lourds — l'IntersectionObserver

La démo

Pour aller plus loin

Talk: Chrome built-in AI APIs

L'idée centrale

Ce que j'ai montré

Ce qu'il faut retenir

Pour aller plus loin

Talk: L'outillage JavaScript - Les bundler

Minification

Bundling

Tree Shaking

Code Splitting

Pour aller plus loin

Les combinateurs de promesses en JavaScript

Promise.all

Promise.any

Promise.race

Promise.allSettled

En résumé

Pour aller plus loin

`loading="lazy"`, c'est tout

La balise `<picture>` : afficher VS bien afficher