Score global
C
Exemple public de rapport CodeSure
github.com/acme-finance/platform
Référentiel analysé : github.com/acme-finance/platform
Cas type PME: un logiciel métier utile, exploité au quotidien, mais encore trop dépendant d’un petit nombre de personnes pour garantir une reprise rapide et sereine.
Comment lire cet exemple
Cette version publique montre uniquement les écrans les plus utiles pour un dirigeant: niveau de risque, dépendance, difficultés de reprise, risques urgents et premières actions.
Sommaire
Lecture rapide
Lecture rapide
Les repères essentiels apparaissent ici avant le détail: niveau de dépendance, vitesse de reprise, risques urgents et premières décisions à prendre.
Niveau de dépendance
Élevé
Difficulté estimée de reprise
4–6 semaines
Nombre de risques critiques
3
À retenir
- La reprise dépend encore trop du contexte détenu par la personne actuelle En cas de départ ou de rupture, vous paierez d'abord pour comprendre avant de pouvoir reprendre, ce qui vous place immédiatement en position faible.
- La restauration n’est pas suffisamment prouvée En cas d'incident de données, la sauvegarde peut exister sans garantir une reprise dans un délai acceptable pour l'activité, ce qui transforme un incident technique en risque opérationnel majeur.
- Le déploiement reste trop dépendant d’habitudes non formalisées Une correction urgente ou un changement de prestataire pourrait être bloqué plus longtemps que prévu, au moment où chaque jour de flottement coûte cher.
Ce qui fonctionne bien
- Le système fonctionne en production et soutient déjà l’activité.
- Le socle technique reste exploitable et identifiable.
- Une activité de développement récente existe encore.
Premières actions
-
Documenter la reprise minimale
C'est le gain de contrôle le plus rapide.
-
Consolider les accès critiques
Évite les blocages cachés au mauvais moment.
-
Tester la restauration
Transforme une hypothèse de continuité en preuve.
Ce que le rapport complet ajoute
- Cartographie détaillée des accès, dépendances et points de reprise
- Plan d’action priorisé avec effort estimé
- Support pour challenger un prestataire ou préparer une relève
1
Section 1
Ce que vous devez savoir immédiatement
Lecture en 5 minutes
Objectif de lecture
Donner une vision claire sans jargon.
À retenir
- La reprise du système resterait difficile sans la personne actuelle.
- Le risque principal est opérationnel: temps perdu, visibilité faible, décision sous contrainte.
- La priorité n'est pas une refonte, mais une base claire de continuité.
1.1
Votre niveau de risque global
Le niveau de risque n'est pas celui d'un système à l'arrêt. C'est celui d'un système qui fonctionne mais qui reste difficile à reprendre vite.
Niveau de risque
Élevé
Dépendance élevée
Score observé
49/100
Le score ne vaut que s’il explique une décision. Ici, il sert à estimer votre exposition concrète en cas d’incident, de changement ou de croissance.
Le système est exploitable aujourd'hui, mais la continuité dépend encore trop d'une connaissance concentrée, d'un déploiement peu transmissible et d'une reprise non prouvée. Le niveau de dépendance est déjà assez élevé pour compliquer une décision rapide.
Question à vous poser maintenant
Si votre développeur disparaît demain, le système ne s'arrête pas forcément tout de suite. En revanche, votre capacité à reprendre vite, à décider sereinement et à éviter une transition coûteuse reste aujourd'hui trop faible.
À traiter maintenant
Obtenir une base claire de reprise sous 30 jours: accès critiques, runbook minimum, déploiement et restauration testée.
Lecture dirigeant
Vous n'êtes pas face à une catastrophe technique immédiate. Vous êtes face à une dépendance opérationnelle déjà installée: si la personne actuelle disparaît demain, vous aurez besoin de temps avant de retrouver un contrôle réel.
1.2
Êtes-vous dépendant d’un prestataire ?
La dépendance observée porte autant sur la continuité et les accès que sur le code lui-même.
La dépendance n’est pas un sujet technique abstrait. Pour un dirigeant, elle se traduit par plus de temps facturé avant une reprise utile, moins de marge de négociation et davantage d’incertitude si la relation change.
Niveau actuel
Élevée
La connaissance utile, certains accès et plusieurs procédures restent trop concentrés.
Ce que cela change pour vous
Si la personne actuelle n’est plus disponible, votre premier problème ne sera pas seulement technique. Ce sera le temps perdu avant de retrouver de la visibilité, des accès et une capacité réelle à décider.
Preuve à obtenir sans attendre
Demandez une preuve de restauration testée et une cartographie des accès critiques avant tout arbitrage important.
Si vous devez changer de prestataire
Semaine 1: le nouveau partenaire passera surtout du temps à reconstruire le contexte, identifier les accès et comprendre les flux critiques.
Semaine 2: la reprise peut commencer sur les zones les plus visibles, mais les zones sensibles resteront dépendantes d'une transmission active.
Semaine 3 et plus: sans documentation de continuité ni preuve de recovery, le coût d'une transition augmente vite et devient nettement plus difficile à challenger.
Ce qui crée la dépendance aujourd’hui
-
Connaissance des flux clés concentrée sur trop peu de personnes.
-
Accès critiques non cartographiés de manière consolidée.
-
Déploiement et restauration encore peu transmissibles.
Lecture rapide
Ce que vous devez pouvoir comprendre en moins de 2 minutes
Si rien ne change
Ce qui se passera le plus probablement
-
Dans 3 mois
- Le système continuera probablement à tourner, mais la dépendance humaine restera entière.
- Chaque changement important demandera toujours plus de prudence que nécessaire.
-
Dans 6 mois
- La reprise deviendra plus coûteuse à challenger si la documentation n'avance pas.
- Le moindre départ ou incident vous placera plus vite dans l'urgence.
-
Dans 12 mois
- Le coût caché de dépendance risque de dépasser largement le coût d'une sécurisation précoce.
- Changer de prestataire ou recruter un repreneur deviendra plus lent, plus cher et plus tendu.
Difficulté estimée de reprise
Temps et obstacles probables
-
Temps estimé pour une reprise utile
3 à 6 semaines pour retrouver une capacité d’action confortable, selon la qualité de la transmission disponible au moment du changement.
-
Difficulté d’onboarding
Élevée au départ, puis décroissante si les accès, le déploiement et la logique métier sont clarifiés rapidement.
-
Principaux obstacles
- documentation incomplète
- déploiement manuel
- dépendance humaine
- reprise non prouvée sur la restauration
Niveau réel de dépendance
Ce que cela veut dire en pratique
-
Détenteurs critiques de connaissance
2 personnes au maximum semblent capables de remettre rapidement le système sous contrôle sans phase longue de reconstruction.
-
Concentration observée
Élevée. L’historique, les accès et les procédures restent encore trop liés à la personne actuelle et à son contexte.
-
Exposition opérationnelle
Modérée à élevée. Le système peut tenir au quotidien, mais votre capacité à agir vite reste trop dépendante d’un petit nombre de personnes.
1.3
Les 3 risques les plus urgents
Les risques les plus urgents sont ceux qui vous feraient perdre du temps avant même de pouvoir agir.
Risque 1
La reprise dépend encore trop du contexte détenu par la personne actuelle
En cas de départ ou de rupture, vous paierez d'abord pour comprendre avant de pouvoir reprendre, ce qui vous place immédiatement en position faible.
Premier pas recommandé
Documenter la reprise minimale et enregistrer une session de transmission.
- README incomplet
- 72% des commits concentrés sur un auteur
Risque 2
La restauration n’est pas suffisamment prouvée
En cas d'incident de données, la sauvegarde peut exister sans garantir une reprise dans un délai acceptable pour l'activité, ce qui transforme un incident technique en risque opérationnel majeur.
Premier pas recommandé
Tester une restauration complète et consigner la durée réelle.
- docs/recovery.md absent
- aucun test de restauration horodaté retrouvé
Risque 3
Le déploiement reste trop dépendant d’habitudes non formalisées
Une correction urgente ou un changement de prestataire pourrait être bloqué plus longtemps que prévu, au moment où chaque jour de flottement coûte cher.
Premier pas recommandé
Formaliser une procédure de déploiement répétable.
- deploy.sh partiel
- absence de procédure consolidée
À arbitrer vite
-
Absence de preuve de restauration complète.
-
Reprise dépendante d'une transmission orale.
-
Mise en production trop liée aux habitudes de la personne actuelle.
1.4
Ce qui fonctionne bien aujourd’hui
Le système a aussi des points solides: il n'est ni abandonné ni anarchique.
- Le système fonctionne en production et soutient déjà l’activité.
- Le socle technique reste exploitable et identifiable.
- Une activité de développement récente existe encore.
- La structure générale n’impose pas une reprise depuis zéro.
Ce qu’il faut encore vérifier
- La rapidité réelle de reprise sans le développeur actuel.
- La liste complète des accès critiques et de leurs propriétaires.
- La capacité à restaurer vite après incident sans dépendre de la même personne.
Points rassurants
-
Socle Symfony moderne.
-
Activité Git récente.
-
Structure générale de projet exploitable.
-
Présence de premiers tests automatisés.
1.5
Ce que nous vous recommandons de faire en premier
L'objectif n'est pas de tout refaire. L'objectif est de retrouver une base de décision et de continuité.
Priorité 1
Documenter la reprise minimale
C'est le gain de contrôle le plus rapide.
Intervenant recommandé : Interne + développeur actuel
Priorité 2
Consolider les accès critiques
Évite les blocages cachés au mauvais moment.
Intervenant recommandé : Dirigeant + responsable technique
Priorité 3
Tester la restauration
Transforme une hypothèse de continuité en preuve.
Intervenant recommandé : Prestataire ou développeur + décideur
Actions à lancer d’abord
-
Documenter la reprise minimale.
-
Consolider les accès critiques.
-
Tester une restauration complète.
-
Rendre le déploiement répétable.
2
Section 2
Comprendre votre système
Ce qui le compose et ce qui le fait fonctionner
Objectif de lecture
Donner au dirigeant une vision claire de ce qu’il possède et de ce qui fait réellement tourner son activité.
À retenir
- Le système repose sur des briques compréhensibles, mais plusieurs éléments critiques restent peu explicités.
- Sans vision claire des services et dépendances externes, une reprise rapide resterait incomplète.
2.1
Les briques principales de votre système
Le système repose sur un cœur applicatif Symfony, quelques services annexes et plusieurs intégrations externes.
Briques principales
-
Application métier Symfony/Twig.
-
Base de données relationnelle.
-
Services d’email, stockage et supervision.
-
Scripts d’exploitation et déploiement partiels.
2.2
Les technologies utilisées
La stack est globalement moderne et courante, ce qui aide une reprise future.
Technologies détectées
-
PHP / Symfony 6.x
-
Twig
-
JavaScript
-
Composer + npm
2.3
Les services externes indispensables
Le système dépend de plusieurs services externes qui doivent être connus, accessibles et documentés pour une reprise.
Services externes indispensables
-
Hébergement cloud
-
Base de données managée
-
Email transactionnel
-
Monitoring
-
Sauvegardes et stockage
2.4
Les éléments critiques pour faire fonctionner votre activité
Les éléments critiques pour l’activité ne sont pas seulement techniques: ce sont aussi les flux métier qu’il faut pouvoir remettre en marche rapidement.
Éléments critiques
-
Authentification et accès utilisateurs
-
Génération de rapports
-
Synchronisations métier
-
Gestion des paiements ou événements bloquants
2.5
Les points où votre activité pourrait s’arrêter
Les points d’arrêt probables sont connus: accès manquants, restauration non testée, déploiement lent ou compréhension insuffisante des flux.
Point de vigilance majeur
Le système peut continuer à tourner quelques jours sans intervention. Mais s'il faut corriger, déployer ou restaurer vite, la fragilité devient immédiatement visible.
3
Section 3
Votre dépendance réelle à votre prestataire
Le vrai risque pour beaucoup d’entreprises
Objectif de lecture
Mesurer le niveau réel de dépendance, la difficulté de reprise, et le risque de verrouillage technique.
À retenir
- Le niveau réel de dépendance est élevé, même si le système n'est pas bloqué aujourd'hui.
- Une transition resterait faisable, mais lente et coûteuse sans préparation minimale.
- Le vrai risque est la perte de vitesse de décision en cas de départ ou de rupture.
3.1
Qui détient réellement le savoir technique
Le savoir technique utile reste concentré dans la personne qui tient l’historique récent du projet.
Indices observés
-
Commit
72% des commits récents sur un auteur
La reprise resterait possible, mais lente sans sa participation.
-
Docs
Documentation partielle
Le dépôt n'explique pas encore assez la logique métier et les points sensibles.
3.2
Ce qui se passerait en cas de départ du prestataire
En cas de départ du prestataire ou du développeur, le système ne s’arrête pas forcément. Ce qui s’arrête d’abord, c’est votre vitesse de réaction.
Ce qui changerait immédiatement
Le premier effet probable serait une hausse du temps de compréhension, des questions sur les accès et une prudence plus forte avant chaque intervention utile.
3.3
Les zones que personne d’autre ne pourrait reprendre facilement
Les zones les plus difficiles à reprendre sont les flux métier personnalisés et les opérations peu documentées.
Zones les moins facilement transférables
-
Import et synchronisations métier
-
Procédure de déploiement
-
Restauration après incident
-
Convention de traitement des cas métier atypiques
3.4
Les signes d’un verrouillage technique (lock-in)
Le verrouillage observé n'est pas un lock-in brutal. C'est un lock-in progressif: plus vous attendez, plus la sortie coûte cher.
Signes de verrouillage progressif
-
Difficulté à challenger un chiffrage sans contexte détaillé.
-
Accès critiques non cartographiés.
-
Procédures de continuité non consolidées.
3.5
Votre niveau réel d’autonomie
Votre autonomie actuelle est partielle: vous possédez le système, mais pas encore toute la visibilité nécessaire pour décider sans dépendre du récit de la personne en place.
Niveau d’autonomie
Autonomie partielle: suffisante pour piloter au quotidien, insuffisante pour une transition rapide sans préparation.
3.6
Niveau de documentation
Le niveau de documentation n'est pas nul. Il est simplement trop faible pour rassurer sur la continuité.
Ce qu’il manque surtout
-
Carte simple du système
-
Inventaire des accès critiques
-
Runbook de recovery
-
Guide de déploiement transmissible
3.7
Difficulté estimée de reprise
La reprise par un tiers paraît réaliste mais difficile sans phase préalable de sécurisation.
Difficulté estimée de reprise
Difficile mais faisable. Le coût d'entrée viendra surtout du contexte à reconstruire, pas d'une impossibilité technique absolue.
Principaux obstacles
-
Documentation de continuité incomplète.
-
Déploiement encore trop manuel.
-
Connaissance métier et opératoire trop concentrée.
3.8
Temps estimé pour une transition
Une transition préparée pourrait être engagée. Une transition subie serait plus lente, plus chère et plus tendue.
Temps estimé
-
1re semaine: reconstruction du contexte et des accès
-
2e semaine: premières interventions utiles sur les zones visibles
-
3e semaine et plus: sécurisation des zones sensibles et baisse du risque
4
Section 4
Vos données et votre activité sont-elles en sécurité ?
Risque légal, financier et réputationnel
Objectif de lecture
Activer la peur rationnelle (RGPD, fuite, piratage).
À retenir
- Le risque sécurité principal est surtout un risque de continuité et de contrôle, pas un scénario catastrophe déjà visible.
- Sans clarification des accès et des responsabilités, un incident deviendrait plus long à contenir.
4.1
Niveau global de sécurité
Le niveau de sécurité observé n'appelle pas d'alerte dramatique immédiate, mais il reste insuffisamment industrialisé.
Lecture utile
Le sujet principal n'est pas une faille spectaculaire déjà visible. C'est l'absence de routine assez forte pour éviter une dette de sécurité silencieuse.
4.2
Gestion des accès et des comptes
La gestion des accès mérite d'être consolidée pour réduire le risque opérationnel.
Accès à clarifier
-
Cloud et hébergement
-
Base de données
-
DNS et certificats
-
Monitoring et sauvegardes
-
Comptes tiers
4.3
Protection des données sensibles
Les données sensibles semblent traitées dans un cadre correct, mais la traçabilité des responsabilités reste partielle.
Ce qui manque surtout
-
Propriétaire identifié de chaque secret critique
-
Journal simple des rotations ou vérifications
-
Vision consolidée des intégrations sensibles
4.4
Exposition à des failles connues
Quelques dépendances en retard existent, sans justifier un discours alarmiste à elles seules.
Constat
-
Dépendances
MEDIUM23% en retard notable
Le sujet est gérable si une revue régulière est lancée.
4.5
Risques en cas d’incident
En cas d'incident, le risque majeur serait moins l'attaque elle-même que le temps perdu à reprendre le contrôle sans documentation suffisante.
Risque en cas d’incident
Le facteur aggravant serait l'absence de procédure claire de reprise plutôt qu'une exposition extrême déjà prouvée.
Repères complémentaires
Repères techniques visibles dans cet exemple
Ces indicateurs ne sont pas la conclusion. Ils montrent le type de faits utilisés pour documenter un échange avec un prestataire, un repreneur ou un responsable interne.
findings count
12
git contributor count
2
git total commits
428
git commits last 90 days
47
scc file count
186
scc line count
28440
scc code count
17380
scc comment count
2080
scc complexity
108
repository count
1
active contributor count
2
commit frequency
3.6 per week
test coverage estimate
18
dependency outdated ratio
23
documentation presence score
32
automation score
41
recovery readiness score
24
bus factor estimate
1
deployment repeatability score
37
Passer à votre diagnostic
Votre situation ne ressemblera pas exactement à cet exemple.
L’intérêt du diagnostic n’est pas de lire un cas générique. C’est de savoir si, dans votre entreprise, un changement de prestataire, un départ ou un incident vous bloque pendant 2 jours, 2 semaines ou 2 mois.