Jobmiko
Des candidatures adaptées à chaque offre, rédigées avec l’IA.
- Next.js
- React
- TypeScript
- Tailwind CSS
COLLECTION ’26
Anas Abbassi, ingénieur agentic delivery à Casablanca
Je conçois et je livre des applications en production en orchestrant des agents de code : spécification, parallélisation, revue et durcissement.
Spécifier, paralléliser, revérifier. Le code part en production.
- 2,5+ans en production
- 3produits personnels
- 5études de cas
- FR · EN · ARlangues de travail
01 · Projets sélectionnés
Projets sélectionnés
Quatre produits récents, du SaaS client à la suite métier. Chaque carte ouvre une étude de cas sur le problème, les décisions et ce qui a été construit.
02 · Stack
Les outils derrière la méthode, pas une liste de logos.
Chaque nœud porte une décision de livraison : une interface qui parle à la bonne base, un module servi par la CI, une mémoire locale qui reste sur disque.
Survolez un nœud pour voir les projets qui l’utilisent.
STACK / MAP
2026
Jobmiko · Next.js · Supabase · Cloudflare
- Back-end
- LaravelPHPNode.jsMCP
- Front-end
- TypeScriptReactNext.jsElectron
- Données & infra
- SupabaseSQLiteDockerGitLab CICloudflare
Les technologies que j’utilise en production.Les trois familles de la stack, en un coup d’œil.
03 · Services
Comment je livre
Quatre étapes, une seule chaîne : le brief devient une spécification, les agents exécutent, la revue tranche, la mise en production tient.
Cadrage et spécification
Un brief devient une spécification exécutable : contrats, critères d’acceptation, cas limites, plan de vérification.
Orchestration d’agents
Plusieurs agents en parallèle sur des périmètres disjoints, coordination via MCP, mémoire de projet et revue à chaque étape.
Revue et durcissement
Le code généré n’est pas livré tel quel. Architecture, edge cases, sécurité et intégrité des données sont relus et testés.
Mise en production
CI/CD, environnements, observabilité et passation. Le livrable est un système qui tourne et qu’une autre équipe peut reprendre.
04 · Lab
Expérimentations
Six essais courts, entre mémoire d’agent et outils de livraison.
Voir sur GitHub (ouvre un nouvel onglet)05 · Notes
Notes
- Spécifier avant de paralléliser : pourquoi un agent sans critères d’acceptation produit du code invérifiable.Un agent n’est fiable que si sa sortie peut être refusée. Sans critères d’acceptation écrits, chaque relecture devient un avis.
- Mémoire de projet : pourquoi j’ai écrit SupraCortex plutôt que de coller du contexte à chaque session.Recoller le contexte à la main ne passe pas l’échelle. SupraCortex garde une mémoire locale, interrogeable par MCP et rattachée à ses sources.
- Revue comme goulot : ce que je vérifie systématiquement dans du code généré.La vérification devient le point de contention, donc ce qui doit être outillé. Dans SEMS, la CI et les environnements Docker imposent ce que je peux livrer.
06 · À propos
Je livre avec des agents, et je réponds du code produit.
Je conçois et je livre des applications en production en orchestrant des agents de code. Le travail se joue en quatre temps : spécifier, orchestrer, vérifier, livrer. Les agents accélèrent l’exécution ; la spécification et la revue restent miennes.
Cette méthode vient de l’outillage que j’ai construit pour moi : SupraCortex, une mémoire de projet local-first pour les agents de code ; SupraSpace, un poste de commande local pour les CLI de code ; FlowFactory, une expérimentation de génération de workflows n8n.
La base reste la production : le module Procure-to-Pay de SEMS chez E-Solution depuis août 2024, avec Laravel, GitLab CI/CD et Docker, après un stage sur les sous-modules de gestion de flotte de février à juillet 2024. J’utilise Laravel, Node.js ou React quand c’est le bon outil, jamais comme argument en soi.
Méthode
Spécifier, orchestrer, vérifier, livrer.
Spécifier
Contrats, critères d’acceptation et cas limites sont écrits avant la première ligne. La spec sert aux agents et à la revue.
Orchestrer
Les agents travaillent en parallèle sur des périmètres disjoints, avec une mémoire de projet partagée et une revue à chaque étape.
Vérifier
Architecture, sécurité et intégrité des données sont relues, et les tests passent en CI avant chaque intégration.
Livrer
Pipelines CI/CD, environnements Docker et documentation de reprise, pour qu’une autre équipe puisse continuer.
En quoi c’est différent
En quoi c’est différent
- Une seule spec que les agents et les humains suivent.
- Des agents parallélisés sur des périmètres disjoints.
- Chaque fusion est relue et testée.
- Spécification
- Contrats · critères d’acceptation · cas limites
- Orchestration
- Claude Code · Codex · OpenCode · MCP
- Revue
- Architecture · sécurité · tests · CI
- Mise en production
- GitLab CI/CD · Docker · observabilité
StackLaravel · PHP · Node.js · React · Next.js · TypeScript · Tailwind · Supabase · SQLite · Docker · GitLab CI
- Basé à
- Casablanca
- Rôle
- Ingénieur agentic delivery
- Entreprise
- E-Solution
- Formation
- EHEI
- Langues
- FR · EN · AR
07 · Contact
Un projet, un poste, une idée ?
Décrivez le contexte, le problème et l’échéance. Je réponds en français ou en anglais, depuis Casablanca.
abbassianas43@gmail.com
Ailleurs
DisponibleCDI & freelanceUTC+1Pas de formulaire, pas de traceur : un e-mail suffit.