Drive Talk Supercar Club

Chaque décision a été prise avec le fondateur, en lui donnant de quoi arbitrer plutôt qu'un avis technique à croire sur parole.

• Reconstruire plutôt que rafistoler

  La plateforme a été reprise de zéro : une base de données pensée pour le club, une interface de programmation qui la dessert, un site construit dessus. Node.js et TypeScript côté serveur, GraphQL comme couche d'accès, MongoDB pour les données, Next.js côté visiteur, hébergement Vercel et mise en production automatisée.

  Pourquoi

  L'outil demandé n'était pas une vitrine améliorée, c'était un logiciel de club. Continuer à empiler des rustines sur un constructeur de site aurait coûté plus cher à deux ans, pour un résultat plafonné par ce que l'outil savait faire.

• Une connexion par code à usage unique, écrite sur mesure

  Les membres se connectent avec un code reçu par email, sans mot de passe et sans compte à créer.

  Pourquoi

  Les membres du club ont entre 35 et 65 ans et n'ont aucune envie d'un compte de plus, avec un mot de passe de plus à retenir. C'est la raison principale, et elle vaut plus que n'importe quel argument technique : une barrière à l'entrée sur un club payant se paie en adhésions qui ne se terminent pas.

  Un code reçu par email ne demande rien à retenir. En prime, l'accès suit la sélection du club plutôt qu'une inscription libre, et personne n'a de file de mots de passe oubliés à traiter.

• Rendre au club la main sur ses contenus

  Les textes, les programmes, les partenaires et les articles se modifient depuis une interface d'administration, sans toucher au code.

  Pourquoi

  Une correction d'horaire ne doit pas dépendre de ma disponibilité. C'est aussi ce qui permet à la plateforme de continuer à vivre quand je n'y suis plus.

• Arrêter de poser deux fois la même question

  La plateforme garde en mémoire, quelques instants, les réponses qu'elle vient de recevoir du service extérieur, au lieu de les redemander à chaque visiteur.

  Pourquoi

  C'est la décision qui illustre le mieux comment je travaille, et elle mérite d'être racontée en entier.

  Le service extérieur est facturé par tranche d'appels. Tant que le trafic restait modeste, personne ne le remarquait. En grandissant, la plateforme s'est mise à redemander les mêmes informations en boucle : chaque visiteur, sur chaque page, déclenchait un nouvel appel pour une réponse identique à celle donnée à quelqu'un d'autre quelques secondes plus tôt. Le compteur montait, et le palier suivant représentait une augmentation permanente de la facture.

  Il y avait deux façons de régler ça. Payer le palier supérieur, ce qui règle le problème tant qu'on accepte de payer davantage chaque mois, pour toujours. Ou arrêter de poser deux fois la même question. J'ai mis en place une mémoire tampon : la première demande va chercher l'information, les suivantes sont servies depuis cette mémoire, jusqu'à ce que l'information soit considérée comme périmée et redemandée.

  Depuis, les pages se chargent en moins de 350 millisecondes, avec le même abonnement qu'avant. Ce n'est pas un exploit technique, c'est un arbitrage : quelques jours de travail une fois, contre une facture qui aurait augmenté tous les mois.

• Migrer le référencement adresse par adresse

  Chaque adresse de l'ancien site a été redirigée vers son équivalent sur le nouveau, avec des descriptions et un plan de site reconstruits.

  Pourquoi

  C'est l'opération qui casse le plus souvent une refonte, et elle ne se rattrape pas après coup. Le trafic acquis en quatre ans valait plus que le temps passé à cartographier les anciennes adresses.

• Une application iOS native sur la même interface de programmation

  Une application Swift et SwiftUI, apprise en autonomie, branchée sur l'interface de programmation déjà construite pour le site.

  Pourquoi

  Les membres consultent le club depuis leur téléphone. Comme la couche d'accès aux données existait déjà et ne dépendait pas du site, l'application n'a rien eu à redévelopper côté serveur : c'est ce choix d'architecture, fait deux ans plus tôt, qui a rendu l'extension possible sans repartir de zéro.

• Chiffrer une fonctionnalité avant de l'écrire

  Avant chaque ajout notable, une étude de faisabilité économique : coût d'hébergement, coût des services tiers, coût à l'échelle visée.

  Pourquoi

  Le fondateur pouvait ainsi choisir entre développer, acheter ou reporter, sur des chiffres et non sur une intuition. Une fonctionnalité qui coûte plus qu'elle ne rapporte au club se voit avant de l'écrire, pas après.