Caroline B.
Cheffe de marques
Reprise de code sans documentation
Votre application est en service, et plus personne chez vous ne sait expliquer comment elle fonctionne. Une reprise de code sans documentation commence par reconstituer cette explication, à partir du code, de votre base, de vos utilisateurs et de ce que l'application déclenche sans intervention.
15 ans
d'expérience
250+
missions réalisées
+30
projets en activité
100%
sur-mesure
Ils nous font confiance
LE CONSTAT
Votre code tourne, et les personnes qui savaient le lire ont quitté l'entreprise
Votre outil fonctionne tous les jours. Vos équipes savent dans quel écran saisir un dossier et quel bouton produit quel document. Leur connaissance s’arrête là.
Ce qui manque tient en un mot : la raison. Pourquoi ce seuil vaut cette valeur, pourquoi une catégorie de dossier suit un autre chemin, pourquoi une case cochée ici change un montant trois écrans plus loin. Le développeur qui a écrit ces règles les tenait de vos collaborateurs les plus anciens, et personne ne les a jamais consignées.
Le premier effet se lit sur vos devis. Une évolution de quelques heures à vos yeux revient chiffrée avec du temps d’exploration devant, ce que les développeurs appellent une dette technique : un coût qui ne disparaît jamais tant que personne ne consigne ce qui a été compris. Vous payez la lecture avant la modification, et vous la repayez au changement d’intervenant suivant.
Le deuxième effet se voit à chaque incident. L’intervenant du moment cherche dans un code qu’il découvre, et la durée de l’arrêt dépend de sa vitesse de lecture bien plus que de la panne elle-même.
Le troisième bloque vos projets. Un de vos services demande une évolution, et rien ne vous dit si elle touche autre chose dans l’outil. La demande attend, puis vous y renoncez.
Le quatrième se voit le moins et pèse sur toutes vos négociations. Le prestataire qui connaît le code est seul à savoir ce que coûte une modification, et vous acceptez son chiffre sans point de comparaison.
Le manque est le même dans les quatre cas, et le traiter au coup par coup laisse les trois autres intacts. Retrouver la description de l’outil vient donc avant la décision, quelle que soit celle que vous prendrez ensuite, comme au départ de toute reprise de projet existant.
Vous vous reconnaissez ?
Quand une reprise de code sans documentation devient urgente
Vos équipes vous signalent ces six situations avant tout examen technique.
Vous avez reçu une archive de code et rien d'autre
Le code vous est arrivé entier, et l'adresse du serveur, le détenteur du nom de domaine et les comptes extérieurs manquent tous.
Un traitement automatique s'est arrêté sans que personne le voie
Les envois partaient seuls depuis des années. Un destinataire finit par réclamer ce qu'il attendait.
Un calcul sort un résultat que plus personne ne sait justifier
Le montant paraît faux, votre équipe le corrige à la main, et la règle qui l'a produit reste introuvable.
Chaque intervenant vous refacture le temps de comprendre
Le devis porte sa ligne d'analyse préalable, et le suivant vous la refacturera entière.
Vos utilisateurs ont inventé des contournements que rien ne valide
Ils saisissent une référence dans un champ prévu pour autre chose, et l'application accepte cette saisie depuis longtemps.
Le prestataire qui vous chiffre découvre l'outil pendant la réunion
Les questions restent sans réponse, et il se couvre par une marge que vous payez.
Ces six situations ont un point commun : l’urgence ne se voit pas de l’extérieur. Rien ne force la décision, et le coût s’accumule sans déclencher d’alerte, une exploration chiffrée ici, un incident traité sans repères là. La situation se durcit quand l’auteur du code reste injoignable, ce que nous traitons à part dans mon prestataire a disparu, que faire.
NOS SERVICES
Sept points à relever sur un code livré sans documentation
Nous commençons par un relevé. Voici les sept points sur lesquels nous travaillons, retenus selon ce que vous comptez faire de l'outil. La part strictement technique de ce travail fait l'objet d'un audit de code avant reprise de projet.
Inventaire des accès et des comptes
Serveur, nom de domaine, services extérieurs, abonnements : nous établissons qui détient quoi, et à quel nom. Ces accès restent réservés à l'équipe affectée à votre mission, sous engagement de confidentialité, et toute faille ou donnée sensible repérée pendant le relevé vous est signalée sans attendre la fin de la mission.
Parcours suivis par vos équipes
Nous suivons vos utilisateurs écran par écran et nous notons l'écart entre ce que l'outil prévoyait et ce qu'ils font.
Règles de calcul remises par écrit
Seuils, remises, prorata, arrondis : nous les sortons du code et vos responsables les relisent.
Traitements déclenchés sans intervention
Nous recensons les envois, les relances, les exports et les suppressions programmées, avec leur horaire et leur destinataire.
Échanges avec vos autres outils
Ce que votre application envoie et reçoit, vers quel partenaire, et sa réaction quand le correspondant répond mal.
Résultats attendus fixés par écrit
Nous écrivons ce que vos cas réels doivent produire, avant de modifier quoi que ce soit.
Document de reprise remis à votre entreprise
Un dossier lisible par une équipe extérieure, qui reste valable après un changement d'intervenant.
Nos dernières réalisations
Toutes nos réalisations 4,8
CE QU'ILS EN DISENT
Nous avons aidé des dizaines de clients dans leur transformation digitale
-
Equipe très à l'écoute, dynamique, réactive, de très bons conseils, très pro, à la fois très techniques mais qui sait aussi se mettre à la place de personnes non averties.
-
Laurence V.
Directrice Marketing
Nous ne pouvons que nous féliciter de notre choix d'agence web : une équipe sympathique, à l'écoute, professionnelle, rigoureuse, technique... présente tout en respectant nos contraintes.
-
Mirela O.
Reponsable Marketing
À l'écoute, disponibles et très créatifs, ils comprennent rapidement les besoins de leurs clients et leurs conseils sont opportuns.
-
Tiffany V.
Responsable Communication
Bonne compréhension des enjeux et attentes, couplée à de la créativité : tout est fluide. J'apprécie leur accompagnement, leur prise en charge et la disponibilité des équipes.
Par où commence la reprise de votre outil ?
Décrivez-nous votre application en quelques lignes, ce qu’elle produit et ce que vous en détenez aujourd’hui.
Cinq étapes pour reprendre un code non documenté
-
Nous lisons le code, nous regardons ce que contient votre base, et nous interrogeons vos utilisateurs, un travail de rétro-ingénierie qui reconstitue les règles à partir de ce qui existe plutôt que d'une spécification écrite. Quand ces sources se contredisent, les écarts vous reviennent pour arbitrage. Vous recevez la description de l'outil, la liste des accès manquants et notre avis sur ce qui mérite d'être gardé.
-
Nous redessinons les parcours retrouvés, en montrant ce que vos équipes font vraiment. Vous validez règle par règle. Ce prototype devient la référence commune le jour où le code et le souvenir de vos collaborateurs se contredisent.
-
Chaque règle retrouvée s'écrit avec sa raison d'être, pas seulement son comportement : pourquoi ce seuil, pourquoi cette exception. Ce document devient la référence que ni le code ni la mémoire de vos équipes ne portaient jusque-là, et la base sur laquelle discuter une évolution future.
-
La première évolution part de résultats écrits à l'avance, un test de non-régression qui rejoue chaque cas connu avant et après le changement. Nous modifions, puis nous comparons au résultat attendu. Nous complétons le document de reprise à chaque zone touchée, au rythme du travail.
-
Quand vous nous confiez la maintenance, ce suivi s'ouvre sous un contrat de maintenance et d'évolution distinct de la mission de reprise, et nous complétons le document à chaque intervention menée dans ce cadre. Vos évolutions se chiffrent alors sur un périmètre décrit. Le jour où vous confiez l'outil à une autre équipe, elle démarre sur ce qui est écrit.
Reprendre un code non documenté : ce que vous pouvez décider et quand
La réponse dépend de la taille de l’outil et des accès qui vous restent, et elle arrive après une première lecture. Nous procédons en deux temps. Un premier passage situe l’application : son ampleur, son état, ce qui manque pour l’exploiter, et se compte en jours à quelques semaines selon la taille de l’outil, jamais en mois. Le chiffrage vient une fois les accès récupérés, sur le périmètre que vous retenez.
.La lecture demande le code. L’exploitation demande en plus l’endroit où l’application tourne, le nom de domaine, la base et ses sauvegardes, les comptes des services extérieurs qu’elle appelle, les certificats. Nous établissons cette liste au démarrage, avec le détenteur présumé de chaque élément, et nous vous aidons dans les démarches de récupération. Ces démarches aboutissent avant le chiffrage : estimer une reprise sur un outil que nous ne pouvons pas encore faire tourner reviendrait à vous vendre une supposition. Chaque accès recensé reste consigné à votre nom pendant toute la mission, et nous vous le restituons intégralement à la fin.
.Le périmètre dépend de ce que vous comptez faire. Une évolution isolée sur un écran demande de comprendre cet écran, ce qui l’alimente et ce qu’il déclenche derrière. Reprendre la maintenance complète demande en plus l’inventaire des traitements automatiques et des échanges extérieurs. Nous partons du plus petit périmètre utile et nous l’élargissons quand vos demandes le justifient.
.Elles continuent comme d’habitude. Le relevé avance par lecture et par entretien, sans modification de l’outil en service. Nous leur demandons du temps par tranches courtes, pour nous montrer leurs manipulations réelles. La seule contrainte porte sur les modifications faites par une autre équipe pendant cette période : nous demandons à en être prévenus.
.Un relevé en cours rend cette panne moins coûteuse. L’inventaire des accès et la liste des traitements automatiques passent en tête du travail justement parce qu’ils forment le minimum nécessaire à un dépannage. Nous mettons le relevé de côté le temps de traiter l’incident avec vous, puis nous le reprenons avec ce que cet incident a montré.
.Réécrire sans avoir lu revient à redemander à vos équipes de réinventer des règles que le code contient déjà, et elles n’en connaissent qu’une partie. Le relevé sert dans les deux cas de figure : vous en tirez le cahier des charges d’une réécriture aussi bien que le plan de travail d’une reprise. Vous tranchez après, avec les deux chiffrages devant vous.
.Nous vous demandons ce contrat dès le premier échange, pour repérer avec vous s’il réserve les interventions futures à son signataire. Cette vérification se fait avant le relevé, pour engager le travail en connaissance de cause plutôt que découvrir la contrainte en cours de route.
. POUR ALLER PLUS LOIN
Ce que vous récupérez en reprenant un code non documenté
Le code décrit votre activité mieux que vos écrits d’origine
Vos écrits d’origine décrivent une intention. Le cahier des charges dit ce que l’outil devait faire au moment de la commande, et chaque évolution livrée depuis s’en est écartée d’un cran. Le code, lui, produit vos documents et vos chiffres tous les jours. C’est la description la plus à jour de votre activité, y compris quand son résultat vous surprend.
Notre premier travail consiste donc à le traduire en français. Nous soumettons chaque phrase à la personne de chez vous qui connaît le métier, et nous notons chaque endroit où elle nous arrête pour dire que le résultat devrait être autre. Ces endroits deviennent vos premiers chantiers.
La raison de chaque règle est restée chez vos utilisateurs
Une remise se déclenche à partir d’un certain montant, et le code s’en tient à ce montant sans dire qui l’a fixé ni contre quel concurrent : cette raison-là, il ne l’a jamais consignée.
Vos utilisateurs détiennent cette part-là : ils savent quel client est traité à part, quelle case attend l’accord d’un responsable, quelle manipulation contourne un écran cassé depuis des années. Nous recueillons ce savoir en entretien, chez les personnes qui se servent de l’outil tous les jours. Nous écoutons aussi ce qui ressemble à une bizarrerie : un contournement installé de longue date vaut la peine d’être instruit, il porte parfois un besoin que l’outil n’a jamais couvert.
Ce que votre outil envoie dehors sans que personne le décide
La partie visible d’une application tient dans ses écrans. La partie qui engage votre responsabilité tient dans ce qu’elle transmet à des tiers : un export nocturne chez un partenaire, une relance sur facture impayée, un rapport adressé à un client, des données confiées à un service extérieur. Ces envois ont été mis en place à une date, pour une raison, par quelqu’un qui a quitté le projet.
Votre client vous interroge sur le sort de ses données, votre assureur veut la liste de ce qui sort de chez vous, et la réponse tient dans ce relevé. Un envoi qui part encore vers un partenaire perdu de vue se coupe une fois qu’il est identifié.
Ce que vous cessez de repayer une fois l’outil décrit
Ce chiffrage sans référence se retourne une fois l’outil décrit : vous transmettez la description à d’autres sociétés, qui chiffrent alors sur un périmètre écrit au lieu de le deviner.
Ce document sert aussi à l’intérieur. Un nouveau collaborateur a de quoi apprendre l’outil sans mobiliser un ancien à temps plein, et votre direction sait ce qui tourne sous son nom. C’est le premier bénéfice à attendre d’une reprise de projet web, avant même la première évolution livrée.
La connaissance de votre outil vous appartient aussi
Le document que nous écrivons pendant la reprise reste chez vous. Nous le rédigeons pour qu’une équipe extérieure puisse le lire, et nous le complétons à chaque intervention que vous nous confiez. Le code et les données suivent la même règle : ils vous appartiennent intégralement, sans clause de reprise ni redevance.
Cette description vous appartient comme le reste, et c’est elle qui vous met en position de décider : la garder, la transmettre, ou vous en servir pour comparer un chiffrage à un autre.
