Doolta
FR · EN Nous écrire

Arnaud ASSAD, fondateur de Doolta

Je commence par comprendre le système. L'outil vient en dernier.

Vous ne m’engagez pas pour une techno. Vous m’engagez pour transformer un problème confus, où le code, l’architecture, le métier et l’organisation s’entremêlent, en quelques décisions claires que votre équipe pourra tenir sans moi.

Arnaud ASSAD

Arnaud ASSAD

Expert technique senior et Fractional CTO. 25 ans de Perl, C, Go, systèmes distribués et équipes qui les portent.

25+

années sur des systèmes en production

9h-13h

recouvrement horaire avec l'Europe

24 h

délai de réponse

Mon mode de pensée

Quatre temps, toujours dans cet ordre.

La plupart des missions qui dérapent inversent cet ordre : elles commencent par l’outil, et cherchent ensuite le problème qu’il résout. Je fais l’inverse, et c’est ce qui rend les décisions défendables six mois plus tard.

  1. 01

    Pensée systémique

    Un symptôme n’est presque jamais sa propre cause. Je regarde le système entier : le code, mais aussi les flux de données, les contraintes métier, les habitudes de l’équipe et ce que l’organisation récompense sans le dire. Beaucoup de pannes que l’on croit techniques sont des pannes de couplage.

  2. 02

    Clarification

    Je réduis jusqu’à ce que le problème devienne falsifiable. Qu’est-ce qui doit rester vrai ? Qu’est-ce qui peut céder ? À quelle question voulez-vous réellement une réponse ? Tant que ce n’est pas formulé, toute solution reste un pari. C’est souvent cette étape qui débloque, avant la première ligne de code.

  3. 03

    Solution

    Je cherche la structure la plus simple qui tienne. Pas la plus élégante ni la plus moderne : celle que vos équipes pourront exploiter, déboguer et faire évoluer une fois que je serai parti. Une solution que vous ne pouvez pas maintenir n’est pas une solution.

  4. 04

    Outils

    L’outil arrive en dernier, et seulement si les trois étapes précédentes le justifient. Go, PostgreSQL, ClickHouse, Docker, HTMX, un binaire unique ou un script de quarante lignes : le choix découle du problème, jamais l’inverse. Parfois la bonne réponse est de ne rien ajouter.

Corollaire assumé : il m’arrive de conclure qu’un problème n’est pas technique. C’est parfois la conclusion la plus rentable d’un audit, et c’est aussi celle que peu de prestataires acceptent d’écrire.

Trois exemples

La même méthode, sur trois problèmes qui n'ont rien à voir.

Ces trois systèmes sont publics : code, tests, décisions d’architecture et limites assumées. Vous pouvez juger le travail avant de me faire confiance.

mAPI-ng

Diagnostic d'incident pour APIs Go

Le système
Une API ralentit en production. La stack d’observabilité en place affiche tout et n’explique rien : à chaque incident, l’équipe passe son temps à interpréter des graphiques au lieu de réparer.
La clarification
La vraie question n’est pas « que montrent les métriques ? » mais « quelle est la cause la plus probable, et qu’est-ce qui l’écarterait ? ». Un diagnostic sans critère de réfutation n’est qu’une opinion bien présentée.
La solution
Classer les causes en huit familles et n’en proposer aucune sans la preuve qui la soutient ni la ligne qui dirait qu’elle est fausse. Quand rien n’explique l’anomalie, l’afficher : « cause non attribuée », plutôt qu’inventer une explication rassurante.
L'outil
Alors seulement l’outillage : agrégation DDSketch dans le process, résumés compacts dans ClickHouse, une variable d’environnement pour instrumenter. L’architecture découle du raisonnement, pas d’un choix de stack.
Voir le projet →

YVO Cloud

Cloud personnel auto-hébergé

Le système
Un stockage de fichiers avec déduplication par blobs. Techniquement correct, mesurable, efficace, et déjà en fonctionnement.
La clarification
Une exigence non négociable n’était pourtant pas tenue : récupérer ses fichiers sans l’application. Le système marchait, mais il ne tenait pas sa promesse. Nuance qu’aucune métrique ne remonte.
La solution
Remettre en cause l’architecture qui fonctionne. Nouveau principe : la vérité est sur le disque, chaque fichier reste lisible intact à son chemin réel, l’historique devient un delta annexe.
L'outil
Le changement est tracé dans une décision d’architecture documentée, avec sa justification complète, comme les huit autres du projet. Savoir démonter ce que l’on a construit fait partie du métier.
Voir le projet →

AXF

Format ouvert d'identités numériques

Le système
Jongler entre un employeur, des clients, des projets personnels : règles ~/.ssh/config, .gitconfig surchargé pour ne pas commiter avec le mauvais email, fenêtres de navigateur séparées. Chacun contourne avec ses propres scripts.
La clarification
Ce ne sont pas cinq problèmes d’outillage indépendants. C’en est un seul, que personne n’avait nommé : le changement de contexte d’identité.
La solution
Donner un modèle explicite au problème : une commande pour entrer dans un contexte, une pour en sortir proprement. Pas de démon, pas d’état caché, des identités stockées en documents versionnables.
L'outil
Une spécification ouverte plutôt qu’un énième script maison, sur le modèle d’OpenAPI ou d’OCI : le format d’abord, l’implémentation Go de référence ensuite. Un problème bien nommé se résout une fois pour toutes.
Voir le projet →

Pourquoi m'engager

Parce que la valeur d’une mission ne se mesure pas au volume de code livré, mais à ce que votre équipe sait faire seule le jour où je pars.

  • Je livre jusqu’au bout. Moontill, la caisse que j’ai conçue et développée, encaisse chaque jour les ventes réelles d’un commerce indépendant, sauvegarde, retour arrière et runbook opérateur compris. Je connais les arbitrages d’une mise en production, je ne fais pas que les recommander.

  • Je rends le système compréhensible. Décisions documentées, architecture lisible, bus factor réduit : rien de ce que je construis ne doit dépendre de ma présence.

  • Je mesure au lieu d’affirmer. Couverture de tests verrouillée, gains de compression benchmarkés sur des dépôts réels, précision de recherche évaluée : mes affirmations sont vérifiables, y compris quand elles me dérangent.

  • Je dis les limites. Statut pre-alpha annoncé, spécification en draft assumée, cause d’incident non attribuée quand elle l’est. Vous saurez toujours où en est réellement un projet.

  • Vous jugez sur pièces. Les systèmes que je construis sont publics : code, tests, décisions et angles morts.