Les décisions d'architecture qu'on ne peut pas défaire

J'ai pris des décisions d'architecture qui ont été rentables pendant des années. J'en ai aussi pris d'autres qui m'ont hanté tout aussi longtemps. La différence entre les deux tenait rarement au choix de la "bonne" technologie. C'était une question de comprendre quels choix t'enferment et lesquels tu peux revoir plus tard.

Chez Cantoo, notre plateforme télécom cloud, et chez OneRagtime, où j'ai construit un pipeline de données VC de zéro, j'ai appris ça à mes dépens. Voici ce que je sais aujourd'hui sur les décisions techniques qui s'accumulent au fil du temps.

Les décisions qui t'enferment

Toutes les décisions d'architecture ne se valent pas. Certaines, tu peux les changer au prochain trimestre. D'autres deviennent des murs porteurs. L'astuce, c'est de savoir lesquelles sont lesquelles avant de t'engager.

Chez Cantoo, la décision la plus structurante a été la façon dont nous gérions le routage voix. Nous avons construit un moteur de routage multidimensionnel qui optimisait simultanément le coût, la qualité et la latence. L'alternative était plus simple : prendre la route la moins chère et passer à autre chose. Mais les marges en télécom sont ultra-fines, et quelques millisecondes de latence ou une légère baisse de qualité audio pouvaient nous faire perdre un client opérateur définitivement.

Ce moteur de routage est devenu le cœur de notre avantage concurrentiel. Chaque fonctionnalité construite ensuite, le pipeline de facturation en temps réel, l'infrastructure auto-scaling, la couche de détection de fraude, tout reposait sur cette logique de routage. Si on s'était trompés, réécrire ce composant aurait signifié tout réécrire.

La leçon : identifie le composant dont tout le reste va dépendre. C'est ton mur porteur. Passe du temps supplémentaire dessus. Fais-le relire par quelqu'un qui a construit quelque chose de similaire. Ne le bâcle pas parce que tu as hâte de livrer des fonctionnalités.

Quand la simplicité l'emporte

Chez OneRagtime, j'ai conçu un pipeline de données appelé Deepdive. Son rôle était de découvrir, qualifier et classer des startups pour l'équipe d'investissement. Nous passions au crible plus de 4 000 deals par an, et le pipeline devait extraire des données de dizaines de sources, les normaliser, les scorer et faire remonter des recommandations.

La tentation était de construire quelque chose de sophistiqué dès le premier jour. Une architecture microservices avec event sourcing, une base de données graphe pour le mapping de relations, des modèles de ML pour le scoring. J'ai vu des équipes prendre ce chemin. La plupart passent six mois à construire de l'infrastructure sans jamais livrer le produit.

À la place, on a commencé avec une app Django monolithique, une base PostgreSQL et un ensemble de scripts Python qui tournaient de façon planifiée. Ce n'était pas élégant. Mais ça fonctionnait en quelques semaines, pas en mois. L'équipe d'investissement l'utilisait pour prendre de vraies décisions pendant que nos concurrents débattaient encore de leur stack technique.

On a ajouté de la complexité uniquement quand les données prouvaient qu'on en avait besoin. La couche de web scraping a eu son propre service quand elle a commencé à ralentir l'app principale. Le modèle de scoring est devenu un module séparé quand l'équipe a voulu itérer dessus indépendamment. Chaque évolution était motivée par un vrai goulot d'étranglement, pas un hypothétique.

La question de la base de données

Si je devais donner un seul conseil aux CTO en early-stage, ce serait celui-ci : réfléchis plus à ton modèle de données qu'au choix de ton framework.

Chez Cantoo, on utilisait PostgreSQL pour les données transactionnelles et ClickHouse pour l'analytics. Ce split était délibéré. Le trafic voix génère d'énormes volumes de données d'événements, des millions de CDR (call detail records) par jour. Essayer de faire tourner des requêtes de facturation en temps réel et de l'analytics historique sur la même base de données aurait été un désastre.

Mais on n'a pas commencé avec ClickHouse. On a commencé avec PostgreSQL pour tout et migré la charge analytics quand les temps de requête ont commencé à poser problème. L'essentiel, c'est qu'on avait conçu notre modèle de données en anticipant cette séparation. Les tables étaient propres. Les frontières entre données transactionnelles et analytiques étaient bien définies. Quand la migration a eu lieu, ça a pris des semaines, pas des mois.

Compare ça avec ce que j'ai vu pendant les due diligences techniques chez OneRagtime. Des startups avec des modèles de données emmêlés, où les données utilisateur, de facturation et produit étaient entrelacées de façon à rendre presque impossible le scaling de chaque dimension indépendamment. Ce genre de bazar n'arrive pas à cause de mauvais choix technologiques. Ça arrive parce que personne ne s'est arrêté pour réfléchir aux frontières des données suffisamment tôt.

Ce que j'ai raté

Je ne suis pas immunisé contre ça. Chez Cantoo, j'ai surinvesti dans Kubernetes trop tôt. On était une équipe de deux ingénieurs qui faisait tourner une plateforme sans assez de trafic pour justifier la charge opérationnelle de K8s. J'ai passé des semaines à configurer l'auto-scaling, mettre en place le monitoring et débugger des problèmes réseau qui n'auraient pas existé sur un déploiement plus simple.

La plateforme a fini par en avoir besoin. Kubernetes est devenu indispensable une fois qu'on a eu de vrais clients opérateurs et qu'il fallait une fiabilité de grade opérateur. Mais pendant les six premiers mois, quelques VMs derrière un load balancer auraient largement suffi. J'ai laissé mon enthousiasme pour la technologie prendre le dessus sur mon jugement de ce dont on avait réellement besoin à ce stade.

Chez OneRagtime, j'ai sous-estimé à quel point le pipeline Deepdive allait devoir évoluer. Je l'ai construit comme un système de batch processing parce que ça correspondait au besoin initial : lancer le scraping et le scoring une fois par jour. Mais l'équipe d'investissement a vite voulu des alertes en temps réel quand une startup atteignait certains seuils. Retrofitter des capacités temps réel sur un système batch, c'est douloureux. Si j'avais conçu dès le départ une couche event-driven, même simple, la transition aurait été plus fluide.

Un framework pour les décisions d'architecture

Après des années à prendre ces décisions, j'ai développé un cadre mental qui m'aide à les évaluer. Ça se résume à trois questions.

Cette décision est-elle réversible ? Si tu peux la changer en un sprint, ne te prends pas la tête. Si la changer plus tard implique de réécrire la moitié du système, investis le temps maintenant pour bien faire.

À quoi ça ressemblera à 10x ? Tu n'as pas besoin de construire pour 10x aujourd'hui. Mais tu dois t'assurer que ce que tu construis aujourd'hui ne t'empêche pas activement d'y arriver. Évite les conceptions qui créent des plafonds durs.

Qui d'autre doit comprendre ça ? Une architecture que seul l'auteur original peut maintenir est un handicap. J'ai vu des systèmes brillants devenir des goulots d'étranglement parce qu'ils étaient trop malins. La meilleure architecture est celle que ton équipe peut comprendre, débugger et étendre sans toi dans la pièce.

L'effet cumulatif

Les bonnes décisions d'architecture s'accumulent comme de bons investissements. Le moteur de routage de Cantoo a permis des fonctionnalités qu'on n'avait même pas imaginées quand on l'a construit. Le modèle de données propre d'OneRagtime a rendu possible l'ajout de nouvelles sources de données en jours plutôt qu'en semaines.

Les mauvaises décisions s'accumulent aussi, mais dans l'autre sens. Chaque raccourci dans ton modèle de données, chaque frontière floue entre services, chaque optimisation prématurée qui ajoute de la complexité, tout ça crée une résistance qui te ralentit un peu plus chaque mois.

La différence entre les équipes qui livrent vite et celles qui stagnent tient rarement au talent ou aux outils. C'est le poids accumulé de leurs décisions d'architecture passées. Choisis avec soin. Les décisions que tu prends ce trimestre façonneront encore ton produit dans des années.