Auditer sa dette technique

Code legacy et réusinage

Y a-t-il des parties du code qui n'ont pas été modifiées depuis longtemps ?

  • Identifier les sections de code inchangées depuis plusieurs années peut indiquer des zones potentielles de dette technique.

Le code legacy est-il bien documenté ?

  • Vérifier si la documentation est suffisante pour comprendre le fonctionnement du code sans avoir à lire le code en détail.

Existe-t-il des dépendances à des technologies ou des frameworks obsolètes ?

  • Identifier les dépendances à des versions de bibliothèques ou des technologies qui ne sont plus supportées.

Combien de bugs sont associés aux parties legacy du code ?

  • Analyser le nombre de bugs et leur fréquence pour déterminer la stabilité du code legacy.

Le code legacy suit-il les standards de codage actuels de l'organisation ?

  • Comparer le code legacy aux standards de codage actuels pour identifier les écarts et les opportunités de réusinage.

Quel est le temps nécessaire pour comprendre et modifier le code legacy ?

  • Évaluer la complexité et la lisibilité du code en demandant aux développeurs combien de temps il leur faut pour comprendre et modifier le code legacy.

Y a-t-il des modules ou des classes qui sont surchargés de responsabilités ?

  • Identifier les parties du code qui ne respectent pas le principe de responsabilité unique et pourraient bénéficier d'un découpage.

Les tests unitaires couvrent-ils le code legacy ?

  • Vérifier la couverture de tests unitaires pour s'assurer que le code legacy est bien testé et qu'il n'y a pas de zones non testées.

Quels sont les retours des développeurs sur le code legacy ?

  • Collecter les retours d'expérience des développeurs pour identifier les parties du code legacy qui posent des problèmes fréquents.

Existe-t-il des redondances ou du code dupliqué dans le code legacy ?

  • Rechercher les duplications de code qui pourraient être centralisées ou refactorisées pour améliorer la maintenabilité.

Qualité du code

Les standards de codage sont-ils définis et documentés ?

  • Vérifier l'existence de standards de codage clairs et documentés que tous les développeurs doivent suivre.

Les développeurs respectent-ils les standards de codage ?

  • Analyser le code pour vérifier la conformité avec les standards définis, en utilisant des outils de linting par exemple.

Quelle est la qualité de la documentation dans le code ?

  • Évaluer si le code est bien commenté et si la documentation est suffisante pour comprendre le fonctionnement des différentes parties du code.

Y a-t-il des outils de vérification automatique de la qualité du code en place ?

  • Identifier les outils utilisés pour vérifier automatiquement la qualité du code, comme linters, analyseurs statiques, etc.

Le code est-il cohérent en termes de style et de structure ?

  • Vérifier si le code suit un style de codage cohérent et uniforme à travers tout le projet.

Les revues de code sont-elles régulièrement effectuées ?

  • Analyser la fréquence et l'efficacité des revues de code pour détecter et corriger les erreurs ou les déviations par rapport aux standards.

Combien de warnings et d'erreurs sont générés par les outils d'analyse statique du code ?

  • Utiliser les outils d'analyse statique pour évaluer la quantité et la gravité des warnings et des erreurs dans le code.

Le code est-il modulable et réutilisable ?

  • Évaluer si le code est écrit de manière à pouvoir être facilement réutilisé et modifié sans introduire de bugs.

Quelle est la complexité cyclomatique du code ?

  • Mesurer la complexité cyclomatique pour évaluer la complexité du code et identifier les zones potentiellement difficiles à maintenir.

Y a-t-il des pratiques de développement modernes en place (par exemple, programmation orientée objet, programmation fonctionnelle, etc.) ?

  • Vérifier l'utilisation de pratiques de développement modernes et adaptées pour améliorer la qualité et la maintenabilité du code.

Tests et couverture de code

Quelle est la couverture de code actuelle par les tests ?

  • Utiliser des outils pour mesurer le pourcentage de code couvert par les tests unitaires, d'intégration et fonctionnels.

Existe-t-il des tests unitaires pour toutes les fonctionnalités critiques ?

  • Vérifier si toutes les fonctionnalités critiques de l'application ont des tests unitaires associés.

Les tests sont-ils automatisés ?

  • Évaluer le niveau d'automatisation des tests et l'efficacité des pipelines CI/CD pour exécuter ces tests.

Les tests sont-ils régulièrement exécutés ?

  • Examiner la fréquence d'exécution des tests, notamment après chaque changement de code ou à intervalles réguliers.

Quelle est la qualité des tests écrits ?

  • Analyser les tests pour s'assurer qu'ils sont bien écrits, clairs et qu'ils couvrent les cas d'usage pertinents.

Les tests couvrent-ils les cas d'erreur et les cas limites ?

  • Vérifier si les tests incluent des scénarios de cas d'erreur, des cas limites et des conditions exceptionnelles.

Quel est le temps d'exécution des tests ?

  • Évaluer si les tests sont optimisés pour s'exécuter rapidement afin de ne pas ralentir le cycle de développement.

Les tests sont-ils maintenus et mis à jour avec les changements de code ?

  • Vérifier si les tests sont régulièrement mis à jour pour refléter les modifications apportées au code source.

Y a-t-il une politique de revue de tests en place ?

  • Analyser si les tests sont soumis à des revues de code pour garantir leur qualité et leur pertinence.

Les tests sont-ils isolés et indépendants les uns des autres ?

  • Vérifier si les tests sont écrits de manière à être indépendants, sans effets de bord, pour garantir des résultats fiables à chaque exécution.

Architecture et conception

L'architecture du système est-elle documentée ?

  • Vérifier si l'architecture actuelle est bien documentée et accessible à tous les membres de l'équipe.

L'architecture respecte-t-elle les principes de conception modernes ?

  • Évaluer si l'architecture utilise des principes de conception modernes, tels que SOLID, DRY (Don't Repeat Yourself), et KISS (Keep It Simple, Stupid).

L'architecture est-elle modulaire et extensible ?

  • Analyser si le système est divisé en modules clairement définis et s'il peut être facilement étendu ou modifié.

Le design permet-il une scalabilité horizontale et verticale ?

  • Vérifier si le système peut facilement évoluer en ajoutant plus de ressources (scalabilité verticale) ou en ajoutant plus de instances (scalabilité horizontale).

Y a-t-il des points de défaillance uniques (SPOF) dans l'architecture ?

  • Identifier et évaluer les points de défaillance uniques qui pourraient compromettre la disponibilité du système.

Les composants de l'architecture sont-ils découplés et indépendants ?

  • Vérifier si les composants peuvent fonctionner de manière indépendante, réduisant ainsi les dépendances et facilitant les mises à jour.

L'architecture prend-elle en compte la sécurité dès la conception ?

  • Analyser si les aspects de sécurité sont intégrés dès la phase de conception, incluant des mécanismes de protection contre les menaces courantes.

L'architecture est-elle alignée avec les besoins métiers et les objectifs de l'organisation ?

  • Évaluer si l'architecture supporte bien les objectifs stratégiques et les besoins spécifiques des utilisateurs finaux.

Le système est-il conçu pour une résilience et une tolérance aux pannes ?

  • Vérifier si des mécanismes de résilience, tels que la redondance et le failover, sont intégrés pour assurer la continuité des opérations.

Comment les décisions d'architecture sont-elles prises et documentées ?

  • Examiner le processus de prise de décision en matière d'architecture, y compris la documentation des choix et des compromis faits.

Documentation technique

La documentation technique est-elle complète et à jour ?

  • Vérifier si la documentation couvre tous les aspects nécessaires du système et s'il est régulièrement mis à jour pour refléter les changements récents.

La documentation est-elle accessible à tous les membres de l'équipe ?

  • Évaluer si la documentation est facilement accessible et disponible pour tous les membres de l'équipe, y compris les nouveaux arrivants.

La documentation est-elle bien structurée et facile à naviguer ?

  • Analyser la structure de la documentation pour s'assurer qu'elle est organisée de manière logique et qu'il est facile de trouver les informations nécessaires.

Les guides d'installation et de configuration sont-ils clairs et complets ?

  • Vérifier si les guides fournissent des instructions détaillées pour installer et configurer le système.

Les descriptions des API et des interfaces sont-elles détaillées et précises ?

  • Examiner si les API et autres interfaces du système sont bien documentées, avec des exemples d'utilisation et des descriptions claires des paramètres et des réponses.

Y a-t-il une documentation des processus de développement et de déploiement ?

  • Vérifier si les processus de développement, de déploiement et de CI/CD sont bien documentés pour garantir la cohérence et la reproductibilité.

Les diagrammes et illustrations sont-ils utilisés de manière efficace ?

  • Évaluer l'utilisation de diagrammes, de schémas et d'autres visuels pour expliquer les concepts complexes et les relations entre les composants du système.

La documentation inclut-elle des informations sur les meilleures pratiques et les normes de codage ?

  • Analyser si la documentation technique fournit des directives sur les meilleures pratiques et les standards de codage à suivre.

Les procédures de dépannage et les FAQ sont-elles disponibles et utiles ?

  • Vérifier si des guides de dépannage et des sections FAQ sont inclus pour aider à résoudre les problèmes courants.

Y a-t-il un processus en place pour maintenir et améliorer la documentation ?

Dépendances externes

Quelles sont les principales dépendances externes utilisées dans le projet ?

  • Identifier et répertorier toutes les bibliothèques, frameworks, services tiers et autres dépendances externes.

Les dépendances externes sont-elles à jour ?

  • Vérifier si toutes les dépendances sont à jour avec les dernières versions stables disponibles.

Les dépendances externes sont-elles maintenues et activement développées ?

  • Analyser la fréquence des mises à jour et l'activité de la communauté ou des mainteneurs des dépendances.

Y a-t-il des vulnérabilités de sécurité connues dans les dépendances externes ?

  • Utiliser des outils de scan de sécurité pour détecter les vulnérabilités dans les dépendances et vérifier les bases de données de vulnérabilités connues.

Les licences des dépendances externes sont-elles compatibles avec les politiques de l'organisation ?

  • Vérifier si les licences des dépendances sont compatibles avec les exigences légales et de conformité de l'organisation.

Quelle est l'impact de l'obsolescence potentielle des dépendances ?

  • Évaluer les risques liés à l'obsolescence des dépendances et la disponibilité de leurs alternatives.

Les dépendances externes sont-elles bien intégrées et gérées dans le projet ?

  • Vérifier l'intégration des dépendances dans le projet, y compris la gestion des versions et les scripts d'installation.

Y a-t-il des tests spécifiques pour les fonctionnalités fournies par les dépendances externes ?

  • Examiner si des tests sont en place pour vérifier le bon fonctionnement des fonctionnalités critiques fournies par les dépendances externes.

Quel est le plan de secours en cas de défaillance ou d'indisponibilité des services tiers ?

  • Identifier les plans de secours et les stratégies de mitigation en cas de défaillance des services tiers critiques.

Comment les dépendances externes sont-elles documentées ?

  • Vérifier si la documentation du projet inclut des informations détaillées sur les dépendances, leur utilisation, et les instructions pour les mettre à jour ou les remplacer.

Sécurité et conformité

Les politiques de sécurité sont-elles documentées et accessibles à tous les membres de l'équipe ?

  • Vérifier si les politiques de sécurité sont clairement définies, documentées et facilement accessibles à tous.

Y a-t-il des procédures en place pour la gestion des vulnérabilités ?

  • Analyser si des procédures existent pour identifier, évaluer, et remédier aux vulnérabilités de sécurité.

Les données sensibles sont-elles chiffrées en transit et au repos ?

  • Vérifier si des mesures de chiffrement sont mises en place pour protéger les données sensibles à la fois en transit et au repos.

Des audits de sécurité réguliers sont-ils effectués ?

  • Examiner la fréquence et l'efficacité des audits de sécurité pour identifier les failles potentielles.

Les accès aux systèmes et aux données sont-ils contrôlés et limités en fonction des rôles ?

  • Vérifier si les principes de moindre privilège et de séparation des tâches sont appliqués pour contrôler les accès.

Un plan de réponse aux incidents est-il en place ?

  • Évaluer si un plan détaillé de réponse aux incidents existe, incluant les procédures à suivre en cas de violation de la sécurité.

Les employés reçoivent-ils une formation régulière sur la sécurité ?

  • Analyser si des formations régulières sur les meilleures pratiques de sécurité et la sensibilisation aux menaces sont dispensées aux employés.

Les systèmes et les applications sont-ils régulièrement mis à jour et corrigés ?

  • Vérifier si des processus sont en place pour appliquer régulièrement les mises à jour et les correctifs de sécurité.

La conformité aux réglementations et aux normes de l'industrie est-elle régulièrement vérifiée ?

  • Examiner si des audits de conformité sont réalisés pour s'assurer que les systèmes respectent les normes et les réglementations applicables (GDPR, HIPAA, etc.).

Y a-t-il des mécanismes de surveillance et de détection des intrusions en place ?

  • Évaluer l'efficacité des systèmes de surveillance et de détection des intrusions pour identifier et réagir rapidement aux menaces potentielles.

Performance et capacité de mise à l'échelle

Quels sont les indicateurs de performance clés (KPIs) utilisés pour mesurer les performances du système ?

  • Identifier les KPIs actuels utilisés pour évaluer la performance, comme le temps de réponse, le débit et l'utilisation des ressources.

Y a-t-il des tests de performance réguliers effectués sur le système ?

  • Vérifier si des tests de performance, tels que les tests de charge et de stress, sont réalisés régulièrement pour évaluer la capacité du système à gérer des volumes de trafic élevés.

Le système est-il capable de gérer des pics de charge sans dégradation des performances ?

  • Analyser la capacité du système à maintenir des performances acceptables sous des charges élevées et soudaines.

Quelle est l'architecture actuelle en termes de scalabilité horizontale et verticale ?

  • Évaluer si le système est conçu pour évoluer en ajoutant des ressources (scalabilité verticale) ou des instances supplémentaires (scalabilité horizontale).

Les goulots d'étranglement potentiels ont-ils été identifiés et traités ?

  • Identifier les parties du système qui pourraient limiter la performance et vérifier si des mesures ont été prises pour les atténuer.

Les ressources sont-elles correctement dimensionnées pour les besoins actuels et futurs ?

  • Vérifier si les ressources allouées (CPU, mémoire, stockage, etc.) sont suffisantes pour les besoins actuels et peuvent être ajustées pour les besoins futurs.

Y a-t-il des mécanismes en place pour surveiller en temps réel les performances du système ?

  • Examiner les outils et les pratiques de surveillance en temps réel pour détecter et résoudre rapidement les problèmes de performance.

Les stratégies de mise en cache sont-elles efficaces ?

  • Analyser l'utilisation de la mise en cache pour améliorer les performances et réduire la charge sur les ressources principales.

Le système utilise-t-il des techniques de répartition de charge (load balancing) ?

  • Vérifier si des techniques de répartition de charge sont utilisées pour distribuer efficacement le trafic et améliorer la disponibilité.

Comment les incidents de performance sont-ils traités et résolus ?

  • Évaluer les procédures de gestion des incidents de performance, y compris l'identification, la priorisation et la résolution des problèmes.

Gestion de la configuration et déploiement

Existe-t-il une documentation complète des configurations système et des paramètres ?

  • Vérifier si toutes les configurations et les paramètres système sont documentés de manière exhaustive et accessibles à l'équipe.

Utilisez-vous des outils de gestion de configuration (CM) ?

  • Identifier les outils de gestion de configuration utilisés (comme Ansible, Chef, Puppet) et évaluer leur efficacité dans la gestion des configurations.

Les configurations sont-elles versionnées et traçables ?

  • Examiner si les configurations sont versionnées dans un système de contrôle de version (comme Git) et si les changements sont traçables.

Existe-t-il des processus de revue et d'approbation des changements de configuration ?

  • Vérifier si les changements de configuration sont soumis à des processus de revue et d'approbation pour éviter les erreurs et les conflits.

Les déploiements sont-ils automatisés ?

  • Évaluer le niveau d'automatisation des processus de déploiement, y compris l'utilisation de pipelines CI/CD (Intégration Continue et Déploiement Continu).

Les environnements de développement, de test et de production sont-ils cohérents ?

  • Analyser si les configurations des environnements de développement, de test et de production sont cohérentes pour éviter les problèmes lors des déploiements.

Comment gérez-vous les secrets et les informations sensibles dans les configurations ?

  • Vérifier les méthodes utilisées pour gérer les secrets (comme les mots de passe, les clés API) dans les configurations de manière sécurisée.

Les déploiements incluent-ils des étapes de validation et de test ?

  • Examiner si les processus de déploiement incluent des étapes de validation et de test pour s'assurer que les déploiements sont réussis et sans erreurs.

Comment les incidents liés aux configurations sont-ils détectés et résolus ?

  • Évaluer les processus en place pour détecter, signaler et résoudre les incidents liés aux configurations rapidement et efficacement.

Y a-t-il un plan de retour en arrière (rollback) en cas de déploiement échoué ?

  • Vérifier si des plans de rollback sont en place pour revenir à une version précédente en cas de problème lors d'un déploiement.

Maintenance et support

Existe-t-il une documentation claire et à jour pour les procédures de maintenance ?

  • Vérifier si les procédures de maintenance sont bien documentées et mises à jour régulièrement.

Y a-t-il une équipe dédiée à la maintenance et au support ?

  • Identifier si une équipe spécifique est responsable de la maintenance et du support, et évaluer leurs compétences et leur disponibilité.

Quels outils de suivi des incidents et des demandes de support sont utilisés ?

  • Examiner les outils de gestion des incidents et des demandes de support (comme JIRA, ServiceNow) pour évaluer leur efficacité.

Quel est le temps moyen de résolution des incidents ?

  • Analyser les métriques de performance, telles que le temps moyen de résolution (MTTR), pour évaluer l'efficacité des processus de support.

Les incidents sont-ils correctement priorisés en fonction de leur impact et de leur urgence ?

  • Vérifier si les incidents sont classés et traités en fonction de leur impact sur les opérations et leur urgence.

Les correctifs et mises à jour sont-ils régulièrement appliqués ?

  • Évaluer la fréquence et la rigueur avec lesquelles les correctifs et les mises à jour de sécurité sont appliqués.

Y a-t-il des tests post-maintenance pour garantir la stabilité du système ?

  • Vérifier si des tests de régression et de validation sont effectués après les opérations de maintenance pour assurer la stabilité du système.

Les utilisateurs finaux sont-ils satisfaits du support reçu ?

  • Analyser les retours d'expérience des utilisateurs finaux concernant la qualité du support et leur satisfaction globale.

Des audits de maintenance réguliers sont-ils effectués ?

  • Examiner si des audits réguliers sont menés pour évaluer l'efficacité des pratiques de maintenance et identifier les domaines à améliorer.

Existe-t-il des plans de continuité et de reprise après sinistre en place ?

  • Vérifier si des plans de continuité des opérations et de reprise après sinistre sont définis et régulièrement testés.

 

Le Bundle complet DYNAMAP en PDF à prix préférentiel : Livrables expliqués et manuel de cartographie

© Yann-Eric DEVARS - DYNAMAP. Tous droits réservés.

Nous avons besoin de votre consentement pour charger les traductions

Nous utilisons un service tiers pour traduire le contenu du site web qui peut collecter des données sur votre activité. Veuillez consulter les détails dans la politique de confidentialité et accepter le service pour voir les traductions.