François, développeur chez Oniti, connaît bien la reprise de logiciel, un des piliers fondateurs de l’agence. Pour Julien, la reprise est un challenge technique presque toujours possible à relever.
Chez Oniti, on dit « oui » à la reprise et « oui » à la refonte : C’est le contexte client qui en décide, nous nous adaptons.
Reprise ou refonte d’application ?
Julien :
Le cas le plus fréquent est celui de clients dont le prestataire arrête son activité. Ils se retrouvent avec une application dont l’hébergement et la maintenance sont amenés à disparaître très rapidement, souvent dans le mois qui suit. Il faut donc être capable de réagir vite. Dans ces cas-là, la reprise est la seule solution viable.
François :
Ces clients viennent nous voir dans un contexte d’urgence. Dans un premier temps, on reprend l’application existante avec l’hébergement, telle qu’elle est. Pour répondre au besoin client immédiat. Ensuite, si de gros besoins d’évolutions sont nécessaires et engendrent trop de modifications sur le code historique, on peut recommander une refonte.
Julien :
Ce n’est pas commun les structures qui reprennent des applications. La règle, c’est plutôt la refonte. En général, les prestataires refusent les demandes de reprise d’application. Le code ayant été écrit par un autre développeur, cela prendrait trop de temps de se l’approprier. Et la plupart du temps, ces prestataires recommandent une refonte.
Tout savoir sur la reprise logicielle ici
D’où vient le problème ?
Julien :
Une grande partie des sujets de reprise proviennent d’applications qui ont été développées par des développeurs qui n’avaient pas besoin d’utiliser des standards, car travaillant seuls. Les développeurs indépendants permettent au client de trouver une solution peu chère. A l’inverse, ils présentent un risque plus grand de disparaître.
François :
Le premier projet de l’agence, c’était une reprise. La PFS, la Plateforme Service d’Atlantic, fournisseur de pièces détachées sur internet. A la demande de ce client, Oniti s’est développé et c’est dans ce contexte que j’ai été recruté pour rejoindre David, le fondateur d’Oniti.
Julien :
De plus, Oniti a une équipe de développeurs expérimentés avec une culture informatique forte permettant de faire ces reprises. En effet, aujourd’hui, les jeunes développeurs sont formés sur les technologies les plus récentes pour être immédiatement opérationnels sur les projets. Ils n’ont pas forcément la culture de logiciels plus anciens.
La reprise d’application, c’est l’histoire d’Oniti.
Julien :
Ils ont besoin de ce logiciel pour travailler et celui-ci risque de disparaître à n’importe quel moment. Il n’est pas rare qu’ils soient paniqués.
François :
Les cas de figure avec les anciens prestataires sont très différents. Entre ceux qui n’ont pas donné le code source et ceux qui restent disponibles pour faire le suivi. On a tout le spectre des situations avec nos clients.
Julien :
L’exemple du Crefi est intéressant. Ils avaient toujours eu une relation compliquée avec leur développeur et avaient l’impression que c’était le propre du développement. Un jour, le prestataire a mis la clé sous la porte de manière brutale. Ils nous ont trouvé en tapant « reprise d’application » sur Internet. On a dû les rassurer, reprendre l’hébergement de leur application, corriger les bugs. J’ai vraiment apprécié le changement de rapport que nous avons eu à partir de ce moment-là.
Oniti, un prestataire hybride
François :
Les prestataires qui reprennent sont plutôt rares. Oniti est un peu hybride entre l’indépendant, qui n’a pas une connaissance technique assez large pour faire de la reprise et les SSII qui sont trop grosses pour être intéressées par ces sujets.
Julien :
Sur nos développements, on s’efforce d’écrire un code clair et d’utiliser des standards pouvant être repris par un autre prestataire, le cas échéant.
François :
Pour les projets développés en interne sur lesquels nous partageons la même plateforme technique, on choisit des technologies sur lesquelles il existe une communauté importante de personnes qui l’utilisent.
Les clients qui sont dans cette situation, sont stressés
La question des coûts
Julien :
Reprendre un existant peut être plus économique à court terme contrairement au développement complet d’une application, qui peut prendre plusieurs jours, semaines, mois. Cependant, la correction d’un bug ou l’ajout de fonctionnalité sur une reprise est forcément plus longue que sur une application que l’on aura écrite nous-même. C’est souvent la vision du client quant à l’investissement dans ses outils qui arbitre entre ces deux orientations.
Alors reprise ou refonte ?
Julien :
La refonte n’est pas systématique. Des applications sont suffisamment bien écrites pour être maintenables dans le temps. On sait faire l’un et l’autre et proposer une migration de l’un vers l’autre.
François :
Pour toute application qui vit et qui est utilisé quotidiennement, se pose toujours la question de la refonte.
Julien :
L’enjeu entre les deux, c’est la maîtrise du code de l’application. Quand on fait une reprise, nous n’avons pas écrit le code, il y a donc beaucoup d’inconnues pour nous. Si le client souhaite ajouter un menu ou une fonctionnalité, nous ne sommes pas capables d’estimer des durées sans étudier précisément le code. A l’inverse, sur du code que l’on a écrit en interne, nous avons une bien meilleure visibilité et nous pouvons donner au client des réponses fiables immédiatement.
Du point de vue du client, la reprise est plutôt une bonne affaire. Cela permet d’avoir une transition en douceur, de retrouver une relation sereine avec le prestataire, de ne pas payer un bras pour ça, de prendre le temps d’analyser la suite et de se retourner. C’est plutôt pour nous que c’est complexe de devoir reprendre du code dont on ne sait pas comment il a été écrit…
