Le catalogue
Je veux…
42 parcours. Chacun finit cette phrase, et répond par une boucle : ce qu’on dit, dans quel ordre, et ce que chaque étape rend. Les73 arcanes sont empruntées, aucune n’est laissée de côté.
Commencer
Je découvre, je ne sais pas par où entrer
Construire
Je veux fabriquer quelque chose qui n’existe pas encore
- faire une application iPhoneDe l’idée à la première version installable sur un téléphone : le contrat d’API, le code SwiftUI, le style Apple, la relecture, puis TestFlight.
- faire une application AndroidLa même route que l’iPhone, sur l’autre versant : Kotlin et Compose, ou Flutter si les deux plateformes doivent partager le code.
- faire un site qui se litUn site dont le sujet est le texte : une revue, un manifeste, une documentation. Composé comme une page imprimée, pas comme un tableau de bord.
- faire un produit en ligne payantLe chemin long : décider quoi construire, choisir la stack, écrire le contrat d’API, estimer la facture avant de la recevoir, déployer.
- me donner une identité visuelle tenablePasser d’un « ça devrait être plus bleu » à un système : des jetons nommés, mesurés, et une relecture qui dit quand on en sort.
- transformer une maquette en écrans qui marchentLe fichier Figma existe. Il devient des jetons, puis des composants, puis un pont qui reste synchronisé quand la maquette bouge.
- faire une API que d’autres vont utiliserLe contrat d’abord : ce que l’API promet, ce qu’elle refuse, comment elle s’authentifie. Le code vient après, et les tests avec.
- monter une plateforme musicaleUn domaine à part : catalogue, curation, droits, métadonnées. Les erreurs y sont spécifiques et coûteuses.
Reprendre
J’hérite d’un projet que je n’ai pas écrit
- comprendre un projet que je n’ai pas écritQuatre passes : ce qu’il y a dedans, ce qui va mal, ce que le code voulait dire, et ce qu’on peut simplifier sans rien casser.
- faire le tri dans un dépôt à l’abandonCe qui reste, ce qui sert, ce qui ment. On inventorie avant de supprimer, on répare la documentation, on ferme la séance proprement.
- réduire la dette sans tout réécrireMesurer d’abord, couper ensuite. La complexité se chiffre ; la réécriture totale est presque toujours le mauvais geste.
- sortir un morceau de code pour le réutiliser ailleursCe bout de code marche bien. On le détache de son projet, on le généralise, on le rend installable ailleurs.
- sortir mon site de SPIPLe contenu passe de SPIP à Astro : structure, articles, images, redirections. Le site reste le même côté lecteur.
Vérifier
Je veux savoir si c’est bon avant d’y aller
- faire relire mon code sérieusementDeux relectures différentes : une notée à deux voix, une adversariale qui cherche à casser. Elles ne trouvent pas les mêmes choses.
- vérifier que rien ne fuitDeux passes complémentaires : les failles applicatives, et les secrets écrits en dur qui partiront avec le prochain commit.
- rendre le site utilisable par tout le mondeLes contrastes, le clavier, les lecteurs d’écran, les repères. Mesurés, pas devinés — et corrigés dans le même passage.
- mettre des tests là où il n’y en a pasTrois étages : les pièces isolées, les parcours entiers, et l’œil qui compare les rendus d’une version à l’autre.
- voir ce qui a changé à l’écran sans le chercherDeux captures, une comparaison. Ce qui a bougé apparaît, y compris ce qu’on n’avait pas prévu de changer.
- savoir si mon interface tient deboutLa direction artistique relue par quelqu’un qui n’a pas la main dessus, et la page en ligne comparée à ce qu’elle prétend être.
- réécrire les textes de mon interfaceLes boutons, les messages d’erreur, les états vides. C’est là que les gens décrochent, et c’est ce qu’on écrit en dernier, mal.
- qu’on me dise que j’ai tortUne décision est prise. Avant de l’exécuter, quelqu’un cherche méthodiquement à la démolir — et propose ce qu’on n’a pas envisagé.
- savoir combien ça va coûterL’hébergement, les appels aux modèles, les services tiers. Estimés par palier d’usage, et coupés là où ça ne sert à rien.
- choisir mes outils sans le regretterLa stack, l’architecture, et la bibliothèque UI. Chaque choix vient avec sa raison et ce qu’on a écarté.
- comprendre ce que veulent mes utilisateursDes réponses d’enquête, des retours en vrac, des chiffres. Traduits en décisions, pas en jolis graphiques.
Réparer
Quelque chose est cassé et je ne sais pas quoi
- réparer un build qui ne passe plusL’erreur est lue, la cause cherchée, le correctif proposé — et si c’est la CI qui casse, elle est réparée à la source.
- arrêter de refaire la même erreurLa troisième fois qu’un échec revient, ce n’est plus un accident. On cherche le motif, pas l’occurrence.
- remettre la CI d’aplombLe pipeline lui-même est le problème : lent, instable, ou vert quand il ne devrait pas l’être.
- réparer une documentation qui mentLes chemins morts, les commandes disparues, les captures d’un écran qui n’existe plus. On mesure l’écart puis on le referme.
Publier
C’est prêt, je veux que le monde le voie
- mettre mon projet en ligneUne seule livreuse par destination. On choisit d’après le projet et la facture, pas d’après la mode.
- tenir mon propre serveurUn VPS, administré proprement : durcissement, services, sauvegardes, supervision. Sans dépendre d’un fournisseur qui change ses prix.
- publier une versionLa release totale : le feu vert, le rangement, la documentation, le changelog, le site, et le kit de communication prêt à partir.
- soigner ma fiche sur les magasinsLe titre, les mots-clés, les captures, la description. C’est ce que les gens voient avant de décider — et c’est souvent bâclé.
- faire payer mon applicationAbonnement, achat unique, essai gratuit : le modèle se choisit, puis se branche — StoreKit, RevenueCat, le paywall et ses écrans.
- raconter ce qui a changéLe diff en langue courante, pour l’équipe, les clients, ou le journal du produit — et une vidéo quand les mots ne suffisent pas.
Tenir
Je veux que ça dure au-delà de cette semaine
- finir ma séance sans rien perdreLe geste de fin : ce qui a été fait est commité, ce qui reste est écrit, et la prochaine séance peut reprendre sans rien reconstruire.
- avancer pendant que je dorsUne tâche longue est lancée le soir et trouvée faite au matin — ou bien c’est le backlog qui a été écrit pendant la nuit.
- transformer les tickets en pull requestsLa boucle complète : un ticket étiqueté est pris, compris, implémenté, et rendu en PR relue. Sans qu’on ait à le lancer à chaque fois.
- répondre aux tickets sans y passer la journéeLes tickets entrants sont triés, les doublons fermés, les manques signalés, les réponses écrites. Il reste ceux qui méritent une décision.
- que le projet se souvienneCe qui a été décidé, essayé, écarté — capturé au fil de l’eau, rangé, et relu quand la même question revient.
- transformer un geste en habitude automatiqueUn audit qu’on refait tous les lundis devient une routine qui tourne toute seule et ne prévient que s’il y a quelque chose à dire.
- enchaîner plusieurs passes d’un coupQuand on sait déjà ce qu’on veut — un audit complet, une revue, une pré-release — une seule commande enchaîne les arcanes dans l’ordre.