Vous avez un site ou un logiciel qui n’évolue plus ? Votre agence ou ESN actuelle ne vous donne pas satisfaction ? Vous avez un outil digital développé en interne ou avec un freelance, et vous avez besoin d’une équipe pour le faire évoluer ?
Alors vous avez besoin de mettre en place un contrat de TMA (Tierce Maintenance Applicative). L’objectif, c’est que vous puissiez à terme dormir sur vos deux oreilles, avec une équipe qui puisse intervenir rapidement en cas de problème sur votre site application, corriger les bugs, mettre en place les évolutions nécessaires, et qui s’assure que les performances et la sécurité soient au rendez-vous.
Mais avant d’en arriver là, il faut passer par quelques étapes cruciales pour que la reprise de votre projet soient une réussite. Dans cet article, on détaille les 10 étapes clés pour la mise en place d’un contrat de TMA.
Sommaire
- 1- Récupération de l’ensemble des accès à la plateforme
- 2- Audit de la plateforme et de la documentation
- 3- Mise en place de l’environnement de développement et récupération de l’environnement de production
- 4- Initialisation de la TMA
- 5- Transfert de responsabilité avec l’ancien prestataire
- 6- Implémentation des nouveaux standards de qualité
- 7- Co-construction de la nouvelle roadmap
- 8- Spécifications fonctionnelles et mise à jour des maquettes
- 9- Estimation des évolutions
- 10- Planification des sprints de développement
- Conclusion
1- Récupération de l’ensemble des accès à la plateforme
Première étape : transmettre à la nouvelle équipe tous les accès à votre plateforme :
- accès au code (Github, Gitlab…) ;
- accès aux environnement de travail (recette, pre-production, production) ;
- mots de passe ;
- comptes de test ;
- back-office ;
- hébergement ;
- outils tiers (gestionnaire d’email, gestionnaire de paiement, analytics) ;
- …
Il ne faut rien oublier !
La passation du projet est un moment crucial et pour cela, il est nécessaire que l’équipe qui était auparavant en charge du projet puisse communiquer avec la nouvelle équipe en charge de la maintenance. Aucune tâche ne pourra démarrer tant que les accès ne seront pas transmis – de façon sécurisée, bien sûr.
💡 Chez theTribe nous ne transmettons jamais les mots de passe par email, et nous ne les stockons pas en clair dans des documents internes. Nous conservons les accès aux plateformes de nos clients et les partageons en interne via Passbolt, une solution de gestion des mots de passe sécurisée et open source.
2- Audit de la plateforme et de la documentation
Une fois que les accès ont été transmis, l’équipe qui va reprendre votre projet va pouvoir enclencher une phase d’audit. L’objectif de cette phase est de vous donner un aperçu de la qualité de votre base de code, au moment de la passation, d’identifier les risques potentiels à court terme, et préparer le cadrage de l’intervention.
L’audit concerne différents aspects du projet.
Le plus gros morceau est l’audit technique, qui comprend plusieurs points de contrôle :
- Audit du code : standards de développements, pipeline d’intégration continue et de déploiement automatisé, qualité du code ;
- Audit de l’environnement de développement et de l’architecture : infrastructure technique, architecture logicielle, monitoring…
- Audit des technos utilisées : pertinence des technos utilisées, versions en place, identification des besoins de mises à jour/montée en version…
Un audit fonctionnel doit également être mené, afin que l’équipe qui va reprendre le projet prenne en main le produit, identifie le périmètre fonctionnel, les fonctionnalités critiques… Pour cette étape, on recommande une interview de quelques utilisateurs.
Enfin, l’audit de la documentation projet est un sujet en tant que tel. En effet, si cette documentation est incomplète, il est capital de l’identifier et d’y remédier.
Ainsi, les 3 livrables de cette étapes sont :
- l’audit technique
- l’audit fonctionnel
- inventaire des éléments manquant dans la documentation
À ce stade, l’équipe en charge de la TMA va pouvoir fournir une liste de recommandations techniques priorisées selon leur criticité.
3- Mise en place de l’environnement de développement et récupération de l’environnement de production
Une fois la phase d’audit passée, la nouvelle équipe doit encore vérifier qu’elle est bien en mesure de reprendre les développements et déployer des modifications du projet en production. À cette étape, elle a encore besoin de pouvoir solliciter l’ancien prestataire (le cas échéant).
Si un environnement de déploiement automatisé ou des tests automatisés étaient déjà en place, on va vérifier qu’on arrive à les faire fonctionner.
Sinon, on vérifie à minima que l’on arrive à démarrer le projet sans erreur pour être en mesure d’assurer la maintenance, et de recopier les développements sur l’environnement de production. L’environnement qualité cible sera mis en place à une étape ultérieure, une fois le transfert de responsabilité effectué.
À l’issue de cette étape, on va fournir une documentation d’installation mise à jour.
Si le nouveau prestataire se charge aussi de l’hébergement et de l’infogérance de la plateforme, il va également falloir prévoir une migration vers le nouvel environnement de production, en minimisant l’impact opérationnel et sans rupture de service. Chez theTribe, c’est ce que nous avons fait lorsque nous avons repris la maintenance du site advenir.mobi, une plateforme publique de distribution de primes à l’installation de bornes de recharge électriques.
4- Initialisation de la TMA
Une fois l’audit finalisé, en même temps que l’équipe technique va mettre en place l’environnement de développement et de déploiement, le nouveau prestataire va pouvoir initialiser la TMA en coordination avec l’équipe projet côté client.
Il s’agit tout d’abord de définir et valider conjointement l’organisation concrète de la maintenance corrective :
- définition des typologies d’anomalies (critique, bloquante, majeure, mineure) et de leur traitement (priorisation, délais de prise en charge…) ;
- workflow de déclaration, de validation et de prise en charge des anomalies ;
- mise en place du bugtracker (chez theTribe, nous utilisons Jira), implémentation du workflow et création du tableau de bord de suivi
5- Transfert de responsabilité avec l’ancien prestataire
À l’issue de cette phase d’initialisation, le transfert de responsabilité peut être acté et formalisé sous la forme d’un courrier afin de décharger l’ancien prestataire de toute responsabilité.
Votre ancien prestataire, le cas échéant, n’interviendra plus sur votre plateforme et son contrat prend fin. Le nouveau prestataire est désormais en responsabilité. Il va pouvoir commencer à implémenter les changements techniques prioritaires recommandés en phase d’audit, et prendre en charge la maintenance corrective.
💡 En cas de difficulté, on pourra tout de même avoir besoin de communiquer avec l’ancien prestataire.
6- Implémentation des nouveaux standards de qualité
En général, une des premières tâches prises en charge par l’équipe TMA en début de projet est la mise à jour des librairies et frameworks utilisés par votre projet. Ces besoins ont été identifiés en phase d’audit technique. C’est indispensable pour pouvoir travailler sur des bases solides en termes de sécurité et de performances.
Parfois, ces mises à jour vont entraîner des effets de bord et nécessiter des adaptations du code. La phase d’audit aura permis d’identifier ces risques et donc, d’être proactif et d’éviter la création de bugs.
On va également pouvoir mettre en place l’infrastructure cible qui nous permettra d’assurer la TMA dans les meilleures conditions (performance, réactivité, évolutivité).
Chez theTribe, pour chaque projet, nous nous assurons de mettre en place a minima les process suivants si ils n’étaient pas déjà implémentés :
- Présence d’une image Docker pour faciliter les déploiements ainsi que la mise en place de l’environnement de développement
- Mise en place d’un outil d’intégration continue (tests automatisés, règles de code…) : Circle CI, Gitlab CI…
- Mise en place d’un outil de déploiement continu : Ansible, Jenkins…
- Mise en place du Gitlab flow (stratégie de branches, merge request workflow, peer review…)
À l’issue de cette étape, toutes les conditions sont réunies pour assurer la TMA et planifier les évolutions à venir : déploiement automatisé, environnement de production et de recette en place, etc.
7- Co-construction de la nouvelle roadmap
Une fois la maintenance opérationnelle, on va pouvoir planifier les évolutions. Il s’agit d’abord de définir les évolutions prioritaires à court terme, moyen terme et long terme.
Cette roadmap (feuille de route) est établie conjointement entre votre équipe et l’équipe du prestataire. Elle doit prendre en compte les évolutions demandées par client, mais également les évolutions nécessaires identifiées par l’équipe technique.
À cette étape, on va définir :
- La charge prévisionnelle allouée aux évolutions et à la maintenance : en fonction de la taille du projet, on sera entre 0,5j et 3j / semaine pour la maintenance, et entre 1 et 4 sprints (1 semaine) par trimestre pour les évolutions;
- Les périodes de l’année où des évolutions majeures seront programmées. Cela permet au client de s’organiser en interne pour planifier le déploiement de ces évolutions (recette, communication, etc).
8- Spécifications fonctionnelles et mise à jour des maquettes
Avant de les confier aux développeurs, on va maquetter graphiquement les évolutions fonctionnelles qui nécessitent de modifier l’interface utilisateur de votre produit. C’est nécessaire pour chiffrer les développements et pour valider les changements d’interface avec vos utilisateurs. On va donc confier à un UX/UI designer la création de ces maquettes dans Figma. On va également rédiger les spécifications fonctionnelles des évolutions à réaliser. Une fois validés, ces éléments vont permettre de chiffrer les développements.
9- Estimation des évolutions
Une fois la roadmap définie, l’équipe du prestataire va pouvoir chiffrer les évolutions planifiées. Elle va s’appuyer sur les maquettes validées, et sur des spécifications ou user stories.
En fonction des temps de développement estimé, on va parfois devoir revoir les priorités pour rester conforme au budget prévu au contrat.
💡 Chez theTribe, nous intégrons dans le cadre de la maintenance les évolutions estimées à moins de 2 jours. Si une évolution est estimée à plus de 2 jours de développement, elle sera incluse dans sprint d’évolution.
10- Planification des sprints de développement
Les évolutions étant estimées et priorisées, on peut désormais planifier les développements !
Chez theTribe, nous allons travailler en sprints courts (une semaine) et les évolutions sont validées au fur et à mesure des développement. Cette recette au fil de l’eau facilite l’adoption des changements par les utilisateurs, encourage l’amélioration continue, et permet de procéder à des ajustements si nécessaire.
Le produit évolue donc par petits lots conformément aux principes de l’agilité. Notre méthode se base sur Scrum et le Lean Startup, elle se veut orientée sur le résultat et les interactions humaines, notamment en mettant en avant la transparence, l’esprit critique, la prise de recul et l’adaptation.
On met en place des rituels quotidiens, hebdomadaires et mensuels afin de maintenir une communication fluide au sein de l’équipe projet.
Les évolutions sont livrées et testées au fil de l’eau sur l’environnement de recette, ce qui garantit un niveau de qualité final optimal. Avant la mise en production, on joue l’ensemble des scénarios de recette sur une copie des données de production.
Le déploiement en production est accompagné d’une mise à jour de la documentation projet et d’un PV de livraison.
Conclusion
Changer de prestataire ou externaliser des développements réalisés en interne, c’est un projet anxiogène pour beaucoup d’équipes, et c’est normal. Nous espérons que vous y voyez plus clair avec ces 10 étapes que chez theTribe, nous respectons chaque fois que nous reprenons les projets de nos clients. Si vous envisagez de changer de prestataire pour la TMA de votre produit, n’hésitez pas à nos contacter !
