DEV Community: Amine Affif

Construire son propre zoom produit : les trois détails qui comptent

Amine Affif — Mon, 02 Nov 2026 07:00:00 +0000

Sur une boutique en ligne, le client ne peut pas toucher le produit. Il ne lui reste que la photo. Si elle ne lui montre pas le détail qu'il cherche, il hésite, et souvent il n'achète pas.

Pour une marque D2C, j'ai développé un zoom produit sur mesure. La fonctionnalité est petite, mais elle porte directement sur la décision d'achat, et je voulais la maîtriser : son comportement, son poids, sa fluidité.

Le principe, dans sa version minimale. Au survol, l'image grossit et le point de zoom suit la souris.

.zoom { overflow: hidden; cursor: zoom-in; }
.zoom img {
  display: block;
  width: 100%;
  transform-origin: var(--x, 50%) var(--y, 50%);
  transition: transform .2s;
}
.zoom:hover img { transform: scale(2); }

zoom.addEventListener("mousemove", (e) => {
  const r = zoom.getBoundingClientRect();
  zoom.style.setProperty("--x", ((e.clientX - r.left) / r.width) * 100 + "%");
  zoom.style.setProperty("--y", ((e.clientY - r.top) / r.height) * 100 + "%");
});

Trois détails qui font la différence :

Une image plus grande que celle affichée. Zoomer sur une miniature donne du flou. Il faut charger la version haute définition.
Pas de survol sur mobile. Un toucher doit activer ou désactiver le zoom, sinon la moitié des visiteurs n'y a pas accès.
Le zoom ne doit rien déplacer. Si le survol décale la page, le visiteur perd sa place et quitte.

C'est une petite fonctionnalité, mais elle se trouve sur le chemin de l'achat, et c'est pour ça que je voulais la maîtriser.

Amine Affif, développeur full-stack à Paris. amineaffif.com

A 500 on every page: two dev servers, one cache folder

Amine Affif — Sun, 01 Nov 2026 07:00:00 +0000

My Next.js dev server suddenly returned a 500 on every page, with this error:

Module not found: Can't resolve
'@vercel/turbopack-next/internal/font/google/font'

It was about a Google font. My first thought was the network. I checked that the font servers answered. They did.

What had changed: I'd run next build while next dev was running. Both write to the same folder, .next. After alternating for a while, it held 281 MB of mixed artifacts, and Turbopack had lost its font import table in there.

Starting on a fresh folder fixed everything. But purging every time isn't a solution. Better to prevent the collision: one folder per use.

In next.config.mjs:

const nextConfig = {
  distDir: process.env.NEXT_DIST_DIR || ".next",
};

In package.json:

"dev": "NEXT_DIST_DIR=.next-dev next dev --turbopack"

The build keeps .next, and a verification build can use a third folder: NEXT_DIST_DIR=.next-verify next build. Remember to add them to .gitignore.

Since then, the dev server and the build no longer step on each other.

Amine Affif, full-stack developer in Paris. amineaffif.com

Un 500 sur toutes les pages : deux serveurs de dev, un seul dossier de cache

Amine Affif — Sat, 31 Oct 2026 07:00:00 +0000

Mon serveur de dev Next.js a soudain renvoyé un 500 sur toutes les pages, avec cette erreur :

Module not found: Can't resolve
'@vercel/turbopack-next/internal/font/google/font'

Elle parlait d'une police Google. J'ai d'abord pensé au réseau. J'ai vérifié que les serveurs de polices répondaient. Ils répondaient.

Ce qui avait changé : j'avais lancé next build pendant que next dev tournait. Les deux écrivent dans le même dossier, .next. À force d'alterner, il pesait 281 Mo d'artefacts mélangés, et Turbopack y avait perdu sa table d'imports de polices.

Démarrer sur un dossier neuf a tout réparé. Mais purger à chaque fois n'est pas une solution. Mieux vaut empêcher la collision : un dossier par usage.

Dans next.config.mjs :

const nextConfig = {
  distDir: process.env.NEXT_DIST_DIR || ".next",
};

Dans package.json :

"dev": "NEXT_DIST_DIR=.next-dev next dev --turbopack"

Le build garde .next, et un build de vérification peut utiliser un troisième dossier : NEXT_DIST_DIR=.next-verify next build. Pense à les ajouter au .gitignore.

Depuis, le serveur de dev et le build ne se marchent plus dessus.

Amine Affif, développeur full-stack à Paris. amineaffif.com

Un seul jeu de données pour mon CV et mon site : fini les dates qui ne concordent pas

Amine Affif — Wed, 28 Oct 2026 07:00:00 +0000

Un lecteur sérieux ouvre ton CV et ton site côte à côte. Si une date ou un intitulé ne concorde pas, c'est la première chose qu'il remarque.

Mon CV en PDF et mon site viennent d'un seul jeu de données : des fichiers TypeScript qui décrivent mes expériences et mes projets. Le site les affiche en React. Le CV est produit par un script qui lit les mêmes fichiers.

Le principe, simplifié :

// content/experience.ts : la seule source
export const experience = [
  { company: "…", start: "2025", end: null, delivered: ["…"] },
];

// scripts/build-cv.mjs : lit le même fichier, produit le HTML, puis le PDF
const experience = extractData("content/experience.ts", "experience");

Deux choix qui comptent.

Lire les données plutôt que compiler le TypeScript. Le script extrait le tableau par lecture. Ça évite de monter une chaîne de build juste pour fabriquer un PDF.

Imprimer depuis Chrome en ligne de commande. Le CV est un HTML mis en page pour une page A4, converti avec --print-to-pdf.

Au quotidien : je corrige une date à un seul endroit, je régénère, et le site comme le PDF sont à jour. Plus de version oubliée dans un coin.

Ça vaut pour un CV, mais l'idée vaut pour tout document qui répète une information : une seule source, plusieurs sorties.

Amine Affif, développeur full-stack à Paris. amineaffif.com

Une landing page pour investisseurs en quelques jours, à partir de photos de téléphone

Amine Affif — Mon, 26 Oct 2026 07:00:00 +0000

Un fondateur avait quelques jours pour présenter son projet à des investisseurs. Un projet ambitieux, mais pour toute matière : quelques photos prises au téléphone.

La contrainte n'était pas la qualité des photos, c'était la date. Attendre un vrai shooting n'était pas une option. J'ai décidé de partir de ce qu'il avait.

J'ai tout pris en charge, seul : le design, le texte, le développement en Next.js. À partir des photos brutes, j'ai retravaillé les visuels, ajouté des rendus 3D et du motion. Puis une landing page complète qui déroule le projet section après section.

Pourquoi une seule personne ? Sur un délai de quelques jours, chaque passage de relais ralentit. Quand le design, le texte et le code sont tenus par la même personne, les décisions se prennent en une phrase, pas en réunion.

La page était prête pour la présentation. Le fondateur a levé les fonds ; la page faisait partie de son dossier.

Sur une page qui doit convaincre, le texte et le visuel pèsent autant que le code. Je les ai traités de la même façon : une section à la fois, chacune avec un seul message.

Amine Affif, développeur full-stack à Paris. amineaffif.com

Why your PDF's text comes out as separate letters

Amine Affif — Sat, 24 Oct 2026 06:00:00 +0000

I generated a PDF from HTML with Chrome on the command line. To the eye, it was perfect. But when I extracted its text with a pdf.js-based tool, my section headings came out like this:

E X P É R I E N C E
STA C K

With pdftotext (poppler), the same words came out whole. Same file, two readings.

I looked inside the PDF. In mine, Chrome doesn't write words but roughly one character per operation: 3,136 text-drawing operations for 3,062 repositioning ones. Every letter is placed absolutely.

My headings had letter-spacing: .13em. Removing the letter spacing made the words come out whole in both tools. I make up for it with font size:

/* before */
h2 { letter-spacing: .13em; font-size: 8.4pt; }

/* after */
h2 { letter-spacing: 0; font-size: 9pt; }

A PDF isn't text, it's a list of positioned glyphs. That it looks right to the eye doesn't guarantee a machine can read it.

If your PDF's text needs to be found, copied or indexed, test it with at least two extractors. One alone can tell you everything is fine.

Amine Affif, full-stack developer in Paris. amineaffif.com

Pourquoi le texte de ton PDF ressort en lettres séparées

Amine Affif — Fri, 23 Oct 2026 06:00:00 +0000

J'ai généré un PDF depuis du HTML avec Chrome en ligne de commande. À l'œil, il était parfait. Mais quand j'en ai extrait le texte avec un outil basé sur pdf.js, mes titres de section sortaient comme ça :

E X P É R I E N C E
STA C K

Avec pdftotext (poppler), les mêmes mots sortaient entiers. Même fichier, deux lectures.

J'ai regardé l'intérieur du PDF. Dans le mien, Chrome n'écrit pas des mots mais à peu près un caractère par opération : 3 136 opérations d'affichage de texte pour 3 062 repositionnements. Chaque lettre est placée en absolu.

Mes titres avaient un letter-spacing: .13em. En retirant l'interlettrage, les mots sont ressortis entiers dans les deux outils. Je compense en taille de police :

/* avant */
h2 { letter-spacing: .13em; font-size: 8.4pt; }

/* après */
h2 { letter-spacing: 0; font-size: 9pt; }

Un PDF n'est pas du texte, c'est une liste de glyphes positionnés. Qu'il soit beau à l'œil ne garantit pas qu'une machine saura le lire.

Si le texte de ton PDF doit être trouvé, copié ou indexé, teste-le avec au moins deux extracteurs. Un seul peut te dire que tout va bien.

Amine Affif, développeur full-stack à Paris. amineaffif.com

J'ai relu deux fois plus de code que je n'en ai écrit : ce que ça m'a appris

Amine Affif — Wed, 21 Oct 2026 06:00:00 +0000

Avec les agents de code, on produit plus vite qu'on ne relit. Le goulot, c'est maintenant la relecture.

Sur quinze mois, j'ai relu à peu près deux fois plus de pull requests que je n'en ai écrites, sur huit dépôts et trois stacks. Je le vois comme du temps donné à l'équipe : une pull request qui n'est pas relue, c'est du code que personne n'a lu qui part en production.

Trois habitudes qui rendent la relecture possible.

Livrer petit. Mes pull requests font deux à cinq fichiers en médiane. Une PR qui touche trois sujets ne se relit pas, elle s'approuve par fatigue. J'en ouvre trois.

Découper un gros chantier en étapes lisibles. Le helper, puis l'interface, puis le branchement aux données, puis les tests.

Écrire le pourquoi, pas le quoi. La description dit ce que ça change et pourquoi. Le diff montre déjà le reste. S'il y a une décision discutable, je l'écris dans la PR plutôt que d'attendre qu'on la trouve.

Ce que j'attends d'une revue : qu'on discute les décisions, pas la syntaxe. Le formatage est un travail d'outil, pas de relecteur.

Relire demande de comprendre le code de l'autre, pas seulement de vérifier qu'il compile. C'est aussi un bon moyen d'apprendre une base de code qu'on ne connaît pas encore.

Amine Affif, développeur full-stack à Paris. amineaffif.com

Deposits and holds with Stripe: what actually happens

Amine Affif — Mon, 19 Oct 2026 06:00:00 +0000

On a vehicle rental platform, I had to handle deposits and security holds with Stripe. They both look like a payment, but they're not the same operation.

A deposit is a normal payment: the money is taken right away, for part of the price.

A security hold must not be collected. You block it on the customer's card, then release it when the vehicle comes back in good shape. In Stripe, that's separating authorization from capture:

# example: €500 held, nothing collected
curl https://api.stripe.com/v1/payment_intents \
  -u "$STRIPE_SECRET_KEY:" \
  -d amount=50000 \
  -d currency=eur \
  -d "automatic_payment_methods[enabled]=true" \
  -d capture_method=manual

Once the card is confirmed, the payment moves to requires_capture. The money is held, not collected.

Three things to know.

The authorization expires. For a card paid online, it's usually 7 days. After that, the hold is released and the payment moves to canceled. For a longer rental, a hold placed at pickup doesn't last: you need an extended authorization (only for certain cases), or save the payment method to charge later if needed.
You can capture less than the held amount. With amount_to_capture, the rest is released automatically. But in most cases, you can only capture once.
Releasing means canceling the payment. Nothing more.

One detail on the customer side: some bank statements don't distinguish a held amount from a charged one. Better to say so in the confirmation email.

And not every payment method allows it: SEPA direct debit or iDEAL, for example, don't support this separation.

Amine Affif, full-stack developer in Paris. amineaffif.com

Acomptes et cautions avec Stripe : ce qui se passe vraiment

Amine Affif — Sun, 18 Oct 2026 06:00:00 +0000

Sur une plateforme de location de véhicules, j'ai eu à gérer des acomptes et des cautions avec Stripe. Les deux ressemblent à un paiement, mais ce n'est pas la même opération.

L'acompte est un paiement normal : l'argent est pris tout de suite, pour une partie du prix.

La caution ne doit pas être encaissée. On la bloque sur la carte du client, puis on la libère quand le véhicule revient en bon état. Chez Stripe, ça s'appelle séparer l'autorisation de la capture :

# exemple : 500 € bloqués, rien d'encaissé
curl https://api.stripe.com/v1/payment_intents \
  -u "$STRIPE_SECRET_KEY:" \
  -d amount=50000 \
  -d currency=eur \
  -d "automatic_payment_methods[enabled]=true" \
  -d capture_method=manual

Une fois la carte confirmée, le paiement passe en requires_capture. L'argent est retenu, pas encaissé.

Trois choses à savoir.

L'autorisation expire. Pour une carte payée en ligne, c'est en général 7 jours. Passé ce délai, le blocage est levé et le paiement passe en canceled. Pour une location plus longue, la caution bloquée au départ ne tient plus : il faut une autorisation prolongée (réservée à certains cas), ou enregistrer le moyen de paiement pour débiter plus tard si besoin.
On peut capturer moins que le montant bloqué. Avec amount_to_capture, le reste est libéré automatiquement. Mais dans la plupart des cas, on ne peut capturer qu'une seule fois.
Libérer, c'est annuler le paiement. Rien de plus.

Un détail côté client : certains relevés bancaires ne font pas la différence entre une somme bloquée et une somme prélevée. Mieux vaut le dire dans l'email de confirmation.

Et tous les moyens de paiement ne le permettent pas : le prélèvement SEPA ou iDEAL, par exemple, ne supportent pas cette séparation.

Amine Affif, développeur full-stack à Paris. amineaffif.com

Giving tools to an AI agent: why I set the limit outside the prompt

Amine Affif — Sat, 17 Oct 2026 06:00:00 +0000

When I give tools to an agent, I treat it like a third-party dependency: I don't trust it, I contain it.

The rule that matters: the constraint is set when the process starts, not in the prompt. A prompt is a request. The model can ignore it, or be turned around by malicious text slipped into what it reads.

On an agent I built, the tool list is closed in advance: twelve read tools allowed, fifteen write tools refused. It can't write a file or send a message, even if it tries.

Three more protections:

an anti-injection section in the prompt, because an agent reads text it doesn't control,
a mandatory adversarial pass before every output,
human validation before anything is published.

Why this instead of "a good prompt": an agent that can act does what its environment allows, not what it was politely asked. If the action is impossible, there's nothing left to trust.

I care less about the speed these tools bring than about how to contain them: that's what lets you move fast without pulling code into a repo that nobody has read.

Amine Affif, full-stack developer in Paris. amineaffif.com

Donner des outils à un agent IA : pourquoi je pose la limite hors du prompt

Amine Affif — Fri, 16 Oct 2026 06:00:00 +0000

Quand je donne des outils à un agent, je le traite comme une dépendance tierce : je ne lui fais pas confiance, je l'encadre.

La règle qui compte : la contrainte se pose au lancement du processus, pas dans le prompt. Un prompt, c'est une demande. Le modèle peut l'ignorer, ou se faire retourner par un texte malveillant glissé dans ce qu'il lit.

Sur un agent que j'ai construit, la liste des outils est fermée à l'avance : douze outils de lecture autorisés, quinze outils d'écriture refusés. Il ne peut ni écrire un fichier ni envoyer un message, même s'il essaie.

Trois protections s'ajoutent :

une section anti-injection dans le prompt, parce qu'un agent lit des textes qu'il ne maîtrise pas,
une relecture contradictoire obligatoire avant chaque sortie,
une validation humaine avant toute publication.

Pourquoi ce choix plutôt que « un bon prompt » : un agent qui peut agir fait ce que son environnement lui permet, pas ce qu'on lui a gentiment demandé. Si l'action est impossible, il n'y a plus à lui faire confiance.

Je m'intéresse moins à la vitesse que ces outils apportent qu'à la façon de les contenir : c'est ce qui permet d'aller vite sans ramener dans un dépôt du code que personne n'a lu.

Amine Affif, développeur full-stack à Paris. amineaffif.com