Amine Mekki
Je conçois et construis des systèmes web qui restent maintenables : Next.js et React devant, NestJS et PostgreSQL derrière, et du jugement d'ingénieur partout, y compris sur le code généré par IA.
À propos
Développeur full-stack JavaScript avec plus de 5 ans d'expérience dans la conception d'applications web et mobiles scalables sur l'écosystème TypeScript moderne : React, Next.js, Node.js et NestJS. J'ai piloté des équipes pluridisciplinaires, architecturé des produits de bout en bout et assuré la livraison en environnement Agile, en Espagne et en Tunisie. Ce qui m'importe n'est pas la liste de frameworks. C'est que le système reste compréhensible, testable et modifiable après mon départ. Cela façonne ma manière de concevoir des APIs, de modéliser les données et de relire du code. Cela façonne aussi ma manière d'utiliser l'IA : comme un accélérateur dont la production subit le même examen que n'importe quelle pull request.
Philosophie d'ingénierie
Les frameworks changent. Les raisons qui rendent un logiciel coûteux à faire évoluer, non. Voici les principes auxquels je soumets un codebase, y compris le mien.
Le code est bien plus souvent lu qu'écrit. J'optimise pour le prochain développeur : des noms explicites, des modules courts, des frontières qui correspondent à la façon dont on pense le métier. Si un changement nécessite un guide touristique, l'architecture a déjà échoué.
Chaque couche, pattern ou abstraction doit mériter sa place en résolvant un problème que le projet a réellement. Je préfère livrer une conception simple et directe plutôt que spéculative, puis refactorer délibérément quand de vrais besoins apparaissent.
Un pipeline vert n'est pas la ligne d'arrivée. La qualité de production inclut l'observabilité, la sécurité, la performance, une gestion d'erreurs claire et la documentation. Les tests donnent confiance dans le comportement ; le reste garde le système honnête face aux vrais utilisateurs.
J'utilise l'IA tous les jours pour aller plus vite, et je relis tout ce qu'elle produit comme n'importe quelle pull request. L'IA peut générer une implémentation qui fonctionne. Elle ne peut pas décider si l'abstraction est la bonne, si la frontière est correcte, ni si ce code a sa place dans le système. Ce jugement, c'est mon métier.
Qu'il ait été écrit par un collègue, par moi il y a six mois, ou par un modèle, les critères de revue sont les mêmes :
Ingénierie assistée par IA
Le développement assisté par IA a déplacé le goulot d'étranglement. Produire une implémentation qui fonctionne est devenu rapide ; savoir si elle doit atteindre la production reste la partie difficile. Un code syntaxiquement correct peut cacher de mauvaises frontières, des requêtes N+1, un typage faible, des chemins d'erreur absents et des abstractions dont personne n'a besoin. Voici deux exemples de ce qu'une revue attentive change.
À la demande « le total des commandes de chaque utilisateur », l’assistant a produit cette fonction. Ça compile, les tests sur trois utilisateurs de fixture passent, et la revue semble triviale. Jusqu’à ce qu’on compte les requêtes.
// "Get each user's order total", first attempt from the assistant
async function getUserOrderTotals(prisma: PrismaClient) {
const users = await prisma.user.findMany()
const results = []
for (const user of users) {
const orders = await prisma.order.findMany({
where: { userId: user.id },
})
const total = orders.reduce((sum, o) => sum + o.amount, 0)
results.push({ name: user.name, total })
}
return results
}type UserOrderTotal = { name: string; total: number }
async function getUserOrderTotals(prisma: PrismaClient): Promise<UserOrderTotal[]> {
const totals = await prisma.order.groupBy({
by: ['userId'],
_sum: { amount: true },
})
const users = await prisma.user.findMany({
select: { id: true, name: true },
})
const totalByUserId = new Map(totals.map((t) => [t.userId, t._sum.amount ?? 0]))
return users.map((user) => ({
name: user.name,
total: totalByUserId.get(user.id) ?? 0,
}))
}Une requête par utilisateur
La boucle émet un findMany par utilisateur : 10 000 utilisateurs, c’est 10 001 requêtes. Invisible sur des données de développement, incident de production à l’échelle.
Agrégation faite dans le code applicatif
La base sait calculer des sommes nativement. Rapatrier toutes les commandes en mémoire pour les réduire en JavaScript déplace le travail vers la couche la plus lente.
Pas de type de retour explicite
Les appelants voient une forme anonyme inférée. Un type métier d’une ligne documente l’intention et survit aux refactors internes.
Sélection de colonnes non bornée
findMany() sans select fait transiter toutes les colonnes alors que seuls id et name sont utilisés.
Le code généré optimise pour « ça compile et ça a l’air correct ». Les patterns de requêtes sont l’endroit où ça casse en silence : rien dans le système de types ne distingue 2 requêtes de 10 001. Relire les chemins d’accès aux données n’est pas optionnel, quel que soit l’auteur du code.
Une page App Router listant des projets. La version générée ressort la recette SPA familière : composant client, useEffect, fetch, état de chargement. Ça fonctionne, et ça embarque une classe entière de problèmes que le framework avait déjà résolus.
'use client'
// Project list page, generated with a client-side fetch "to be safe"
export default function ProjectsPage() {
const [projects, setProjects] = useState<any[]>([])
const [loading, setLoading] = useState(true)
useEffect(() => {
fetch('/api/projects')
.then((res) => res.json())
.then((data) => {
setProjects(data)
setLoading(false)
})
}, [])
if (loading) return <Spinner />
return <ProjectList projects={projects} />
}// Server component: data is fetched where it lives, typed end to end
export default async function ProjectsPage() {
const projects: Project[] = await getProjects()
if (projects.length === 0) {
return <EmptyState />
}
return <ProjectList projects={projects} />
}Mauvais côté de la frontière client/serveur
Rien ici n’est interactif. Rendre côté serveur supprime l’aller-retour réseau, le spinner et le layout shift.
any[] efface le contrat
Le composant accepte ce que l’endpoint renvoie, quoi que ce soit. Un champ renommé casse en production à l’exécution au lieu de casser à la compilation.
Pas de chemin d’erreur
Si le fetch échoue, loading reste vrai pour toujours et l’utilisateur regarde un spinner. Chaque accès aux données doit avoir un comportement d’échec défini.
Une route API qui n’existe que pour ce composant
L’endpoint /api/projects duplique un accès aux données qu’un composant serveur ferait directement. Plus de surface, plus de code à sécuriser et maintenir.
Les outils d’IA entraînés sur des années de patterns SPA les reproduisent dans des frameworks qui les ont rendus obsolètes. « Est-ce idiomatique pour la plateforme sur laquelle on est ? » est une question de revue qu’un modèle ne se pose pas de façon fiable.
Travaux choisis
Une sélection de missions que j'ai pilotées ou auxquelles j'ai contribué. Les études de cas complètes sont sur la page projets.
Team Lead : architecture, backend, livraison
Un produit full-stack qui digitalise l'étude technique et le chiffrage de projets de ventilation, piloté de bout en bout : coordination d'équipe, architecture API et données, fondations frontend et mise en place DevOps.
Lire l'étude de cas
Lead Technique : design system, services backend, livraison
Une plateforme full-stack de gestion agronomique : design system web, services backend NestJS et fonctionnalités front office / back office en Next.js, livrées dans un rôle de leadership technique.
Lire l'étude de cas
Katalii – Groupe Berto
Lead Technique : architecture, roadmaps, qualité de code
Un produit d'optimisation du transport multiplateforme : web en Next.js, mobile en React Native, APIs NestJS derrière les deux. J'y portais la responsabilité des choix d'architecture, des feuilles de route techniques et de la qualité de code.
Lire l'étude de cas
Développeur Full-Stack
Une plateforme de génération de pages publicitaires statiques : Astro.js pour la génération, des blocs de page réutilisables intégrés depuis Figma, et des services NestJS + GraphQL derrière.
Lire l'étude de cas
Expérience
Plus de cinq ans au sein d'équipes produit en Espagne et en Tunisie, souvent comme développeur responsable de l'architecture, de la qualité du code et de la livraison.
Team Lead & Développeur Full-Stack · Soler & Palau · Barcelone, Espagne
Lead Technique & Développeur Full-Stack · RAGT · Barcelone, Espagne
Lead Technique · Katalii – Groupe Berto · Barcelone, Espagne
Développeur Full-Stack · Le Bon Coin · Barcelone, Espagne
Développeur Full-Stack · My Insurance / GestiLot / OneWay · Sfax, Tunisie
Développeur Frontend · Piximind · Sfax, Tunisie
Stack
Pas un mur de logos. Voici la stack avec laquelle je travaille au quotidien, regroupée selon le rôle qu'elle joue dans un système.
Notes d'ingénierie
Des notes courtes et pratiques sur l'architecture, le clean code et le développement assisté par IA. Le genre de choses que je partagerais dans une revue de code.
Le développement assisté par IA a déplacé le goulot d'étranglement : écrire le code est devenu rapide, le juger reste lent. Cela change le rôle d'un développeur senior, et rend la compétence de revue plus précieuse, pas moins.
Les codebases les plus pénibles ne manquent pas d'abstraction. Elles ont des abstractions au mauvais endroit. Les frontières viennent d'abord ; les abstractions se méritent ensuite.
Un pourcentage de couverture mesure l'exécution, pas la confiance. Une suite utile se conçoit autour d'une autre question : qu'est-ce qui me permettrait de refactorer sans peur ?
Contact
Le moyen le plus rapide de me joindre est l'email. Je suis ouvert aux discussions d'architecture, de leadership technique, ou à un second avis sur votre codebase.
ou retrouvez-moi sur LinkedIn