Projets

Le problème, ce que j'ai construit, le résultat

Huit systèmes utilisés chaque jour par ceux qui les ont payés. Chacun raconté de la même façon : ce qui bloquait le travail, ce que j'ai construit, et ce qui a changé ensuite.

30+

Projets livrés

Ans d'expérience

Secteurs servis

1 jour

Délai de réponse

Waiter mobile appReal-time ordersStation printingPoint of sale

Paresta

Le problème: La commande était écrite sur un carnet puis répétée trois fois — en cuisine, au bar, en caisse — et un service chargé perdait des lignes à chaque trajet.
Ce que j'ai construit: Une application pour les téléphones des serveurs et un point de vente de bureau qui fait aussi office de serveur : la commande est prise à la table, arrive en caisse en temps réel et s’imprime au poste qui doit la préparer.
Le résultat: Une commande, saisie une seule fois : la cuisine et le bar démarrent pendant que le serveur est encore à la table, et la recette du jour se calcule sur les mêmes enregistrements.

Lire l'étude de cas

Illustration éditoriale sombre de l’espace Paresta avec le contrôle des tables, des commandes et une grille de produits.

Browser extensionTest dataQA toolingChrome, Edge & Firefox

DevFiller

Le problème: Tester un formulaire, c’est retaper sans cesse le même faux nom, le même e-mail, la même adresse — et le remplissage automatique classique devine à partir du seul nom du champ, ignore les règles de validation et échoue sur les formulaires en français ou en arabe.
Ce que j'ai construit: Une extension qui lit chaque champ avant de le remplir, génère une identité fictive cohérente qui respecte les règles de chaque champ, et explique son raisonnement dans un panneau latéral avec annulation.
Le résultat: Un clic remplit correctement un formulaire réel dans 93,5 % des cas, sur Chrome, Edge et Firefox, sans que rien ne quitte le navigateur.

Lire l'étude de cas

ShopifyE-commerceLiquidUX

Léonie Maroquinerie

Le problème: Une sélection de quinze maisons de créateurs sans endroit pour la vendre : les acheteurs demandaient les pièces en message, les prix se donnaient au fil des conversations, et le stock vivait dans un tableur.
Ce que j'ai construit: Une vitrine sobre, volontairement dépouillée, qui laisse les pièces porter la page, avec un paiement en quatre devises, trente jours de retour gratuit, et une campagne « ticket d’or » qui donne une raison de revenir.
Le résultat: La collection se vend en ligne en quatre devises, et les retours comme le stock sont gérés par la boutique plutôt qu’à la main.

Lire l'étude de cas

La vitrine Léonie présentant des articles de maroquinerie de créateurs sur fond neutre

Next.jsNestJSReactCMS & Roles

Irched & Islah

Le problème: Actualités, activités et coordonnées des filiales dépendaient de qui les avait saisies, les demandes de bénévolat et de don arrivaient en messages, et changer une seule ligne du site imposait d’attendre un développeur.
Ce que j'ai construit: Un site public en arabe pour le travail de l’association, et un back office où un super-admin attribue à chaque membre ses propres modules — le responsable des actualités modifie les actualités, et rien d’autre.
Le résultat: L’association publie tout elle-même sur seize modules, et bénévolat comme dons arrivent sous forme de demandes à traiter plutôt que de messages.

Lire l'étude de cas

TypeScriptCanvas 2DWebRTC Co-opWeb Audio

Life Quest

Le problème: Les platformers navigateur téléchargent des mégaoctets de sprites et d’audio avant la première image, et le jeu en ligne demande d’habitude un serveur que quelqu’un doit payer.
Ce que j'ai construit: Un jeu sans assets et sans backend : le style « rubber-hose » des années 1930 est dessiné en direct sur un canvas à chaque image, chaque son est synthétisé, et le co-op passe en pair-à-pair via un code à quatre lettres.
Le résultat: Quatre boss multi-phases dessinés à la main, deux styles graphiques interchangeables et un co-op en ligne — sans un seul fichier image ou audio dans le dépôt.

Lire l'étude de cas

Life Quest dans son style Cuphead dessiné à la main, en plein combat contre un des quatre boss

La boutique JF LAROSE affichant la gamme de produits et le paiement à la livraison

Next.jsNestJSE-commerceFR + AR (RTL)

JF LAROSE Laboratoires

Le problème: Chaque commande arrivait par téléphone ou en message privé, et le prix de livraison pour la commune de l’acheteur devait être cherché à la main à chaque fois. Personne ne pouvait dire ensuite ce qui avait été expédié où.
Ce que j'ai construit: Une boutique en français et en arabe où le client paie à la livraison, où le tarif de sa commune exacte est déjà connu, et où l’équipe gère le catalogue, les commandes et la paperasse du livreur depuis un back office.
Le résultat: Les clients des 58 wilayas commandent eux-mêmes dans la langue qu’ils lisent, et les bordereaux de livraison s’impriment au lieu d’être rédigés.

Lire l'étude de cas

ReactLaravelB2B BookingRole-based Access

DenizTrip

Le problème: Les agences partenaires vérifiaient les disponibilités par téléphone et par message. Confirmer une réservation puis émettre son voucher et sa facture pouvait prendre une journée d’échanges, et la même place se vendait parfois deux fois.
Ce que j'ai construit: Un portail où chaque agence voit les disponibilités en temps réel et ses propres tarifs, réserve en quelques clics et télécharge voucher et facture — pendant que l’équipe Deniz gère voyages, allotements hôteliers, transferts et annonces depuis un seul back office.
Le résultat: Les agences réservent sur des disponibilités réelles, les départs complets disparaissent d’eux-mêmes, et la paperasse autrefois manuelle est générée dès la confirmation.

Lire l'étude de cas

Le portail agences DenizTrip affichant les voyages disponibles avec places restantes et tarifs par agence

Votre projet commence par un message

Premier échange gratuit, 20 minutes

Écrivez ce qui vous prend du temps ou vous fait perdre de l'argent. Je réponds sous un jour ouvré avec un plan et un prix — et si je ne suis pas la bonne personne, je vous le dirai.

01: Vous envoyez le message ; je réponds sous un jour ouvré avec quelques questions.
02: Un échange de 20 minutes pour comprendre ce dont vous avez réellement besoin.
03: Un plan écrit avec un prix et un délai clairs, sans engagement.

Dites-moi ce dont vous avez besoin

← Retour au site

Projets

Le problème, ce que j'ai construit, le résultat

Huit systèmes utilisés chaque jour par ceux qui les ont payés. Chacun raconté de la même façon : ce qui bloquait le travail, ce que j'ai construit, et ce qui a changé ensuite.

30+

Projets livrés

Ans d'expérience

Secteurs servis

1 jour

Délai de réponse

Waiter mobile appReal-time ordersStation printingPoint of sale

Paresta

Le problème: La commande était écrite sur un carnet puis répétée trois fois — en cuisine, au bar, en caisse — et un service chargé perdait des lignes à chaque trajet.
Ce que j'ai construit: Une application pour les téléphones des serveurs et un point de vente de bureau qui fait aussi office de serveur : la commande est prise à la table, arrive en caisse en temps réel et s’imprime au poste qui doit la préparer.
Le résultat: Une commande, saisie une seule fois : la cuisine et le bar démarrent pendant que le serveur est encore à la table, et la recette du jour se calcule sur les mêmes enregistrements.

Lire l'étude de cas

Browser extensionTest dataQA toolingChrome, Edge & Firefox

DevFiller

Le problème: Tester un formulaire, c’est retaper sans cesse le même faux nom, le même e-mail, la même adresse — et le remplissage automatique classique devine à partir du seul nom du champ, ignore les règles de validation et échoue sur les formulaires en français ou en arabe.
Ce que j'ai construit: Une extension qui lit chaque champ avant de le remplir, génère une identité fictive cohérente qui respecte les règles de chaque champ, et explique son raisonnement dans un panneau latéral avec annulation.
Le résultat: Un clic remplit correctement un formulaire réel dans 93,5 % des cas, sur Chrome, Edge et Firefox, sans que rien ne quitte le navigateur.

Lire l'étude de cas

ShopifyE-commerceLiquidUX

Léonie Maroquinerie

Le problème: Une sélection de quinze maisons de créateurs sans endroit pour la vendre : les acheteurs demandaient les pièces en message, les prix se donnaient au fil des conversations, et le stock vivait dans un tableur.
Ce que j'ai construit: Une vitrine sobre, volontairement dépouillée, qui laisse les pièces porter la page, avec un paiement en quatre devises, trente jours de retour gratuit, et une campagne « ticket d’or » qui donne une raison de revenir.
Le résultat: La collection se vend en ligne en quatre devises, et les retours comme le stock sont gérés par la boutique plutôt qu’à la main.

Lire l'étude de cas

Next.jsNestJSReactCMS & Roles

Irched & Islah

Le problème: Actualités, activités et coordonnées des filiales dépendaient de qui les avait saisies, les demandes de bénévolat et de don arrivaient en messages, et changer une seule ligne du site imposait d’attendre un développeur.
Ce que j'ai construit: Un site public en arabe pour le travail de l’association, et un back office où un super-admin attribue à chaque membre ses propres modules — le responsable des actualités modifie les actualités, et rien d’autre.
Le résultat: L’association publie tout elle-même sur seize modules, et bénévolat comme dons arrivent sous forme de demandes à traiter plutôt que de messages.

Lire l'étude de cas

TypeScriptCanvas 2DWebRTC Co-opWeb Audio

Life Quest

Le problème: Les platformers navigateur téléchargent des mégaoctets de sprites et d’audio avant la première image, et le jeu en ligne demande d’habitude un serveur que quelqu’un doit payer.
Ce que j'ai construit: Un jeu sans assets et sans backend : le style « rubber-hose » des années 1930 est dessiné en direct sur un canvas à chaque image, chaque son est synthétisé, et le co-op passe en pair-à-pair via un code à quatre lettres.
Le résultat: Quatre boss multi-phases dessinés à la main, deux styles graphiques interchangeables et un co-op en ligne — sans un seul fichier image ou audio dans le dépôt.

Lire l'étude de cas

Next.jsNestJSE-commerceFR + AR (RTL)

JF LAROSE Laboratoires

Le problème: Chaque commande arrivait par téléphone ou en message privé, et le prix de livraison pour la commune de l’acheteur devait être cherché à la main à chaque fois. Personne ne pouvait dire ensuite ce qui avait été expédié où.
Ce que j'ai construit: Une boutique en français et en arabe où le client paie à la livraison, où le tarif de sa commune exacte est déjà connu, et où l’équipe gère le catalogue, les commandes et la paperasse du livreur depuis un back office.
Le résultat: Les clients des 58 wilayas commandent eux-mêmes dans la langue qu’ils lisent, et les bordereaux de livraison s’impriment au lieu d’être rédigés.

Lire l'étude de cas

ReactLaravelB2B BookingRole-based Access

DenizTrip

Le problème: Les agences partenaires vérifiaient les disponibilités par téléphone et par message. Confirmer une réservation puis émettre son voucher et sa facture pouvait prendre une journée d’échanges, et la même place se vendait parfois deux fois.
Ce que j'ai construit: Un portail où chaque agence voit les disponibilités en temps réel et ses propres tarifs, réserve en quelques clics et télécharge voucher et facture — pendant que l’équipe Deniz gère voyages, allotements hôteliers, transferts et annonces depuis un seul back office.
Le résultat: Les agences réservent sur des disponibilités réelles, les départs complets disparaissent d’eux-mêmes, et la paperasse autrefois manuelle est générée dès la confirmation.

Lire l'étude de cas

Votre projet commence par un message

Premier échange gratuit, 20 minutes

Écrivez ce qui vous prend du temps ou vous fait perdre de l'argent. Je réponds sous un jour ouvré avec un plan et un prix — et si je ne suis pas la bonne personne, je vous le dirai.

01: Vous envoyez le message ; je réponds sous un jour ouvré avec quelques questions.
02: Un échange de 20 minutes pour comprendre ce dont vous avez réellement besoin.
03: Un plan écrit avec un prix et un délai clairs, sans engagement.