Étude de cas
Un moteur de formulaires, trois apps grands comptes
Les apps d'inspection, d'audit et de reporting d'Enablon tirent leurs écrans du même moteur de formulaires natif. J'ai porté ce moteur côté iOS pendant plus de cinq ans, pendant que trois produits sortaient dessus.
Pas le temps d'un appel ? Écrivez-moi : chaque e-mail reçoit une réponse sous un jour ouvré.
- Client
- Enablon (Wolters Kluwer)
- Rôle
- Référent technique iOS
- Période
- 2019 à 2024
Le problème
Les clients grands comptes configurent leurs propres formulaires : l'app ne peut pas connaître ses écrans à l'avance. Chaque champ, règle et dépendance vient du serveur, doit fonctionner hors ligne dans une usine, et ne doit casser aucune des deux autres apps qui partagent le moteur.
Ce que j'ai fait
Formulaires pilotés par le serveur
Écrans construits à l'exécution depuis la définition du serveur : champs conditionnels, règles de validation, dépendances entre champs et valeurs pré-remplies.
Hors ligne d'abord
Checklists remplies sans réseau, stockées localement et synchronisées à la reconnexion, parce que les inspections se font là où il n'y a pas de signal.
Un moteur, trois produits
Inspection, Go et Audit consomment le même SDK : chaque changement devait être sûr pour les trois et sortir sur un calendrier commun.
Plomberie grands comptes
OAuth 2.0 avec PKCE, APIs OData, support de l'arabe en lecture de droite à gauche et refonte en 12 langues de l'app Go.
Où ça en est
Trois apps sur un moteur
Inspection, Go et Audit livrées sur le SDK partagé, avec des releases pilotées de la release candidate à la production.
Cinq ans de responsabilité
Le moteur est resté en service à travers les versions, les équipes et les clients, ce qui est le vrai test pour ce genre de composant.
Les questions qu'on me pose
- Pouvez-vous nous construire l'équivalent ?
- Oui, et la première question est de savoir à quel point vos formulaires varient vraiment. Un moteur piloté par le serveur se rentabilise quand les clients configurent leurs écrans ; sinon c'est de la complexité payée deux fois.
- Comment éviter qu'un SDK partagé casse ses apps ?
- Des releases versionnées, une suite de tests sur le moteur de règles, et un responsable unique qui relit ce dont chaque app dépend.
Stack
- Swift
- UIKit
- SwiftUI
- Realm
- OData
- OAuth 2.0 PKCE
- Azure DevOps
Ce projet est sous NDA : les détails client et les éléments internes restent en dehors de cette page.
Prestations liées
Autres études de cas
Vous voulez construire ce genre d'app ?
Réservez un appel de 20 minutes et parlez-moi de votre app. Je vous dirai par quoi je commencerais.
Pas le temps d'un appel ? Écrivez-moi : chaque e-mail reçoit une réponse sous un jour ouvré.