Au premier abord, la qualité du code applicatif semble être une simple question technique, dont seuls les développeurs devraient se préoccuper. Il n’en est rien. Si un code source de qualité médiocre n’a que peu d’impact tant qu’il s’agit d’applicatifs mineurs, dès lors qu’il s’agit d’applications stratégiques pour l’entreprise, la non-qualité a un coût.
Dans le domaine de la qualité du code, deux aspects doivent être pris en compte : la manière dont le code est écrit et structuré, autrement dit sa syntaxe, et la manière dont il s’exécute. Le présent article est consacré aux méthodes d’audit de code, qui permettent de gérer le premier aspect. Les problématiques de test, qui permettent de contrôler la qualité de l’exécution, seront abordées dans un prochain article.
Les pratiques d’audit de code permettent de contrôler la qualité syntaxique, en particulier grâce aux outils dits « d’analyse statique ».
Ces solutions permettent en effet d’analyser et de comparer des codes sources pour détecter les modifications, vérifier des règles d’écriture (syntaxe, nommage, documentation, complexité des algorithmes, usage d’instructions obsolètes, etc.), voire identifier des failles de sécurité ou des bugs potentiels, liés par exemple à la manière d’accéder aux bases de données. Les offres les plus évoluées permettent en outre un suivi dans le temps et fournissent des indicateurs sur la composition du patrimoine applicatif, sa structure et sa qualité.
L’audit de code, pour quoi faire ?
La qualité de la syntaxe est un paramètre important quand il s’agit d’assurer la maintenance des applications. Des applicatifs au code peu lisible ou mal conçu sont plus difficiles à faire évoluer, une simple adaptation pouvant prendre des semaines là où il ne faudrait que quelques jours, voire moins avec un code bien écrit.
Dans le cas d’applicatifs développés et/ou dont la maintenance est assurée en externe, ces dérives peuvent vite se chiffrer en millions d’euros sur les gros projets. Toute entreprise possédant des applications susceptibles d’évoluer plus ou moins fréquemment a donc intérêt à surveiller la qualité de leur code source, afin que le moment venu, les modifications et adaptations puissent être effectuées dans les temps et dans les budgets.
Ces bonnes pratiques sont d’autant plus importantes que le développement s’effectue de manière distribuée ou fait appel à des grandes équipes, dans lesquelles chaque développeur est susceptible d’intervenir sur des modules écrits par d’autres.
En outre, dépendre entièrement des personnes développant une application est dangereux pour une entreprise, en particulier quand il s’agit d’un applicatif stratégique. Si le code source n’est compréhensible que des développeurs initiaux, alors de tels applicatifs sont de fait des « boîtes noires » sur lesquelles l’entreprise n’a aucune maîtrise.
Dans le cas d’un développement interne, si ces développeurs quittent l’entreprise, toute intervention sur l’application deviendra de facto un projet compliqué. En cas de développement en externe, il est tout autant primordial de conserver la maîtrise des applicatifs. Sans cela toute clause de réversibilité est par avance inutile.
Un audit de chaque nouveau développement permet de contrôler que le code source respecte les règles nécessaires pour que n’importe quel développeur expérimenté puisse intervenir.
Enfin, un cas est un peu à part, celui des développements effectués sur des progiciels : si les deux aspects mentionnés ci-dessus restent valables, l’audit permet également d’identifier et de tracer précisément les développements spécifiques, un atout pour les projets de montée de version/migration. Un suivi précis des développements spécifiques évite également certaines dérives dans les contrats d’externalisation.
Quand effectuer des audits ?
Le premier cas de figure est celui d’une entreprise ne disposant pratiquement pas d’indicateurs sur son patrimoine applicatif et souhaitant avoir une vision plus précise et chiffrée de ce dernier. Dans cette situation, un audit approfondi est nécessaire. Une telle opération peut vite demander du temps, d’autant plus quand elle porte sur un parc vaste et hétérogène.
Un tel audit est une opération ponctuelle, destinée à la prise de décision. Les informations ainsi recueillies permettront d’identifier les applications susceptibles de poser problème afin de les moderniser ou de les remplacer, ainsi que celles qui peuvent être confiées sans risque à un prestataire. Ces audits ponctuels peuvent être effectués en mode à la demande, certains prestataires fournissant ce type de service.
Le second cas de figure concerne les entreprises qui souhaitent surveiller de près une ou plusieurs applications stratégiques, sur lesquelles des modifications sont souvent effectuées. Dans ce cas, un suivi régulier s’impose, la qualité du patrimoine applicatif étant susceptible d’évoluer à chaque intervention sur le code source : un contrôle à chaque livraison est recommandé pour les applicatifs particulièrement sensibles.
Ce type d’audit est particulièrement utile dans le cadre de développements externalisés, qu’il s’agisse de nouveaux projets ou de tierce maintenance applicative. Dans ce type de situation, il peut être utile de s’équiper d’une solution adaptée, le choix dépendant du périmètre ciblé (progiciels, développements sur mesure) et des langages de développement utilisés.
Qui est concerné ?
Un processus d’audit de code implique différents acteurs, parmi lesquels on peut distinguer deux grandes catégories : les équipes de développement d’une part, les décideurs d’autre part. Les développeurs sont au premier rang, qu’il s’agisse d’équipes internes ou de prestataires. La conduite du changement est particulièrement importante avec les équipes internes, ne serait-ce que pour éviter un sentiment de « flicage ».
Il est essentiel d’être transparent, d’expliquer et d’afficher clairement les règles à suivre, voire de mettre en place des outils pour aider les équipes de développement à mettre en œuvre ces bonnes pratiques. Mieux, les développeurs eux-mêmes peuvent être impliqués dans le choix des règles à mettre en œuvre.
L’un des buts à terme étant de faciliter leur travail, mieux vaut privilégier au départ quelques règles bien choisies et avancer progressivement que de surcharger d’emblée les équipes avec des dizaines de règles contraignantes. Enfin, il est nécessaire de leur fournir tous les indicateurs nécessaires pour qu’ils puissent vérifier par eux-mêmes leur code.
Avec les prestataires, la transparence est également de mise, étant primordiale pour entretenir de bonnes relations. Il est fort souhaitable de prévenir ses sous-traitants de la mise en place d’un système d’audit, ainsi que des conditions prévues pour ces audits.
Dates/périodicité et règles d’analyse, seuils en deçà desquels la qualité est considérée comme insuffisante sont autant d’éléments qui doivent figurer clairement dans les contrats. De la même façon, les résultats des audits doivent être fournis aux prestataires. Par ailleurs, nombre de sociétés de services sont elles-mêmes équipées d’outils d’audit.
Elles peuvent donc plus aisément contrôler leurs livraisons si les clients leur indiquent précisément leurs standards de qualité.
Du côté des décideurs, les managers informatiques et la direction des systèmes d’information sont les premiers destinataires des indicateurs agrégés remontés par les solutions.
Les chefs de projet s’en serviront principalement pour gérer leurs équipes et optimiser les compétences, identifiant par exemple des personnes maîtrisant bien les règles de syntaxe en vigueur pour former les nouveaux arrivants. La DSI pourra quant à elle prendre des décisions sur ses applications en fonction de leur niveau de qualité : externalisation, refonte prioritaire, abandon, etc.
Si les décideurs de l’informatique sont les principaux consommateurs des résultats de l’audit, il ne faut pas pour autant négliger les autres : directions métiers, voire direction générale, peuvent être destinataires d’informations sur la qualité applicative, à condition que les indicateurs transmis soient adaptés à leurs préoccupations, explicités et traduits en enjeux métiers : capacités des applications à évoluer, coûts de maintenance, etc.
L’objectif est double : les alerter sur d’éventuels risques liés à leurs applicatifs stratégiques et faciliter la communication entre ces directions et la DSI.
En bref
L’audit de code pour…
Faire évoluer facilement ses applications
Des applications bien écrites sont naturellement plus évolutives que celles dont le code source est médiocre.
Contrôler le coût des projets applicatifs
Auditer tout nouveau développement permet d’éviter les dérives et aide à maintenir la qualité du code dans le temps, réduisant ainsi le coût et la durée des projets de maintenance.
Conserver la maîtrise de son patrimoine applicatif
Pour éviter l’effet « boîte noire » sur des applications stratégiques, il faut conserver une visibilité sur le code source.
Gérer la qualité de son patrimoine applicatif : quelques fournisseurs de solutions
La qualimétrie applicative reste un marché de spécialistes, caractérisé par une grande hétérogénéité entre les acteurs et les solutions. Les solutions industrialisées, proposant une vaste palette d’indicateurs, des outils de suivi avancés et supportant plus d’une dizaine d’environnements techniques dans une même plate-forme intégrée sont peu nombreuses. En revanche, il existe une pléthore d’outils plus modestes, dont beaucoup fournis par l’open source, adaptés à des besoins simples ou à des environnements techniquement homogènes, notamment pour la plate-forme Java.
- Plateformes de qualimétrie intégrées : Cast Software (Cast Application Intelligence Platform), Metrixware (System Code), McCabe Software (McCabe IQ)…
- Qualimétrie simple : Hello2morrow (SonarJ), SonarSource, Qalab, XRadar…
- Solutions spécialisées : HP Fortify – RATS (audits de sécurité), Metaware – Refine (modernisation des applications), Microfocus – i.Sight (modernisation des applications)…