Deux casquettes,
une seule exigence.

Je construis les outils, et j'accompagne les gens qui s'en servent.

[ 01 ]Le récit

D'où ça vient

J'ai commencé par vouloir que ça marche.

Comme beaucoup, j'ai appris en cassant des choses. Un site qui ne s'affichait pas, une base de données mal pensée, une fonctionnalité qu'il fallait réécrire trois fois. Ce que ces échecs m'ont appris n'est pas technique : c'est qu'un produit ne tient jamais debout tout seul. Il tient parce que quelqu'un a compris à quoi il servait avant de l'écrire.

Alors j'ai arrêté de commencer par le code. Je commence par la question qui dérange : qu'est-ce qui vous coûte vraiment du temps, aujourd'hui ? La réponse n'est presque jamais celle qu'on m'avait annoncée au téléphone.

Comment je pense

Enlever est une décision de conception.

« Less is more, let's refactor » n'est pas une posture d'esthète. C'est une méthode de travail. Chaque écran en trop est un écran à maintenir, à traduire, à tester, à expliquer. Chaque option ajoutée « au cas où » est une décision qu'on refile à l'utilisateur.

Je passe donc beaucoup de temps à retirer. À fusionner deux pages qui disaient la même chose. À supprimer un réglage que personne n'a jamais touché. Le produit qui en sort est plus court à lire, plus rapide à charger, et surtout plus facile à faire évoluer six mois plus tard, quand j'ai oublié pourquoi j'avais écrit ça.

Pourquoi les PME

La plupart des projets ne meurent pas d'un problème technique.

Ils meurent parce que personne n'a traduit un besoin métier en décisions de produit. Le dirigeant sait ce qui coince ; le développeur sait ce qui est possible ; entre les deux, il manque presque toujours quelqu'un pour arbitrer. C'est le travail que je préfère, et c'est pour ça que je ne me contente pas de livrer un dépôt Git.

Une PME n'a pas d'équipe produit, pas de designer interne, pas de temps à perdre en réunions de cadrage. Elle a besoin de quelqu'un qui construit, qui explique, et qui s'efface une fois que ça tourne. L'objectif n'a jamais été qu'on dépende de moi. C'est que ça tienne sans moi.

[ 02 ]ConvictionsMa manière de réfléchir

Six règles que je ne négocie pas.

Elles ne viennent pas d'un livre de méthode : chacune est la trace d'un projet où j'ai fait l'inverse.

Le problème avant l'outil

Choisir sa stack avant d'avoir cadré le besoin, c'est acheter les meubles avant de connaître la taille de la pièce.

Concrètement : le premier appel ne parle pas de technologie.

Enlever avant d'ajouter

Une fonctionnalité retirée ne tombe jamais en panne. La simplicité n'est pas un manque d'ambition, c'est une ambition plus difficile.

Concrètement : je propose souvent de sortir des choses du périmètre.

Livrer petit, livrer souvent

Un projet qui disparaît trois mois dans un tunnel revient toujours à côté. On corrige quand la correction est encore gratuite.

Concrètement : une URL que vous pouvez ouvrir dès la première semaine.

La performance est une politesse

Faire attendre quelqu'un quatre secondes sur un téléphone en 4G, c'est décider que son temps vaut moins que le confort du développeur.

Concrètement : le budget de performance est fixé avant de dessiner.

L'accessibilité n'est pas une option

Contrastes, tailles de cible, navigation au clavier, mouvement réduit. Ce n'est pas une case à cocher en fin de projet : c'est la définition de « ça marche ».

Concrètement : chaque animation de ce site sait s'arrêter.

Rendre autonome, pas dépendant

Un prestataire indispensable est un risque, pas un partenaire. Ce que je construis doit pouvoir être repris par quelqu'un d'autre.

Concrètement : documentation claire et prise en main accompagnée.

[ 03 ]Philosophie

Ce en quoi je crois, en dehors du code.

Le soin se voit dans ce que personne ne remarque

Un espacement juste, une transition qui ne saute pas, un message d'erreur écrit comme une phrase. Personne ne vous félicitera pour ça. C'est pourtant exactement ce qui fait la différence entre un produit qu'on tolère et un produit qu'on aime ouvrir.

On ne construit rien de solide dans l'urgence permanente

L'urgence est parfois réelle ; en faire un régime de croisière est un choix de gestion, et c'est toujours le produit qui paie. Je préfère annoncer une date plus lointaine et la tenir.

Dire non à temps est un service rendu

Accepter un projet qu'on ne peut pas bien faire, c'est voler du temps à quelqu'un. Refuser tôt, en expliquant pourquoi, vaut mieux qu'un demi-produit livré en retard.

Apprendre en public

Je ne sais pas tout, et faire semblant coûte cher à tout le monde. Dire « je ne sais pas encore, je regarde et je reviens vers vous » a toujours mieux marché que l'assurance de façade.

La technique ne vaut que par ce qu'elle permet

Une architecture élégante qui ne fait gagner de temps à personne est un plaisir privé. Ce qui compte, c'est la personne à l'autre bout, un mardi matin, qui a un truc à faire.

[ 04 ]En dehors du code

Ce qui me nourrit, en dehors du code.

On travaille mieux avec quelqu'un qu'on connaît un peu. Voilà ce qui tourne quand l'éditeur est fermé.

01/04Musique

Derrière les platines

Je mixe sur une DDJ-FLX4, Rekordbox ouvert. Construire une transition propre et construire une interface, c'est le même plaisir : une affaire de timing.

02/04Tech créative

Le code qui sort de l'écran

Shows laser, imagerie générative, animations web, impression 3D. J'aime quand la technique devient quelque chose qu'on regarde.

03/04Pensées

Philosophie & développement personnel

Je questionne ma façon de faire autant que mon code. Les convictions plus haut ne sortent pas de nulle part : elles viennent de ce travail-là.

04/04Gaming

Manette en main

Baldur's Gate 3 en ce moment. Les bons jeux sont des leçons de design : ils vous apprennent leurs règles sans jamais ouvrir un manuel.

[ 05 ]Comment je travaille

Quatre étapes, toujours les mêmes.

On cadre le vrai problème

Un appel, des questions précises. On identifie ce qui vous coûte réellement du temps ou de l'argent. Souvent, ce n'est pas ce que vous pensiez au départ.

Je maquette avant de coder

Vous voyez le produit à l'écran avant qu'une ligne de code existe. On corrige à ce moment-là, quand ça ne coûte rien.

Je construis par tranches

Des livraisons régulières sur une URL que vous pouvez ouvrir à tout moment. Pas d'effet tunnel, pas de mauvaise surprise à la fin.

Je rends votre équipe autonome

Documentation claire, prise en main accompagnée. L'objectif n'est pas que vous dépendiez de moi. C'est que ça tourne sans moi.

//Le mot d'ordre

« Less is more, let's refactor. »

Ce n'est pas une punchline de profil : c'est ce que je me répète quand j'ai envie d'ajouter une fonctionnalité qui ferait plaisir à moi seul.

// fiche technique

StatutDisponible

FocusWeb · SaaS · PME

LanguesFR · EN

BaseBelgique · remote

// stack technique

Frontend

ReactNext.jsTypeScriptTailwindVue.js

Backend

Node.jsJavaExpressPython

Données

PostgreSQLSupabaseMongoDB

Mobile

React NativeFlutter

Outils

DockerGitAWS

Travaillons ensemble.

Un projet, une question, une envie de moderniser votre PME ?
Écrivez-moi. Je réponds en moins de 24 heures.

amauryandrade1998@gmail.com

Envoyer un emailVoir les projets

Deux casquettes,une seule exigence.