eSimphony est construit par une équipe d'ingénierie de cinq personnes. Le produit couvre plus de 150 pays, livre des applications iOS et Android natives, fait tourner une stack d'intégration opérateur multi-régions, prend en charge cinq langues de bout en bout et livre des changements produit chaque semaine. Nous ne sommes pas un opérateur de mille personnes. Nous sommes une petite équipe qui opère avec un levier délibéré.

Le levier vient d'une approche spécifique de l'ingénierie que nous avons intériorisée au cours des 18 derniers mois. Nous l'appelons développement IA-natif. Voici à quoi cela ressemble en pratique.

La forme de l'équipe

Cinq ingénieurs. Une designer produit. Un CEO qui écrit encore certaines specs produit. Pas de chef de produit formel — les specs viennent du CEO + d'un brouillon assisté par Moza + du jugement d'ingénierie. Pas d'équipe QA dédiée — le test fait partie de la boucle de construction. Pas de DevOps séparée — l'infrastructure appartient à celui qui livre la fonctionnalité.

Ce n'est pas une vantardise. C'est une contrainte. Avec cette taille d'équipe, la seule façon de livrer un produit à l'échelle d'eSimphony est de multiplier la production de chaque ingénieur. L'IA est le multiplicateur sur lequel nous nous sommes appuyés.

Le workflow en cinq étapes

Chaque changement chez eSimphony — d'une correction de copy à une nouvelle intégration opérateur — passe par les mêmes cinq étapes. Chaque étape est assistée par l'IA ; chaque étape a un humain dans la boucle.

1. Découvrir (sans barrières techniques)

Quand une nouvelle exigence arrive (« il faut intégrer l'opérateur X pour la couverture Égypte »), le premier réflexe de l'ingénieur n'est pas de supposer ce qu'il ne sait pas. C'est d'utiliser l'IA pour explorer le territoire inconnu en 20 minutes au lieu de 2 jours.

En pratique : un ingénieur qui n'a jamais intégré de MVNO égyptien peut donner à un assistant IA la documentation API de l'opérateur, obtenir un résumé structuré de la surface d'intégration, poser des questions de suivi sur les cas limites (« quel est le flux eKYC typique pour ce marché ? »), et produire une évaluation d'une page sur l'effort, les risques et les inconnues avant le déjeuner.

Ce qui change : le goulot d'étranglement n'est plus « avons-nous un ingénieur qui connaît ce domaine ? ». C'est « l'ingénieur que nous avons, augmenté par l'IA, peut-il devenir suffisamment compétent dans ce domaine en quelques heures ? ». Presque toujours, oui.

2. Spécifier (en heures, pas en semaines)

La plupart des specs produit dans la plupart des entreprises prennent 1 à 3 semaines : un PM rédige, les parties prenantes relisent, les cas limites s'ajoutent, les critères d'acceptation se raffinent, puis l'ingénierie re-cadre le scope. Au moment où une spec est « terminée », l'opportunité d'origine a changé.

Notre approche : l'ingénieur (ou le CEO, selon la fonctionnalité) rédige une idée produit en une ligne. L'IA la développe en un PRD structuré — flow utilisateur, cas limites, métriques de succès, critères d'acceptation, questions ouvertes. L'équipe affine en une session de travail de 45 minutes. La spec est livrée à l'ingénierie le jour même.

Le compromis : les specs issues de ce processus sont légèrement plus brutes qu'une spec traditionnelle de 2 semaines menée par un PM. Nous l'acceptons. La compression du temps avant première implémentation vaut l'ambiguïté supplémentaire, qui se résout pendant la construction, pas avant.

3. Concevoir (boucle de feedback rapide)

Pour les fonctionnalités à forte composante UI, notre designer travaille aux côtés de l'ingénieur dans une boucle « design-build-feedback » mesurée en minutes, pas en jours. Des maquettes générées par IA (plugins Figma + générateurs d'images) explorent rapidement les variantes. L'ingénieur livre un prototype en quelques heures. La designer le revoit sur du matériel réel. L'itération se mesure en cycles dans la même journée.

Le résultat, c'est que design et ingénierie ne sont pas séquentiels — ils sont concomitants. Au moment où le design est « final », l'implémentation est déjà aux trois quarts vers la production.

4. Construire (l'IA écrit le code ; les humains relisent chaque diff)

C'est la partie IA-native la plus visible. Le processus d'ingénierie chez eSimphony aujourd'hui :

L'IA génère ~90 % du nouveau code (Cursor, Claude, GitHub Copilot, souvent en combinaison)
Les ingénieurs écrivent les décisions architecturales, les limites d'intégration, la logique métier délicate qui exige une connaissance profonde du système
100 % du code est relu par un humain avant fusion. Chaque diff. Chaque PR. Aucune exception.

Ce dernier point est critique et souvent mal compris. « L'IA écrit le code » ne signifie pas « aucun humain ne regarde le code ». Cela signifie que le rôle de l'ingénieur passe de saisir l'implémentation à relire l'implémentation. Le travail cognitif — est-ce que cela correspond à la spec, est-ce que cela gère les cas limites, est-ce que cela s'inscrit dans l'architecture, est-ce que cela passe à l'échelle — reste celui de l'ingénieur. Le travail mécanique — traduire l'intention en code syntaxiquement correct et idiomatique — est délégué.

Une PR typique chez eSimphony comporte :

200 à 800 lignes de code modifiées (contre ~100 à 200 traditionnellement dans les équipes de l'ère 2024)
1 ingénieur qui relit en détail
Souvent des tests unitaires générés par IA avec >80 % de couverture sur le nouveau code
Des commentaires de relecture centrés sur l'architecture, pas la syntaxe

5. Livrer (s'adapter en minutes)

La livraison est progressive : feature flags pour les changements risqués, déploiements canari pour les services backend, télémétrie surveillée par IA qui fait remonter les anomalies en quelques minutes après le déploiement. Quand un déploiement casse quelque chose, le rollback se mesure en minutes, pas en heures.

La partie « télémétrie surveillée par IA » mérite une phrase : après le déploiement, un agent IA surveille les anomalies dans les taux d'erreur, la latence, les remontées utilisateurs et la conversion. Quand les anomalies franchissent un seuil, l'ingénieur d'astreinte est alerté avec un résumé des causes racines probables. Cela comprime le temps avant détection, de « un utilisateur signale un bug à 9 h » à « alerte déclenchée à 09 h 03 ».

Les chiffres

Métriques approximatives des 12 derniers mois :

Cycle de sprint : 1 semaine. Les nouvelles fonctionnalités sortent chaque semaine ; les petites corrections sortent chaque jour.
5 ingénieurs travaillant à temps plein sur le produit. Un ingénieur supplémentaire en mission partielle.
>90 % du nouveau code est généré par IA (Cursor + Claude principalement).
100 % du code mergé a été relu par un humain.
Temps médian entre la spec de fonctionnalité et la production : 5 à 10 jours.
Incidents en production par trimestre : 1 à 2. Sous la moyenne du secteur pour notre périmètre.
Tickets de support client escaladés vers l'ingénierie : ~5/semaine. La plupart sont résolus dans la même journée.

Ces chiffres ne sont pas théoriques. C'est le tempo opérationnel réel de notre équipe.

Ce que ce n'est pas

Il vaut la peine d'être explicite sur ce que le développement IA-natif chez eSimphony ne signifie pas.

Ce n'est pas du « vibe coding ». Le code est relu ligne par ligne. Les décisions architecturales sont prises par des humains. L'IA accélère la frappe, pas la pensée.

Ce n'est pas « pas de tests ». Les tests générés par IA ont des faiblesses spécifiques (ils tendent à tester les chemins heureux plus à fond que les cas limites), donc les ingénieurs ajoutent des tests écrits à la main pour les cas limites. La couverture de tests est constamment au-dessus de 80 % sur le nouveau code.

Ce n'est pas « pas besoin d'ingénieurs seniors ». Au contraire. L'IA augmente dramatiquement la valeur du jugement senior, parce que les ingénieurs seniors peuvent relire et affiner la sortie de l'IA 5 à 10 fois plus vite qu'ils ne pourraient l'écrire de zéro. Les ingénieurs juniors qui utilisent l'IA sans relecture senior tendent à produire du code qui compile mais qui est structurellement fragile.

Ce n'est pas « pas de réflexion design ou produit ». L'IA est inutile sans spécifications claires et flux utilisateur bien pensés. Le travail cognitif du « que devons-nous construire, pourquoi, pour qui » reste humain.

Ce que cela exige

Trois choses, par ordre d'importance.

1. Une revue humaine stricte

Chaque ligne de code généré par IA passe par la revue d'un ingénieur senior avant fusion. La tentation de sauter la revue pour des petits changements « manifestement corrects » est réelle et dangereuse. Nous avons tenu la ligne sur 100 % de revue.

2. Des garde-fous architecturaux serrés

Quand l'IA génère du code, elle suit les conventions locales. Conventions fortes = sortie IA forte. Nous avons beaucoup investi dans des frontières de modules claires, des nommages cohérents, des interfaces bien typées et une documentation explicite du « comment on fait les choses ici » afin que l'IA puisse pattern-matcher proprement.

3. Une acceptation culturelle de l'IA par défaut

L'équipe a convenu, explicitement, que l'assistance IA est le défaut dans chaque workflow. Les nouveaux ingénieurs sont onboardés dans ce défaut. La résistance (« mais je préfère l'écrire moi-même ») est entendue et discutée, mais la norme d'équipe est que l'IA gère le travail mécanique sauf raison spécifique de ne pas le faire.

Ce que nous n'utilisons pas l'IA pour faire

Relire le code généré par IA (nous voulons un regard humain frais)
Décider ce qu'il faut construire (la stratégie produit est humaine)
Les escalades directes de support client (les humains gèrent les cas difficiles)
Les évaluations de performance et les feedbacks d'équipe (humain uniquement)
Les décisions d'embauche (humain uniquement, augmenté par l'IA pour le sourcing et le screening)

Le schéma : l'IA augmente l'exécution ; les humains possèdent les décisions.

Pourquoi cela compte pour le produit

La sortie de ce workflow est visible dans le produit. Nous avons livré :

L'architecture eSIM à vie (un projet multi-trimestriel dans la plupart des entreprises)
Moza, le compagnon de voyage IA, en cinq langues
Les forfaits dynamiques IA sur trois régions
Le dépannage IA avec auto-réparation
Des applications iOS et Android natives avec des sorties hebdomadaires
Un backend multi-régions avec >99,9 % de disponibilité
Une localisation 5 langues sur toute la surface du produit

Cette liste demande normalement 30 à 50 ingénieurs et plus de 3 ans. Nous l'avons livrée avec 5 ingénieurs en 18 mois.

Une note sur le recrutement

Nous faisons croître l'équipe avec précaution. Les ingénieurs qui réussissent ici partagent trois traits :

Du jugement élevé plutôt qu'un volume élevé. L'IA gère la frappe ; nous voulons des ingénieurs qui excellent à relire, décider, façonner.
À l'aise avec l'IA comme un pair. Des ingénieurs qui traitent l'IA comme un collègue (lui déléguer, la relire, la contredire) plutôt que comme un oracle magique ou une menace pour leur identité.
Le souci de l'utilisateur. Les workflows IA-natifs sont assez rapides pour produire beaucoup de code qui compile mais ne compte pas. Les ingénieurs qui ancrent chaque PR dans « est-ce que ça aide l'utilisateur » produisent le meilleur travail.

Si c'est vous, nous recrutons. Contactez-nous via la page carrières ou écrivez directement à Trung.

Ce qui sort ensuite

Le même workflow qui a construit le produit actuel livre la feuille de route :

Gestion multi-eSIM (mai 2026)
Forfaits famille (juin 2026)
Fidélité et récompenses (août 2026)
Couverture opérateur direct dans le monde entier (2027)

Chacun de ces projets est multi-mois dans un opérateur traditionnel. Nos estimations internes voient les quatre arriver dans les délais, avec la même équipe de cinq personnes.

C'est le levier. C'est le pari. C'est ainsi qu'une petite équipe livre contre toute une inertie sectorielle.

Voyez eSimphony en action, lisez notre positionnement, ou consultez notre pitch deck de MVNO Nation Americas.

Comment une équipe de 5 personnes livre à la vitesse 10× : l'ingénierie IA-native chez eSimphony