Krafteo

Le contexte

Krafteo édite une application de gestion pour les équipes terrain : planning partagé, dossiers, rapports de chantier et suivi d’activité. J’y prends en charge le cycle complet en autonomie, de la conception au déploiement et à la maintenance, en échange direct avec l’équipe produit.

La situation à mon arrivée

Le produit tenait dans deux dépôts sans lien entre eux : d’un côté l’application web Next.js, de l’autre l’API Express / Prisma. Les schémas de validation vivaient dans le serveur, et le web redéclarait à la main ce dont il avait besoin.

L’application mobile, elle, n’existait pas encore. Elle allait devenir une troisième surface, avec les mêmes formes de données à réécrire une fois de plus.

Avant. Deux dépôts séparés, aucun espace commun : ni configuration TypeScript partagée, ni schémas partagés, ni utilitaires. Chaque surface repartait de zéro.

Ce que j’ai mis en place

J’ai proposé de réunir les applications dans un monorepo TypeScript, sur pnpm workspaces et Turborepo. J’ai initialisé la structure, déplacé l’application web dans apps/web, puis créé l’application mobile de zéro dans apps/mobile (React Native, Expo). J’ai ensuite centralisé l’outillage commun : configuration TypeScript, ESLint, Prettier et hooks de pre-commit.

Après. Une seule arborescence. Les applications vivent dans apps/ et partagent depuis packages/ tout ce qui doit l’être.

Ce que j’ai fait, et ce que l’équipe a fait

Autant être précis, parce que c’est un travail d’équipe. Le monorepo, l’application mobile et la configuration partagée sont mon travail. Sur le package contracts, j’ai assisté mon maître d’apprentissage pour sa création et la migration des schémas du serveur.

Mais c’est le monorepo qui l’a rendu possible : avant, il n’y avait aucun endroit où le mettre. Et ma contribution principale aux contrats est du côté client, c’est l’objet de la section suivante.

Le reste de mon périmètre

• L’application mobile, de zéro jusqu’aux stores. Expo Router, design system NativeWind, écrans d’authentification, gestion d’erreurs, puis publication. C’est aujourd’hui l’essentiel de mon travail chez Krafteo.
• Des packages partagés. J’ai développé les utilitaires communs de récurrence d’agenda, d’adresses et de permissions, consommés par plusieurs applications du monorepo.
• La CI/CD et les livraisons mobiles. Builds et soumissions via EAS, mises à jour OTA pour corriger sans repasser par la revue des stores, et campagnes de bêta-test externes. Un cycle court entre déploiement, retour et itération.
• Les relectures de code et le process Git de l’équipe.

Ce que ça change

Une application échange en permanence des données avec son serveur : un rendez-vous, un client, un rapport d’intervention. Pour se comprendre, les deux doivent être d’accord sur la forme exacte de ces données.

Avant, chaque application décrivait cette forme dans son coin. Quand quelqu’un en modifiait une et oubliait les autres, rien ne signalait l’erreur. Elle n’apparaissait que plus tard, chez l’utilisateur. Aujourd’hui, cette description est écrite une seule fois, à un seul endroit, et toutes les applications s’y réfèrent.

Ma contribution : j’ai branché l’application mobile sur cette description partagée. Elle ne redécrit plus les données, elle les reprend. Et c’est le monorepo que j’ai mis en place qui a rendu ce partage possible, puisqu’avant il n’existait aucun endroit où poser quoi que ce soit de commun.

L’application mobile

Créée de zéro et publiée sur l’App Store et Google Play, elle est aujourd’hui l’essentiel de mon travail chez Krafteo.

Technologies

• TypeScript
• pnpm workspaces
• Turborepo
• React Native
• Expo
• Next.js
• Node.js
• Express
• Prisma
• Zod
• NativeWind
• CI/CD