UBBFY

Une dizaine d’entreprises y font tourner leur exploitation, la plus grande gérant deux cents salariés et prestataires. La plateforme, c’est trente-trois modules côté serveur, 338 modèles de données et près de quatre cents écrans, servis en trois langues : KPS, Planus, Flowplan, Gotolearn et People&Skill sont les tenants en production.

Je suis arrivé sur un projet déjà commencé, écrit en Laravel sur MySQL, et la première décision a été de le restructurer vers Django et PostgreSQL. Migrer des données est un travail ingrat qui se facture tard : les horodatages repris de l’ancienne base arrivaient avec une heure de retard, et ce genre d’écart ne se voit pas en recette, il se voit en production sur la feuille de temps de quelqu’un.

Ce qui a décidé de l’architecture, ce sont les parties que personne ne voit. Des droits d’accès conçus pour être configurés plutôt que codés, de sorte qu’un nouveau tenant n’implique pas un nouveau déploiement. Un bus d’événements sur Celery, pour qu’un module puisse réagir à un autre sans l’importer. Une piste d’audit, parce qu’une plateforme qui héberge l’exploitation de plusieurs entreprises doit pouvoir dire ce qui s’est passé et qui l’a fait. La facturation passe par Stripe et FedaPay ensemble, ce qu’exige réellement le fait de servir des clients européens et ouest-africains.

Ce que je n’ai pas vu venir, c’est l’internationalisation. Je ne l’ai pas prévue au départ, et la rattraper sur une base déjà écrite a mis l’environnement de développement à terre plusieurs jours. Le problème n’était pas la traduction, c’était la frontière : les chaînes de l’interface sont à moi, le contenu saisi par un tenant est à lui et doit exister dans des langues que je ne choisis pas. Une notification part maintenant dans la langue de qui la lit, pas de qui la déclenche. C’est une décision que je prends désormais le premier jour d’un projet, pas au sixième mois.

Le socle est tenu par les tests : 3 146 côté serveur, 468 parcours de bout en bout dans le navigateur.