Avec plus d’1,5 million d’utilisateurs par mois, Essence&CO est l’application pionnière de comparaison des prix des carburants en France. Lancée seulement quinze jours après l’ouverture de l’App Store, elle a marqué l’histoire du mobile en France. Mais au-delà de son rôle grand public, Essence&CO est surtout, pour Ripple Motion, un terrain d’expérimentation et de montée en compétences.
Essence&CO, app historique au SI complexe, a été refondue en SwiftUI avec une approche industrielle. Olivier Tabone, CTO, partage choix et innovations internes. Découvrez les raisons de cette refonte et les choix techniques qui l’ont guidée.
Pourquoi avoir décidé de refaire Essence&CO ?
Olivier Tabone : Trois raisons principales ont conduits à ces travaux :
- Un retard technique : le code iOS était devenu difficile à maintenir. Il nous fallait trouver un équilibre entre la qualité du service rendu aux utilisateurs et une maîtrise des temps de maintenance.
- Un périmètre trop large : nous avons empilé des fonctionnalités qui ne correspondent plus à la réalité économique de l’app. Rappelons qu’Essence&CO est un service gratuit.
- Un rôle de laboratoire : Essence&CO est, pour Ripple Motion, un terrain d’expérimentation à très grande échelle. Nous avons voulu repartir de zéro pour tester SwiftUI dans son intégralité, sans compromis et avec notre niveau d’exigence.
Pourquoi ne pas avoir basculé sur SwiftUI dès 2019 ?
Olivier Tabone : SwiftUI n’était pas assez stable. D’une version à l’autre du SDK, il fallait parfois réécrire des écrans. Cela aurait été trop risqué. Nous avons préféré attendre une maturité suffisante. Adopter une technologie au bon moment, quand elle est fiable est une exigence qui guide chacun de nos choix techniques.
En parallèle, nous avons priorisé les projets de nos clients. Aujourd’hui, SwiftUI est arrivé à un niveau qui permet d’envisager des projets complets.
Vos clients se posent-ils aussi la question de SwiftUI ?
Olivier Tabone : Oui, surtout pour les nouveaux projets. Une nouvelle app doit aujourd’hui être conçue en SwiftUI. Pour une application existante, il faut réfléchir au bon moment pour migrer. UIKit n’est pas officiellement déprécié, mais il n’évolue plus. À terme, rester dessus posera problème : certaines fonctionnalités deviendront inaccessibles, et il sera impossible de compiler l’app.
Il faut être réaliste : une formation des développeurs en UIKit serait désormais une perte de temps !
Nous présentons souvent deux stratégies à nos clients :
- migrer les écrans en profondeur de hiérarchie, pour limiter les transitions en fin de parcours,
- ou basculer d’abord les écrans principaux, là où se concentrent les évolutions et la maintenance.
Dans tous les cas, l’objectif est de minimiser les transitions entre UIKit et SwiftUI, car elles complexifient le projet.
Vous avez aussi testé Flutter pour cette refonte. Pourquoi avoir renoncé à l’hybride ?
Olivier Tabone : Nous avons en effet testé Flutter, mais nous n’avons pas été convaincus. Nous savons qu’il y aurait débat, les développeurs ont leurs croyances dans les technos, mais je vais essayer d’être très factuel :
- La pérennité nous semble fragile, notamment après les licenciements récents dans l’équipe Flutter chez Google.
- La promesse du “write once, run anywhere” n’est pas tenue : trop d’adaptations sont nécessaires. Il me parait difficile de « lutter » contre les milliers de cerveaux d’ingénieurs mobilisés par Apple et Google !
- Le rendu n’est pas vraiment natif, et cela se voit. En réalité, nous pensons que l’effort pour combler cet écart annule l’avantage théorique.
- Enfin, le tooling. Force est de constater qu’utiliser Android Studio et Dart pour des app iOS n’atteint pas la qualité de Xcode.
Quels ont été les piliers techniques de la refonte ?
Olivier Tabone : Nous avons structuré ce projet autour de cinq piliers qui reflètent notre exigence technique :
1. Tests d’UI : éviter toute régression
Nous avons automatisé des tests d’UI pour garantir que chaque nouvelle version de l’app fonctionne sans régression. Concrètement, chaque test génère une vidéo de son exécution : en cas d’échec, nous pouvons rejouer la séquence pour identifier la cause.
Problème : les plateformes de CI limitent le stockage des artefacts. Nous avons donc développé un outil interne qui déporte ces vidéos sur S3, avec un lien sécurisé pour y accéder à la demande.
Je pense que nous pouvons aller plus loin ici pour améliorer la rapidité des tests.
2. Coverage à 100 % : une règle d’hygiène
Nous avons atteint une couverture de 100 % des tests répétables, un niveau très rare sur mobile. Cela demande une rigueur extrême : pas de raccourcis, pas de branches de code “oubliées”.
Par exemple, nous avons dû résoudre des cas non déterministes liés aux simulateurs iOS, qui bloquaient parfois une seconde au démarrage. Cela n’apparaissait pas en local, mais seulement en CI. Nous avons créé des scripts d’observation pour identifier et corriger ce problème.
Cette règle change tout :
- le développeur est contraint d’écrire un code plus clair, plus factorisé et répétable
- la maintenance est sécurisée, car une mise à jour de librairie est validée automatiquement par les tests,
- nous pouvons même tirer parti de l’IA pour automatiser des tâches sans crainte de casser l’app. L’IA essaye de faire des choses sans comprendre ce qu’elle fait. Dans ce cadre, on peut mettre à jour une lib en modifiant un peu le code. L’ensemble des tests est lancé et permet de s’assurer du maintien du bon fonctionnement de l’app.
- Autre bénéfice : au moment d’implémenter, on est obligé de se poser toutes les questions et à préciser la Definition Of Done (DOD).
Concrètement, en développement, on pourrait être tenté de glisser sous le tapis quelques frictions pour poursuivre l’avancement. Avec notre expérience, notamment dans le cas de reprise de projets ou d’audit, on sait qu’à un moment donné (proche ou lointain), ça ressort.
3. Sécurisation des API : HTTP Message Signature
La plupart des projets sécurisent correctement les appels après authentification, mais les appels avant login restent souvent vulnérables (exemple : API de réinitialisation de mot de passe).
4. Intégration continue : du code à l’App Store en un clic
Nous avons mis en place une CI complète basée sur Xcode Cloud :
- builds rapides,
- tests automatisés,
- soumission directe à l’App Store.
Résultat : plus besoin de se demander “qui fait le build ?” ou “qui pousse en production ?”. Le processus est entièrement automatisé, fiable et traçable.
5. SwiftUI et la force des Previews
L’un des plus grands bénéfices de SwiftUI, ce sont les Previews : elles permettent de visualiser et ajuster l’UI en direct, sans relancer l’application. On a réduit drastiquement le cycle entre le « j’effectue une modification dans le code » et « je la vois ».
Couplé aux tests et à la CI, cela crée un environnement où l’on peut itérer vite, sans sacrifier la qualité. Pour les équipes, c’est un vrai gain de productivité et de confort de travail.
Quelle place tient la formation dans ce projet ?
Olivier Tabone : Une place centrale. Essence&CO est notre laboratoire d’expérimentation, mais c’est aussi un outil de formation. Nous avons constitué une équipe mixte juniors/seniors, avec l’objectif de documenter nos méthodes, nos outils et nos process.
Nous avons ensuite transformé ce retour d’expérience en formation interne pour l’équipe. C’est ce qui fait la valeur de ce type de projet : il nous permet de progresser collectivement et de consolider nos standards.
Quel bilan tirez-vous de cette refonte ?
Olivier Tabone : Tous nos objectifs ont été atteints :
- Le taux de crash de l’app a fortement baissé.
- 4 mois après la refonte, nous avons pu constater les gains lors de nos interventions sur l’app (rapidité, simplicité de la reprise en main).
- Nous avons créé des outils internes qui nous serviront sur d’autres projets.
- Enfin, nous avons formé nos équipes et enrichi nos pratiques.
Est-ce que les standards de ce projet seront les méthodes et process actés pour les projets clients de demain? Nous ne l’avons pas encore décidé.
Nous avons transformé une refonte technique en une expérience de rigueur et de transmission. Ce projet nous a permis de transposer à SwiftUI ce qui était déjà notre standard en backend (et qui reste rare dans le secteur) : le 100% coverage, faisant de cette expérimentation technique une véritable innovation interne. C’est une vraie fierté d’avoir élevé nos standards techniques sur iOS au niveau de ce que nous faisions déjà en backend.