Mis à jour le 7 min de lecture
Sébastien Nobour
Fondateur de DEVEDANOS
Votre application est en service, et ses utilisateurs s’en servent chaque jour. Le prestataire qui l’a développée ne répond plus, ou ne la fait plus évoluer au rythme de votre activité. Parfois, le projet a pris du retard et la date annoncée est passée.
Un nouveau prestataire peut repartir du code existant. Une application en service contient des règles métier : des calculs, des cas particuliers. Souvent, elles ne sont écrites nulle part ailleurs que dans le code. Il le reprend, le comprend, puis le fait évoluer sans casser ce qui fonctionne.
Reprendre une application, c’est continuer à la faire évoluer à partir du code existant, avec une autre équipe. Cela concerne les applications dont le développement s’est arrêté avant leur mise en ligne, et celles qui sont en service mais devenues difficiles à faire évoluer.
Le nouveau prestataire reprend trois choses : le code source, les accès qui permettent de le mettre en ligne, et ce que l’on sait de l’application. La troisième est souvent la plus fragile. Avec un seul développeur, ce qu’il sait du logiciel part avec lui s’il ne l’a pas documenté, d’où l’intérêt de faire écrire cette connaissance au fil du travail.
Une application qui répond à votre besoin et qui évolue sans difficulté n’a rien à reprendre.
Avant de prévenir votre prestataire actuel, faites la liste de ce qui doit vous revenir. Une reprise commence par là : rassembler ce qui doit être à votre nom, c’est-à-dire le code source, l’hébergement, le nom de domaine, et les comptes des services tiers que l’application utilise (paiement en ligne, envoi d’e-mails, cartographie).
Si ces comptes sont au nom du prestataire, c’est lui qui en détient l’accès. Demandez leur transfert au nom de votre entreprise, et ouvrez à son nom les comptes qui n’existent pas encore.
Demandez aussi la documentation, s’il en existe : comment installer l’application, comment la mettre en ligne, quels tests vérifient qu’elle fonctionne.
Avoir une copie du code ne suffit pas pour le faire évoluer avec un autre prestataire : il faut en avoir le droit. Payer les factures ne vous rend pas propriétaire du code. C’est le contrat qui vous le cède, par une cession écrite des droits qui nomme chaque droit cédé.
Relisez donc votre contrat avant d’annoncer votre départ. Si une partie du code reste la propriété du prestataire, vérifiez que la licence qu’il vous accorde vous permet de la confier à quelqu’un d’autre. En cas de doute, faites relire la clause par un avocat.
La clause de réversibilité organise votre départ : la récupération des données, l’accès aux configurations, la remise de la documentation, le délai de préavis. Si votre contrat en contient une, c’est le moment de l’appliquer. S’il n’en contient pas, tout dépend de ce que votre prestataire acceptera de vous remettre.
Pour le contrat que vous signerez avec le suivant, prévoyez ce départ dès le premier jour, et faites un essai de reprise une fois, avant d’en avoir besoin.
Une fois les accès rassemblés, l’application est déployée sur un environnement de recette, une copie de l’application où chaque modification se vérifie avant sa mise en ligne. Le nouveau prestataire l’administre, et il reproduit la production. Il y lit le code, et vérifie qu’il sait le construire et le mettre en ligne sans l’aide de l’équipe précédente.
Michael Feathers est l’auteur de Working Effectively with Legacy Code (Travailler efficacement avec du code hérité), paru en 2004, le livre de référence des développeurs qui reprennent du code existant. Il y définit le code hérité, celui que l’on reçoit d’une équipe précédente, simplement comme du code sans tests.
Sans tests, rien ne permet de vérifier rapidement qu’une modification n’a rien cassé ailleurs. Les modifications se font alors à petits pas, avec prudence. Les évolutions ralentissent.
Avant toute modification, des tests automatisés décrivent ce que fait l’application aujourd’hui, sur les parcours dont dépendent ses utilisateurs. Ensuite seulement, on la modifie. Chaque modification passe par un pipeline de déploiement qui rejoue ces tests avant d’atteindre l’environnement de recette.
Face à un code difficile à faire évoluer, la tentation est de tout refaire. Réécrire l’application d’un bloc oblige pourtant à retrouver chacune de ses règles métier, une par une. Pendant ce temps, l’application en service n’évolue plus. La nouvelle version n’apporte rien à ses utilisateurs tant qu’elle n’est pas terminée.
La refonte peut se faire autrement : par parties. Une partie se remplace quand elle bloque les évolutions dont vous avez besoin, pas parce qu’elle est ancienne. Le reste continue de servir pendant ce temps. Et chaque modification part en production séparément, après sa recette : une petite modification est moins risquée qu’une nouvelle version livrée d’un coup.
Migrer une application fait partie de cette refonte : faire passer son code vers une version plus récente de son framework, vers une autre technologie ou vers un autre langage, sans changer ce qu’elle fait pour ses utilisateurs.
Chez DEVEDANOS, nous commençons par rassembler les accès et par déployer l’application sur un environnement de recette. Nous écrivons ensuite les tests des parcours dont dépendent ses utilisateurs, avant toute modification. S’il existe de la documentation, nous la lisons.
Nous remplaçons une partie quand elle bloque les évolutions dont vous avez besoin, et nous gardons ce qui fonctionne. La décision se prend avec vous, après lecture du code.
Pour un projet en retard, nous reprenons avec vous la liste des fonctionnalités prévues et la classons selon leur valeur pour les utilisateurs de votre application. Celles qui comptent le plus sont conçues, développées puis mises en production les premières, une par une, chacune après sa recette.
Pour un constructeur de véhicules de loisirs, nous sommes intervenus sur le développement de sa marketplace. Le projet avait pris du retard avec un autre prestataire. Avec le client et ce prestataire, nous avons recentré le développement sur les fonctionnalités essentielles, celles qui apportaient le plus de valeur. La nouvelle échéance a été tenue avec une application minimale ; les autres fonctionnalités ont ensuite été ajoutées en continu.
Une fois l’application reprise, il reste à la maintenir. Nous proposons la tierce maintenance applicative (TMA) dans le même modèle. La maintenance corrective (correction de bugs), adaptative (mises à jour de dépendances, correctifs de sécurité, compatibilité navigateur), préventive (refactoring, optimisation de performance) et évolutive (nouvelles fonctionnalités) sont incluses.
Chez DEVEDANOS, la même équipe développe, teste, déploie et maintient votre logiciel en continu, dans le même pipeline.
Nous reprenons d’abord les applications en JavaScript et TypeScript (React, React Native, Next.js, Node.js). Pour une autre technologie (PHP, Java, Python…), les bases de l’ingénierie logicielle valent quel que soit le langage : il suffit d’en discuter dès le premier appel.
Chez DEVEDANOS, nous développons votre logiciel sur mesure, utilisable en un mois, pour un budget mensuel fixe, et l’ajustons en continu à l’évolution de votre activité. Le budget se construit avec vous, à partir de vos chiffres et de vos objectifs : nous fixons ensemble le montant et le problème que votre application doit résoudre.
Ce qui a été recetté part en production. Chaque jour, vous voyez l’application avancer sur votre environnement de recette.
Et pour que ce qui fonctionnait avant la reprise fonctionne encore après, nous appliquons une garantie zéro régression : chaque régression est corrigée et couverte par un test automatisé, pour qu’elle ne revienne pas, et sans surcoût.
Le code source, l’infrastructure, le pipeline de déploiement et la documentation sont votre propriété intellectuelle dès le règlement de la première mensualité. Période d’essai jusqu’à 15 jours ouvrés sur le premier mois : aucune facture si vous ne voulez pas des livrables.
Vous pouvez mettre fin au contrat par écrit à tout moment, sans justification. Pendant le mois de réversibilité, nous accompagnons votre équipe jusqu’à ce qu’elle puisse construire, tester et déployer sans nous.
Notre page sur la reprise et la refonte d’application détaille ce que nous faisons sur une application existante.
Vous choisissez le prestataire qui reprendra votre application ? Notre article sur le partenaire technique d’une PME distingue les quatre formes de prestataire informatique et les questions à leur poser. Et si votre besoin change en cours de route, qui paie ce changement dépend du contrat : forfait à périmètre fixe, régie, ou budget fixe.
Votre prestataire ne répond plus, ou votre application n’avance plus ? On en parle ?
Comment intégrer l'IA dans son entreprise : partir d'une tâche précise, savoir quand une règle suffit, choisir entre un outil d'automatisation et un logiciel sur mesure, et connaître les risques.
Fichier Excel partagé entre plusieurs utilisateurs, erreurs, versions qui se croisent : quand le tableur est devenu une application, et ce que change le passage à une application web métier.
Trouver un associé technique pour sa startup : ce qu'apporte un cofondateur technique, ce que vous cédez, comment le choisir et ce qu'il faut écrire dans le pacte d'associés.