Stage chez Suitime, 6 juillet au 7 août 2026

Journal de stage

Cinq semaines à temps plein sur SYNCRO, une application que je développais déjà pour Suitime depuis avril. C'est pendant ce stage qu'elle a été mise en production et publiée sur l'App Store et Google Play.

5
semaines à temps plein: 2
stores, App Store et Google Play: 53
routes d'API passées en TypeScript: 13
écrans maquettés

Quand le stage a commencé, la base de l'application existait déjà (comptes, groupes, planning, notifications). Les détails techniques internes à Suitime ne sont pas présentés ici.

Semaine 1

6 au 10 juillet

Mise en ligne et notifications

Mise en ligne du site vitrine : accueil, quatre pages légales, identité visuelle.
Un back-office réservé à l'équipe : tableau de bord, utilisateurs, groupes et invitations.
Mise en prod sur un serveur Linux (Nginx, PM2, HTTPS), avec un déploiement automatique et sans coupure.
Les notifications push, côté serveur et côté appli.
Passage au nom de domaine définitif pour le site, l'appli et les liens d'invitation.

Semaine 2

13 au 17 juillet

Back-end en TypeScript et sécurité

J'ai fait le tour de tout le code et écrit un petit guide pour m'y retrouver vite.
Passage du back-end de JavaScript à TypeScript : 14 modules partagés puis 53 routes d'API, par petits lots et sans coupure. Les erreurs se voient maintenant avant la mise en ligne.
Relecture des permissions des routes sensibles, une par une, et correction d'un souci de cloisonnement entre groupes.
Une validation des champs centralisée dans un seul outil au lieu d'être recopiée partout.
Une protection contre les tentatives de connexion à répétition.

Semaine 3

20 au 24 juillet

Le refus d'Apple, et ce qu'il a montré

Apple refuse l'appli : ses testeurs n'arrivent pas à se connecter. En cherchant, je découvre que la connexion était cassée en prod depuis cinq jours pour tout le monde. De vieux fichiers restés sur le serveur après la migration étaient utilisés à la place des nouveaux.
Je répare, puis je corrige le script de déploiement : suppression automatique des vieux fichiers et test de connexion à chaque mise en ligne.
Déploiement par Git au lieu d'envoyer les fichiers à la main.
Vérification des jetons Google et Apple renforcée, avec des tests.
Correction de l'invitation par QR code, qui bloquait sans rien dire le retour d'un membre dans un groupe qu'il avait quitté.
Nouveaux écrans de connexion et d'inscription.

Semaine 4

27 au 31 juillet

Maquettes, validation Apple et correctifs

Nouvelle page de profil, maquettée et validée avant de coder. Les éléments communs sont regroupés dans un seul fichier : un changement de style se fait à un endroit au lieu de quatre.
Une grosse évolution du produit à cadrer. Au lieu d'un long texte, j'ai fait treize écrans maquettés en clair et en sombre, parce que le changement inversait une logique centrale de l'appli et qu'un texte risquait d'être mal compris.
Pour chaque décision, je proposais plusieurs options avec leurs limites. Le choix revenait aux responsables.
J'ai aussi listé les cas limites et ce qui risquait de casser dans l'existant.
Suppression de compte depuis l'appli (obligatoire chez Apple), avec le cas du propriétaire de groupe qui doit d'abord transmettre son groupe.
L'appli est validée sur l'App Store, puis une série de correctifs : vue Couverture plus lisible, limite de membres relevée, notifications iOS, liens d'invitation qui ouvrent directement l'appli.

Semaine 5

3 au 7 août

Publication, accessibilité et dernier bug

Un écran prêt mais caché derrière un interrupteur dans le code, parce qu'il manquait encore un prérequis côté entreprise. Il sera prêt à activer le moment venu.
Les notifications iPhone n'avaient jamais marché, sans aucun message d'erreur. J'ai comparé point par point avec une autre appli de l'entreprise où elles marchaient : trois différences, toutes corrigées.
Un indicateur d'état visible dans l'appli, pour que le prochain diagnostic ne demande ni serveur ni Mac.
Les bandeaux de six écrans, qui avaient dérivé à force de copier-coller, réunis en un seul : 259 lignes de code en moins.
Accessibilité : les zones tactiles sans libellé pour les lecteurs d'écran passent de 62 à 26, et les boutons atteignent la taille minimale conseillée par Apple et Google.
Dernier jour : un membre pouvait être bloqué sur le même créneau par deux groupes. La protection existait, mais elle était fausse pour les horaires qui passent minuit (une équipe de nuit, par exemple). Nouvelle méthode de comparaison, testée sur les cent combinaisons possibles plutôt que sur quelques cas.

Ce que j'en retiens

Une protection qui existe n'est pas forcément une protection qui marche. Les deux plus gros bugs venaient de garde-fous déjà là, mais faux. Il faut vérifier qu'ils tiennent sur les cas limites.
Réparer, puis empêcher que ça revienne. Corriger la connexion n'aurait servi à rien sans le test automatique à chaque déploiement.
Comparer avec ce qui marche déjà. Pour les notifications iPhone, partir d'une appli qui fonctionnait a été plus rapide et plus sûr que d'inventer.
Remonter le problème plutôt que trancher seul. Quand j'ai trouvé trois valeurs différentes pour un même réglage, je l'ai signalé : c'était une décision produit, pas technique.
Maquetter quand les mots ne suffisent pas. Montrer des écrans a évité de construire une fonctionnalité sur un malentendu.
Assumer mes erreurs. Un matin j'ai affirmé un truc faux sur les règles d'Apple. Je l'ai corrigé par écrit l'après-midi même.