Le développement de votre application mobile ou de votre plateforme web ne s’arrête pas à la mise en ligne. En effet, il faut continuer à faire vivre le produit, le stabiliser, l’adapter en fonction de sa croissance et régler d’éventuels problèmes. Bref, les raisons d’intervenir sont multiples et la rigueur, l’anticipation et la continuité sont à l’ordre du jour !
Mais que faire lorsque le prestataire initial n’est plus en mesure d’assurer le suivi ? Une reprise de prestation de développement est inévitable et c’est là que Le Backyard entre en jeu. Habitués à accompagner des entreprises dans cette transition délicate, nous vous donnons les clés pour assurer la continuité et la qualité du projet.
I. Compréhension de la stack technique
La stack technique, c’est l’ensemble des technologies qui sont utilisées pour concevoir, développer et faire fonctionner le projet web ou mobile, des frameworks aux bases de données, en passant par les services tiers. Bien la connaître est la base pour reprendre le code du projet.
1. Identifier les technologies utilisées
La première étape est d’identifier les technologies qui permettent au frontend (interface utilisateur) et au backend (API, base de données, services de paiement, etc.) de fonctionner.
En listant clairement tous les composants de la stack technique, le nouveau prestataire pourra vérifier s’il a les connaissances nécessaires pour travailler ces technologies-là et, par conséquent, évaluer si la reprise de prestation de développement est réaliste ou pas.
Encadré : L’importance de l’open-source
Dès la phase de conception, sélectionner des technologies open-source est essentiel puisqu’elles sont largement diffusées et documentées et, donc, maîtrisées par la plupart des prestataires. À l’inverse, les développements avec des technologies propriétaires poseront problème.
2. La phase de « go / no go »
La phase de go / no go est centrale et systématique pour une agence comme Le Backyard. Effectivement, nos experts évaluent la faisabilité technique avant de s’engager sur une reprise.
Pour cela, ils valident de nombreux points :
- Sommes-nous familiers avec la stack technique utilisée ?
- Le projet est-il suffisamment documenté ?
- Le socle technique sera-t-il encore pertinent à court et moyen terme ?
Bien entendu, la liste de questions incontournables n’est jamais figée et évolue avec le projet en question.
Si les réponses sont favorables, notre équipe passe à l’étape suivante. Dans le cas contraire, deux options s’imposent : une refonte partielle (frontend ou backend) ou une refonte complète si le client opte pour celle-ci.
II. Transmission des livrables
Une fois que le nouveau prestataire confirme qu’il est capable d’assumer une reprise du projet, le client doit lui transmettre les livrables qu’il a en sa possession.
1. La signature d’une déclaration de confidentialité
Avant tout transfert de code ou d’accès, Le Backyard rédige une déclaration de confidentialité se basant sur les informations obtenues jusqu’à maintenant. De plus, ce document protège les données sensibles que le client s’apprête à transmettre au nouveau prestataire.
2. La mise en accès du code
Pour que le nouveau prestataire ait accès au code, la transmission se fait via des plateformes comme GitHub, qui permettent de récupérer l’intégralité du code simplement et en toute sécurité.
Le client doit aussi apporter la documentation technique disponible, même si celle-ci est sommaire, ainsi qu’autoriser l’accès à la production et aux bases de données.
III. Phase d’audit technique
Pour être sûr que Le Backyard est en mesure de continuer le projet, nous réalisons un audit technique express et payant de 2-3 jours.
1. Vérifier les fondations du projet
Avant de se lancer dans un projet d’une telle envergure, il est nécessaire d’analyser en profondeur l’existant. C’est pour cela que Le Backyard démarre toute reprise par un court audit technique de votre application web ou mobile, qui permet d’évaluer les éléments suivants :
- les fondations du projet et sa structure ;
- la qualité du code ;
- le respect des bonnes pratiques ;
- les dépendances, les bibliothèques, les API externes, etc ;
- la documentation existante
Cette étude du produit existant permet également de détecter d’éventuelles erreurs ou problèmes.
Identifier les points critiques
Nos experts profitent donc de cet audit pour identifier les inconvénients et les diviser en deux catégories :
- les points critiques (bugs importants, mises à jour urgentes, erreurs majeures…) dont les actions correctrices doivent être mises en action le plus tôt possible ;
- les points non critiques (améliorations, nettoyage de code, mise à jour des dépendances…) qui s'incluent naturellement dans l’évolution du projet.
Cet audit technique est la base d’un plan d’action clair et priorisé.
IV. Plan d’action et estimation chiffrée
Grâce à l’estimation des points critiques et non critiques, il est possible d’établir un plan d’action complet de la reprise du projet, qui comprend notamment :
- les corrections urgentes du code à réaliser le plus tôt possible ;
- la mise en ligne du nouveau code.
Mais le travail ne s’arrête pas là, le plan d’action prend aussi en compte les évolutions de ce nouveau code au fur à mesure que le projet grandit ou évolue. Il peut s’agir d’évolutions fonctionnelles, d’optimisation de la performance, de mise en conformité RGPD, etc, qui sont à inclure sur du moyen terme.
Ce plan d’action est bien entendu couplé avec une estimation chiffrée de chaque étape. Ce travail est normalement mené en mode forfaitaire (si les objectifs sont clairs) ou en mode régie (avec un suivi au fur à mesure via des tickets correctifs).
Pour conclure, la reprise suite à une prestation de développement est une opération aussi importante que délicate, qui doit être structurée et rigoureuse. Cela garantit la pérennité du produit sans devoir repartir de zéro, ce qui peut coûter très cher au client.
Le Backyard a assuré la reprise de nombreux projets au cours de ces dernières années dans des secteurs très variés. Si vous souhaitez nous confier votre projet, vous êtes entre de bonnes mains. Contactez-nous ici !
.jpg)
.jpg)
