Votre équipe n'a plus le temps de maintenir vos outils, ou votre développeur est parti
Vos outils tournent encore, mais plus personne ne les entretient.
Votre équipe est là, mais elle n'a plus le temps
C'est le cas le plus courant. Votre développeur, ou votre petite équipe technique, fait du bon travail. Mais tout son temps part dans les nouveaux projets et les demandes du quotidien : un export pour la comptabilité, un accès à créer, un bug à corriger avant midi.
Les outils déjà en place passent toujours après : l'outil de devis, l'application interne. Les mises à jour attendent le trimestre suivant, la remise en ordre du code n'est jamais planifiée, et une seule personne éteint les incendies.
Personne n'a mal travaillé. La dette technique, c'est cela : des mises à jour reportées et des raccourcis pris pour livrer à temps, qui s'accumulent jusqu'au jour où chaque changement devient risqué.
Ou votre développeur est parti
Autre cas : l'outil a été construit et tenu pendant des années par une seule personne, un développeur indépendant, un employé, parfois un proche. Puis cette personne est partie, et la passation a tenu en une après-midi, ou n'a jamais eu lieu.
L'outil tourne toujours, mais où est le code, comment il se met en ligne, quelle tâche tourne la nuit : rien de tout cela n'est écrit. Et plus personne n'ose y toucher.
Ce que cela vous coûte déjà
Tant que ça tourne, personne n'y pense. Mais la facture court déjà, en heures que personne ne compte.
-
La personne clé
Si la personne qui connaît votre outil part demain, ou tombe malade un jour de panne, qui le répare, et en combien de temps ?
-
Les projets interrompus
Combien de fois par semaine votre équipe lâche‑t‑elle un nouveau projet pour dépanner un ancien outil ?
-
Les demandes en attente
Combien de modifications attendent depuis des mois, faute de quelqu'un pour les faire ?
-
Les mises à jour reportées
À quand remonte la dernière mise à jour du serveur et des bibliothèques ? Pendant ce temps, de nouvelles failles continuent d'être publiées.
Faites le calcul : les heures de dépannage par semaine, fois 46 semaines, fois le coût horaire de votre équipe. Presque personne ne connaît ce chiffre. C'est le premier que nous mesurons.
Cette semaine, sécurisez
Que votre développeur soit débordé ou parti, ces points demandent quelques heures d'organisation, pas un projet.
- La liste de vos outils. Chaque outil maison dont votre activité dépend, qui le connaît le mieux, et les mises à jour que votre équipe repousse depuis des mois (langage, framework, serveur). Cette liste, c'est votre dette technique, par écrit.
- Deux personnes par accès. Application, serveur, base de données, services tiers : chaque accès administrateur doit être connu de deux personnes de l'entreprise, et rangé dans un gestionnaire de mots de passe partagé.
- Le code source. Dans un dépôt (GitLab, GitHub, Bitbucket) au nom de votre entreprise, dans la version qui tourne en production. Pas seulement sur un serveur ou un ordinateur portable.
- Ce qui n'est écrit nulle part. La mise en ligne, les tâches de nuit, les sauvegardes et la façon de les restaurer. Une heure pour l'écrire vaut mieux que des jours de recherche pendant une panne.
- L'hébergement et le nom de domaine. À quel nom sont les comptes, sur quelle carte sont‑ils payés, quand le domaine doit‑il être renouvelé ? Le titulaire doit être votre entreprise, pas un collaborateur ni un développeur.
- Si votre développeur est parti. Reprenez contact tant que la relation est bonne : demandez les accès, le code et une heure pour vos questions, en proposant de rémunérer ce temps. Fermez dès maintenant ses accès personnels ; les identifiants que l'application utilise elle-même se changent avec quelqu'un qui sait où ils sont configurés, sinon c'est la panne. Et relisez le contrat : à qui appartient le code ? En cas de doute, demandez à un juriste.
La liste complète, et pourquoi chaque point compte : reprendre une application que plus personne ne maintient.
Un renfort pour votre équipe, pas un remplaçant
Nous travaillons à côté de votre équipe, sur les outils qu'elle n'a plus le temps d'entretenir. Elle garde les nouveaux projets.
Nous prenons en charge vos outils existants : la maintenance, les mises à jour de sécurité et la remise en ordre du code (le refactoring), au forfait. Chaque correctif est livré avec sa documentation : le jour où votre équipe reprend un outil, elle le retrouve à jour et documenté. Nous lui demandons une courte passation, et nous la tenons au courant de ce que nous changeons.
Si votre développeur est parti, nous faisons le même travail sans lui, en commençant par récupérer les accès et le code. S'il est d'accord, nous l'associons volontiers à la passation : il sait des choses qu'aucun code ne dit.
Ce n'est probablement pas pour vous si votre équipe a le temps d'entretenir ses outils et de les faire évoluer.
D'abord, un regard extérieur
Votre équipe connaît l'outil de l'intérieur, mais n'a pas le temps de prendre du recul. Le bilan de santé vous donne ce regard extérieur en deux semaines : ce que l'outil vous coûte, ce qui va casser en premier, et par où commencer.
Ou est‑ce plutôt votre prestataire qui ne répond plus ?
Toutes les situations : reprise d'application existante.