Projet client · Reprise de produit
Getizy : nous étions la deuxième société de développement
Les applications iOS et Android existaient déjà. La société qui les avait écrites était passée à autre chose. Nous avons repris le code, corrigé ce qui était cassé, et continué à publier de nouvelles fonctionnalités sur les deux stores.
- Client
- Getizy
- Mission
- Reprise de produit
- Plateformes
- iOS et Android
- Publié sur
- App Store et Google Play
Deux parcours de l’application telle qu’elle était publiée : la commande et le paiement. Nous n’avons ni conçu ces écrans ni écrit leur première version. Nous les avons fait fonctionner, puis nous les avons complétés.
La situation
Un produit en service, et plus personne qui le connaissait
Getizy avait une application iOS, une application Android et des utilisateurs sur les deux. Ce qu’elle n’avait plus, c’était la société de développement qui les avait écrites — et toutes les raisons qui expliquaient l’état d’un fichier étaient parties avec elle.
Rien d’inhabituel à cela. Un logiciel qui tourne est la trace de décisions, et l’essentiel de cette trace vit dans la tête de ceux qui les ont prises, pas dans le dépôt de code. Ce qui reste au propriétaire, c’est un produit qui fonctionne, une liste de ce qui ne va pas, et aucun moyen de savoir à quoi il est prudent de toucher.
La vraie contrainte : pas de réécriture
Une réécriture, ce sont des mois pendant lesquels les personnes qui utilisent déjà l’application ne reçoivent plus rien, et elle jette la seule chose que le vieux code fait bien : avoir raison sur cent petits cas que personne n’a jamais écrits nulle part. Le travail consistait donc à faire fonctionner les décisions d’un autre, et à continuer de livrer pendant ce temps.
Ce que nous avons fait
Stabiliser d’abord, étendre ensuite
Quatre étapes, dans cet ordre. Une reprise qui ajoute des fonctionnalités alors que les anciens bugs sont toujours ouverts ne fait qu’allonger la liste.
Lire avant de toucher
Le premier travail n’a pas été un correctif. Il a consisté à lire le code, à faire tourner les deux applications sur le vrai backend, et à écrire noir sur blanc comment une version se publie réellement. Tant que vous ne savez pas compiler, signer et soumettre l’application vous-même, vous n’avez rien repris : vous l’empruntez.
Trier les bugs hérités
Tous les bugs connus sont entrés dans une seule liste, classée selon ce qu’ils coûtaient à l’utilisateur et non selon leur allure dans le code. Les plantages et tout ce qui bloquait un paiement d’abord. La dette cosmétique en dernier, et une partie jamais : un code hérité est plein de choses laides et justes.
Rendre la publication ennuyeuse
Les certificats, les clés de signature, les comptes sur les stores et la compilation sont passés sous notre contrôle avant que nous promettions la moindre nouvelle fonctionnalité, pour qu’une mise en production cesse d’être un événement.
Puis étendre
L’application étant publiable à la demande et la liste de bugs devenue courte, nous avons commencé à étendre le produit. Les nouvelles fonctionnalités sont sorties sur les deux stores au même rythme que les correctifs, dans des versions assez petites pour qu’une mauvaise puisse être remplacée vite.
La personne qui a lu le code est celle qui a publié les versions.
La reprise de code, comme prestation
Nous partons de zéro — ou nous reprenons ce qui existe
Un développement qui s’enlise, un prestataire parti, une application qui livre des bugs plus vite que des fonctionnalités. Hériter d’un code est une façon normale de commencer avec nous.
Tout commence par un audit de code payant
Une reprise se chiffre à partir du code, pas d’un partage d’écran. La première chose que nous vendons, c’est cet audit, facturé pour lui-même : le Product Decision Sprint, 2 500 € hors TVA et 5 jours ouvrés, rien en production. Ce montant est déduit intégralement d’un projet démarré dans les 30 jours.
Ce que nous examinons
- Si nous pouvons compiler, signer et publier l’application depuis nos propres machines, sans personne de l’équipe précédente.
- Ce que fait le code quand quelque chose échoue : erreurs, nouvelles tentatives, paiements à moitié passés.
- Quelles dépendances sont abandonnées, et quelles versions d’OS vont cesser de les tolérer.
- Où sont les données, qui peut les lire, et ce qu’une demande RGPD exigerait réellement.
- Ce qui est couvert par des tests, et si ces tests passent encore.
- Les parties auxquelles personne ne devrait toucher pour l’instant, et ce qu’il faudrait pour les rendre modifiables.
Ce que vous recevez avant tout chiffrage
- Ce qui ne va pas, en langage clair, avec le risque que porte chaque point plutôt qu’une étiquette de gravité.
- Ce qui doit être corrigé avant de pouvoir construire quoi que ce soit de neuf par-dessus.
- Ce que nous laisserions délibérément en l’état, et pourquoi.
- Les endroits où réécrire une partie revient réellement moins cher que la réparer — cela figure aussi dans l’audit.
Le développement est ensuite chiffré dans cet ordre
La stabilisation d’abord, les nouvelles fonctionnalités ensuite, les deux à prix fixe. La seconde moitié est chiffrée sur ce que l’audit a trouvé, pas sur une supposition faite avant que quiconque ait ouvert le dépôt. Si l’audit conclut que ce code dépasse ce que nous devrions prendre en charge, nous le disons, et vous aurez quand même acheté une réponse honnête.
La partie honnête
Où en est le produit aujourd’hui
Getizy a été publié sur l’App Store et sur Google Play. Le service n’est plus accessible au public.
Cette phrase reste sur la page. Ce dont nous répondons, c’est de l’ingénierie : nous avons repris un produit construit par une autre société, nous l’avons stabilisé, et nous avons continué à livrer. Ce qui est arrivé ensuite à l’entreprise, ce n’est pas à nous de le raconter.
Il n’y a pas non plus de chiffres sur cette page. Nous étions la société de développement, pas l’entreprise qui exploitait le service : les installations, le chiffre d’affaires et la croissance, ce n’a jamais été à nous de les publier.
Ce que nous ferions différemment
Prendre la chaîne de publication dès le premier jour
Nous corrigions de vrais bugs avant de pouvoir produire une version par nos propres moyens. La signature, les certificats et les accès aux stores sont désormais la première chose que nous demandons dans une reprise, avant la liste de bugs : tant que ce point n’est pas réglé, les correctifs sont terminés et toujours pas livrés.
Chiffrer la lecture du code
Nous avons appris ce code sur le temps du développement. Lire correctement le produit d’un autre prend des jours : c’est aujourd’hui un travail distinct et payant, qui a lieu avant le devis — et le montant qui en sort repose sur ce qui est réellement là.
Démarrer un produit, ou en reprendre un
Les deux sont normaux ici. Un nouveau développement est cadré et chiffré avant la première ligne de code. Une reprise commence par l’audit de code payant ; le devis du développement vient ensuite.
Un seul formulaire court, réponse sous un jour ouvré. Si nous ne sommes pas le bon studio pour ce projet, nous le disons.