Ce qui existe réellement
Comprendre l’outil réellement utilisé, les personnes concernées, le contexte, les accès disponibles et les dépendances importantes déjà identifiables.
01 — Votre situation
Reprendre ou faire évoluer un existant
Vous avez déjà un site, une application, un tableur ou un outil métier, mais il devient difficile à maintenir, à comprendre ou à faire évoluer.
Le fait qu’un outil ne réponde plus correctement à vos besoins ne signifie pas qu’il faille tout reconstruire.
Avant de proposer une solution, j’examine ce qui existe, ce qui fonctionne encore, ce qui pose problème et ce qui mérite réellement d’être changé.
Reconnaître la situation
Vous êtes peut-être dans cette situation si…
Ces signes servent à reconnaître ce qui mérite d’être examiné. Ils ne déterminent pas à eux seuls la solution à retenir.
- Votre site fonctionne encore mais ne correspond plus vraiment à votre activité.
- Une application est devenue difficile à modifier ou à maintenir.
- Un tableur essentiel devient fragile ou complexe.
- Vous devez faire évoluer un projet réalisé auparavant par un autre prestataire.
- Une modification qui paraît simple semble risquer d’en casser plusieurs autres.
- Vous ne savez plus clairement ce qui peut être conservé, corrigé ou remplacé.
Projet réalisé par un tiers
Un projet n’a pas besoin d’avoir été créé par moi pour pouvoir être examiné.
La première étape consiste à comprendre son état actuel, ses dépendances, les accès disponibles et ce qui peut être repris dans de bonnes conditions.
Selon ce que montre cet examen, la bonne suite peut être une reprise, une reprise partielle, une migration, une autre orientation ou la décision de ne pas intervenir.
Avant de décider quoi changer
Comprendre l’existant avant de proposer
Le premier niveau de lecture reste simple : comprendre ce qui existe, ce qui fonctionne encore, ce qui pose problème et ce dont vous avez besoin aujourd’hui.
Ce qui fonctionne encore
Identifier les fonctions utiles, les habitudes qui fonctionnent, les données ou contenus à préserver et les parties qui n’ont aucune raison d’être reconstruites.
Ce qui pose problème
Identifier les dysfonctionnements, la complexité devenue inutile, les difficultés de maintenance, les manipulations fragiles et les effets de bord possibles.
Ce dont vous avez besoin aujourd’hui
Clarifier les usages actuels, les nouvelles contraintes, les personnes concernées, le résultat recherché et ce qui doit impérativement être préservé.
Préserver ce qui mérite de l’être
Tout ce qui existe n’est pas un problème
Une reprise peut aussi consister à identifier ce qui fonctionne bien et mérite d’être conservé.
Remplacer une partie utile uniquement pour repartir sur quelque chose de neuf peut ajouter du coût, du risque et du travail sans apporter de valeur réelle.
Intervenir avec prudence
Modifier sans mettre inutilement l’existant en danger
Selon le projet, certaines vérifications permettent de réduire le risque avant d’intervenir. Leur profondeur dépend du contexte réel.
- les sauvegardes disponibles
- les accès nécessaires
- les données à protéger
- les dépendances importantes
- les zones fragiles
- les effets possibles sur le reste du fonctionnement
- la possibilité de revenir en arrière
Juste assez d’analyse
L’analyse doit rester proportionnée
Changer un texte sur un site et reprendre une application métier ancienne ne nécessitent pas le même niveau d’examen.
L’objectif est de comprendre suffisamment l’existant pour intervenir de manière responsable, pas de produire un audit plus lourd que le problème lui-même.
Le niveau d’analyse dépend notamment de l’impact, du risque, de la difficulté de retour arrière, de la complexité de l’existant et de l’incertitude restante.
Transparence technique facultative
Le détail technique vient lorsque le contexte le justifie
Pour aller plus loin techniquement
Lorsque c’est pertinent, l’examen peut aussi porter sur certains éléments techniques :
- organisation du code, CMS ou framework
- versions et dépendances
- données
- hébergement et environnement
- API et services externes
- dépôt Git et historique
- sauvegardes
- accès
- sécurité pertinente
Tous ces éléments ne sont pas systématiquement analysés au même niveau. Cette liste n’est pas une checklist contractuelle.
Plusieurs conclusions restent possibles
La reconstruction n’est qu’une issue parmi d’autres
Les six issues ci-dessous sont des conclusions parallèles. Aucune ne constitue une étape obligatoire vers la suivante.
Conserver
L’existant répond encore correctement au besoin et ne nécessite pas de changement important.
Stabiliser
La base reste pertinente mais certaines fragilités doivent être corrigées avant d’envisager autre chose.
Faire évoluer
La base reste adaptée et peut recevoir des modifications ciblées.
Simplifier
La difficulté vient principalement d’une complexité devenue inutile ; retirer ou réorganiser peut être préférable à ajouter.
Migrer
L’existant doit être quitté, sans que la réponse soit nécessairement un développement spécifique.
Reconstruire
La reconstruction reste possible lorsque l’existant ne constitue plus une base raisonnable. Elle est une conclusion de l’analyse, jamais son point de départ.
Un niveau d’intervention proportionné
Toutes les situations ne demandent pas la même profondeur d’analyse
Intervention directement cadrable
Pour un problème clair, un périmètre identifiable, un risque limité et un existant suffisamment compréhensible.
Diagnostic essentiel
Lorsque certaines vérifications doivent précéder la décision afin de clarifier l’état réel, les causes principales, ce qui peut être conservé, les principaux risques et les options réalistes.
Audit / cadrage approfondi
Pour une reprise plus complexe : application importante, nombreux composants, historique difficile, risque significatif, migration, reconstruction potentielle ou scénarios structurants à comparer.
Ces niveaux ne constituent pas une gamme « bon / mieux / premium ». Le niveau utile dépend de la situation.
Commencer sans tout connaître
Vous n’avez pas besoin de tout connaître avant de me contacter
Vous pouvez ne pas connaître la technologie utilisée, l’emplacement du code, l’existence d’une sauvegarde, les versions, tous les accès ou la meilleure solution entre corriger, migrer et reconstruire.
Ce n’est pas nécessaire pour commencer. Si certains accès, sauvegardes ou informations deviennent indispensables, ils feront partie des éléments à identifier avant de décider ce qui est possible dans de bonnes conditions.
Si le problème bloque l’activité
Un problème bloque actuellement votre activité ?
Vous pouvez le signaler dès votre premier contact afin que j’en comprenne la nature et l’impact.
Cela ne constitue pas une garantie de prise en charge immédiate avant examen de la situation.
Comment commencer ?
Quelques éléments suffisent pour démarrer
Pour commencer, il suffit de m’expliquer :
- ce que vous utilisez aujourd’hui ;
- ce qui vous pose problème ;
- ce que vous aimeriez pouvoir faire différemment ;
- et, si vous le savez, ce qui vous semble important à préserver.
Je pourrai alors déterminer avec vous si le besoin peut être cadré directement ou s’il mérite d’abord une analyse plus approfondie.
Partir de ce qui existe réellement
Vous avez un existant à reprendre ou à faire évoluer ?
Expliquez-moi simplement ce qui existe aujourd’hui et ce qui vous pose problème.