Pourquoi les ingénieurs télécom font de bons CTOs

On me demande parfois comment je suis arrivé dans le leadership tech en venant du télécom. L'hypothèse, c'est que le télécom est une industrie legacy, pleine de vieux protocoles et d'infrastructures rigides. C'est en partie vrai. Mais c'est aussi le meilleur terrain d'entraînement que j'ai trouvé pour construire des produits à grande échelle.

J'ai passé des années à travailler avec l'infrastructure voix chez Legos, où on gérait 1,2 milliard de minutes par an dans 110 pays. Ensuite, j'ai cofondé Cantoo, une plateforme télécom cloud. Aujourd'hui je dirige l'engineering chez Consentio, une plateforme supply chain. Le bagage télécom a façonné ma façon d'aborder chacun de ces systèmes.

Le temps réel n'est pas optionnel

En développement web, tu peux souvent t'en sortir avec de la cohérence éventuelle. Si une notification arrive quelques secondes en retard, personne n'en meurt. Si une page met 200 millisecondes de plus à charger, les utilisateurs ne le remarqueront peut-être même pas.

En télécom, la latence tue. Littéralement, dans certains cas, parce que l'infrastructure voix dessert les services d'urgence. Quand quelqu'un compose un numéro, il s'attend à entendre une tonalité en moins d'une seconde. Si l'établissement de l'appel prend trois secondes, quelque chose est cassé. Si ça prend cinq secondes, tu perds le client.

Ça m'a entraîné à considérer la performance comme un besoin produit, pas comme une tâche d'optimisation. Chez Consentio, où on gère du trading en temps réel de produits frais périssables, cet état d'esprit s'est transféré directement. Quand un acheteur passe une commande de 20 tonnes de tomates, il a besoin d'une confirmation rapide. Les produits sont littéralement en train de pourrir pendant qu'il attend.

La plupart des développeurs web voient la latence comme un indicateur agréable à avoir. Les ingénieurs télécom la voient comme une obligation contractuelle. Ce changement de perspective modifie la façon dont tu conçois tout, des requêtes base de données aux contrats d'API.

Les protocoles t'apprennent à penser en contrats

SIP, SS7, SMPP, Diameter. Le télécom est bâti sur des protocoles conçus par des comités, débattus pendant des années et implémentés par des dizaines de fournisseurs qui interprètent tous les spécifications légèrement différemment.

Travailler avec ces protocoles t'enseigne quelque chose qu'aucune quantité de design d'API REST ne fera : l'importance de contrats stricts entre systèmes. Quand ta gateway SIP communique avec un opérateur, les deux côtés doivent être d'accord sur ce que chaque header signifie, ce que chaque code de réponse indique, et ce qui se passe quand ça tourne mal.

Ça se transpose directement dans ma façon de concevoir les API internes. Chez OneRagtime, la frontière entre la Platform (côté investisseur), le Core (opérations) et Deepdive (pipeline de données) était définie aussi clairement qu'une frontière de protocole télécom. Chaque système avait son propre modèle de données, son propre cycle de déploiement, et un contrat strict pour communiquer avec les autres.

La plupart des startups que j'ai auditées chez OneRagtime ne raisonnaient pas comme ça. Leurs services étaient fortement couplés, partageant des bases de données, important le code des autres, faisant des suppositions sur l'état interne. Ça marchait avec deux développeurs. Ça s'effondrait complètement à dix.

L'échec est l'état par défaut

Les systèmes télécom tombent en panne en permanence. Les opérateurs plantent. Les routes se dégradent. Le matériel meurt. Le trafic frauduleux explose. La question n'est jamais "est-ce que ça va tomber ?" mais "à quelle vitesse on se relève ?"

Chez Legos, j'étais en astreinte 24/7 à gérer des cores SIP, des gateways SMS et des systèmes de détection de fraude pour 100 opérateurs. Quand quelque chose cassait à 3h du matin, la correction devait arriver en minutes, pas en heures. Tu apprends très vite à concevoir pour la dégradation gracieuse.

Chez Cantoo, on a construit l'infrastructure voix avec l'auto-healing comme principe fondamental. Si un nœud de routage tombait, le trafic basculait automatiquement vers les nœuds sains. Si un opérateur commençait à renvoyer des erreurs, le moteur de routage le dépriorisait en temps réel. Aucune intervention humaine nécessaire.

C'est quelque chose que la plupart des applications web se plantent encore. Elles sont conçues pour le happy path et traitent les pannes comme des cas limites. Mais à grande échelle, les cas limites deviennent des événements quotidiens. Un système qui gère les pannes avec élégance a plus de valeur qu'un système théoriquement plus rapide mais fragile.

La conformité réglementaire comme avantage

Le télécom est l'une des industries les plus réglementées de la planète. Pour opérer au Royaume-Uni, en France et en Allemagne, comme on le faisait avec Cantoo, tu as besoin de licences séparées pour chaque pays. Tu dois respecter les exigences d'interception légale, les règles de conservation des données, les réglementations sur les plans de numérotation et les obligations de services d'urgence.

La plupart des développeurs voient la conformité comme un fardeau. En télécom, tu apprends à la voir comme un avantage concurrentiel. Obtenir les licences dans trois pays nous a pris des mois de travail. Mais une fois ces licences obtenues, elles sont devenues une barrière à l'entrée. Tout concurrent voulant offrir le même service devait passer par le même processus pénible.

Chez Consentio, j'applique la même logique à nos certifications ISO (27001, 27017, 27018). Oui, le processus de certification est exigeant. Mais il donne à nos clients, notamment Aldi, Carrefour et Kroger, la confiance que leurs données sont traitées correctement. La conformité n'est pas un coût. C'est un argument de vente.

La planification de capacité n'est pas de la devinette

En télécom, tu ne scales pas à la demande. Tu planifies la capacité des mois à l'avance parce que le provisionnement de circuits avec les opérateurs prend du temps. Tu dois savoir quel volume de trafic tu vas gérer au prochain trimestre, quelles routes vont croître, et où tu as besoin de redondance.

Cette discipline s'est transférée directement dans ma façon de penser la planification d'infrastructure dans chaque entreprise depuis. Chez Cantoo, même si on tournait sur Kubernetes avec de l'auto-scaling, on faisait quand même des revues de capacité trimestrielles. L'auto-scaling gère les pics, mais pas la croissance structurelle. Si ta base d'utilisateurs double, tu dois réfléchir à la capacité de ta base de données, aux coûts de stockage, à la bande passante réseau et à la charge opérationnelle bien avant que l'auto-scaler n'entre en jeu.

Les startups que j'ai auditées chez OneRagtime qui galéraient avec le scaling étaient presque toujours celles qui comptaient entièrement sur l'auto-scaling sans jamais faire de planification. Elles se retrouvaient à atteindre une limite de connexions base de données ou une limite de rate d'API tierce et se dépêchaient de corriger en production.

Débugger des systèmes distribués

Les ingénieurs télécom débuggent des systèmes distribués par défaut. Un appel voix peut traverser cinq ou six systèmes entre l'appelant et l'appelé : la gateway d'origine, le moteur de routage, le système de facturation, l'opérateur de destination, et divers traducteurs de protocoles en chemin. Quand la qualité d'appel se dégrade, tu dois tracer le problème à travers tous ces composants.

J'ai apporté cette approche dans chaque équipe d'engineering que j'ai dirigée. Chez Consentio, quand une commande échoue à être traitée, le processus de debugging suit le même schéma : tracer la requête à travers les services, examiner chaque point de transfert, identifier où les données ou le timing se sont mal passés.

La plupart des développeurs web sont habitués à débugger une seule application. Ils regardent les logs, posent des breakpoints et parcourent le code pas à pas. Débugger des systèmes distribués demande un état d'esprit différent : tu raisonnes en flux, pas en fonctions. Tu t'intéresses à ce qui s'est passé entre les systèmes, pas seulement à l'intérieur.

L'avantage pas glamour

Rien de tout ça n'est glamour. Les protocoles, la conformité, la planification de capacité, la récupération après panne : ce ne sont pas les sujets qui attirent l'attention dans les conférences développeur. Mais ce sont les sujets qui déterminent si ton produit survit au contact avec la réalité.

Les meilleurs CTO que je connais partagent tous un trait : ils pensent aux trucs ennuyeux. Pas au nouveau framework, pas à l'abstraction maligne, mais au monitoring, au comportement de fallback, aux vérifications d'intégrité des données, au processus de rollback de déploiement.

Le télécom m'a enseigné ça. Et c'est le plus grand avantage que j'apporte dans chaque rôle de leadership technique. L'industrie est peut-être "legacy", mais la discipline d'ingénierie qu'elle produit est tout sauf ça.