IT LA RÉFÉRENCE TECHNIQUE ON-LINE DES PROFESSIONNELS DE L'INFORMATIQUE Activités de test externalisées : 5 conseils pour augmenter les chances de succès Une dette technique ruineuse pour la DSI Ingénierie des Performances : une approche orientée performance pour sécuriser la disponibilité des applications en production Bimestriel - janvier/février 2012 n 95
édito 2012 : une année clé pour votre entreprise? Réseaux sociaux, e-mails, audio-vidéo l explosion des volumes de données et des échanges en ligne repoussent chaque jour les limites nécessaires en infrastructure. Pour tenter d anticiper les besoins, éditeurs et constructeurs se démènent et innovent à grands pas : virtualisations, cloud, stockage, administration d infrastructure De multiples innovations ont pris leur essor en 2011, et secoué considérablement la gestion d infrastructure, ainsi que les modes de ventes des logiciels et du matériel. Fort heureusement, ces évolutions concrétisent généralement les démarches déjà imaginées pour améliorer la qualité et l efficacité des services informatiques (Itil, par exemple). Certes, toutes les entreprises n ont pas atteint le même stade de maturité informatique. Et, la résistance au changement est proportionnelle au degré élevé de remise en cause des pratiques traditionnelles. En outre, le SI existant -souvent pesant et rigide- ne favorise pas l évolutivité. Quoi qu il en soit, les entreprises qui montent dans le train de l innovation (même si elles nécessitent du temps pour implémenter les choses) profiteront d un avantage évident, avec le plus souvent un retour sur investissement appréciable. En 2012, votre entreprise restera-t-elle sur le quai? José Diz Rédacteur en Chef IT LA RÉFÉRENCE TECHNIQUE ON-LINE DES PROFESSIONNELS DE L'INFORMATIQUE Editeur Press & Communication France Une filiale du groupe CAST 3, rue Marcel Allégot 92190 Meudon - FRANCE Tél. : 01 46 90 21 21 Fax. : 01 46 90 21 20 http://www.it-expertise.com Email : redaction@it-expertise.com Rédacteur en chef José Diz Email : j.diz@it-expertise.com Directeur de publication Aurélie Magniez Email : a.magniez@it-expertise.com Conception Graphique Nicolas Herlem Email : nico_freelance@yahoo.fr Parution IT-expert - (ISSN 1961-9855) est un journal édité 6 fois par an, par P&C France, sarl de presse au capital de 60 976,61. Avertissement Tous droits réservés. Toute reproduction intégrale ou partielle des pages publiées dans la présente publication sans l autorisation écrite de l éditeur est interdite, sauf dans les cas prévus par les articles 40 et 41 de la loi du 11 mars 1957. 1996 P&C France. Toutes les marques citées sont des marques déposées. Les vues et opinions présentées dans cette publication sont exprimées par les auteurs à titre personnel et sont sous leur entière et unique responsabilité. Toute opinion, conseil, autre renseignement ou contenu exprimés n engagent pas la responsabilité de Press & Communication. Abonnements 01 46 90 21 21 Dossiers en accès libre : http://www.it-expertise.com/ 2 IT-expert n 95 - janvier/février 2012
IT-expert n 95 - janvier/février 2012 Sommaire 4 Dossier Activités de test externalisées : 5 conseils pour augmenter les chances de succès Après avoir défini les enjeux de l externalisation des tests (en off-shore, near-shore ou sur site), l auteur détaille les tâches et activités de tests et distille ses 5 conseils pour en déterminer le(s) périmètre(s) et mettre en place une méthode de suivi et de collaboration, avec des outils adaptés. Des conseils de terrain éprouvés et très utiles. 14 Technique Une dette technique ruineuse pour la DSI Combien coûte la correction de code d une application en production? Selon les choix technologiques, la note s avère plus ou moins salée. Démonstration à l aide de l enquête annuelle menée par l éditeur CAST qui analyse la qualité structurelle de 745 applications issues de 160 sociétés. 24 Actualités Internationales Les informations marquantes d éditeurs, de marchés, d organisme de standardisation, de débats en cours et de tendances 30 Comment ça marche? Ingénierie des Performances : une approche orientée performance pour sécuriser la disponibilité des applications en production Performance et disponibilité des applications sont des objectifs prioritaires pour les DSI. Cependant, ces questions sont généralement soulevées au moment du déploiement. Or, elles devraient être planifiées dès l origine du projet. Explications et approche méthodologique par des spécialistes d Atos. 37 Livres La sécurité dans le cloud Techniques pour une informatique en nuage sécurisée de Vic (J.R.) Winkler et Urbanisation, SOA et BPM - Le point de vue du DSI (4 e édition) de Yves Caseau. IT-expert n 95 - janvier/février 2012 3
ACTIVITÉS DE TEST EXTERNALISÉES : 5 CONSEILS POUR AUGMENTER LES CHANCES DE SUCCÈS Le sujet de la «sous-traitance d activités de test» est présent dans tous les projets de développement informatique, ou presque. Cependant, ce thème est généralement abordé via la question de l Off-shore ou du Near-shore. Certes, la localisation géographique des activités de test revêt une importance à ne pas négliger, vu les spécificités qu elle peut introduire. Toutefois, il peut être aussi très utile de penser à mettre en place des outils ou méthodes simples et efficaces pour augmenter les chances de succès de la sous-traitance dans le domaine du test logiciel. 4 IT-expert n 95 - janvier/février 2012
Dossier Qu entend-on par «externalisation des tests»? Dans le cadre d un projet informatique, le chef de projet sollicite régulièrement des compétences de personnes n appartenant pas à son équipe de projet. Ces «personnes n appartenant pas à l équipe du projet» peuvent appartenir à la même société ou bien à des sociétés externes, travaillant comme sous-traitants de la société porteuse du projet. Elles peuvent appartenir à une entité spécialisée dans un domaine précis ou au contraire être des ressources indépendantes mises à la disposition des projets. Enfin, ces personnes peuvent être localisées dans le même pays que le chef de projet ou dans un pays plus ou moins éloigné. Dans cet article, le mot «externalisé» désignera ce qui n est pas fait pas des personnes intégrées à l équipe du projet. Ceci est valable pour une grande partie des activités liées au développement logiciel, y compris pour les principales activités de test qui peuvent se décliner sur différents niveaux de test. Pour rappel, le syllabus niveau fondation de l ISTQB (International Software Testing Qualifications Board) propose 5 ensembles d activités : Planifier et contrôler Analyser et concevoir Implémenter et exécuter Évaluer les critères de sortie et informer Activités de clôture des tests Ces activités peuvent se décliner sur 4 niveaux de test : Composants Intégration Système Acceptation Sur les gros projets, il est en général judicieux de mettre en place, à un niveau global, une activité de Planification et Contrôle. Planifier Composant 1 Contrôler Contrôler Planifier Analyser et concevoir Implémenter et exécuter Évaluer et informer Clôturer Intégration Système Acceptation Clôturer IT-expert n 95 - janvier/février 2012 5
Il convient ensuite de déterminer si tout peut être sous-traité. Théoriquement, oui. Dans la pratique, certaines tendances se dégagent : les activités de test liées au niveau composant sont souvent portées par l entité en charge des développements correspondants, et se déroulent avant, pendant et après le développement pur et dur. En d autres termes, si le développement d un composant est sous-traité, alors les activités de test associées ont de fortes chances de l être aussi ; les activités de test liées aux niveaux Intégration et Système sont sous-traitées environ une fois sur deux ; les activités de test liées au niveau Acceptation ne sont en général pas sous-traitées, compte tenu des compétences métiers nécessaires, ainsi que de l utilisation de données confidentielles et d environnements techniques complexes et coûteux. Pour les projets suivant une démarche «agile», la situation est différente. Néanmoins, c est un autre sujet! Dans cet article, la notion de «sous-traitance d activités de test» désignera essentiellement les activités appliquées au niveau composant lorsque le développement est sous-traité et les activités mises en œuvre aux niveaux Intégration et système. Un grand projet de transformation dans une grande multinationale Une grande société, présente dans différents pays, fait évoluer son Système d Information (SI) dans le cadre d un vaste projet de transformation. Le SI est constitué d un ensemble d applications couvrant différents domaines techniques ou métiers. Ce projet va donner lieu à l introduction de nouvelles applications et à la modification ou suppression de certaines autres applications, selon les exigences définies par la société porteuse du projet global. Différents sous-traitants se partagent le développement des applications, un sous-traitant étant en charge de plusieurs applications. Un sous-traitant, différent des précédents, est chargé de l ensemble des tests d intégration. Enfin, la société porteuse du projet global est aussi chargée des tests d acceptation. Domaine métier 1 Application 2 Application 14 Application 17 Application 12 Application 8 Plateformes et Réseaux Application 13 Application 1 Application 3 Application 9 Domaine métier 2 Application 16 Application 11 Application 7 Application 15 Application 6 Application 5 Application 10 Application 4 Sous-traitant 1 Sous-traitant 2 Société et un troisième sous-traitant en charge des tests d intégration! 6 IT-expert n 95 - janvier/février 2012
Dossier Conseil n 1 : Mesurer les compétences de chaque sous-traitant et en tirer les conséquences Ceci doit être fait au niveau de l entreprise, mais aussi -et surtout- au niveau des personnes impliquées dans le projet, et ce de manière constructive et factuelle. Une restitution doit être partagée avec le sous-traitant et déboucher, si nécessaire, sur un plan d amélioration suivi de près. Il est en général utile d avoir dans sa boîte à outils des connaissances sur : CMMI (Capability Maturity Model + Integration), TMMI (Test Maturity Model Integration), ISTQB/CFTL (International Software Testing Qualifications Board/Comité Français des Tests Logiciels) pour différentes normes et standards référencés : IEEE 829, IEEE 1044, ISO 9126 Cependant, avant de sortir l artillerie lourde, il est prudent de vérifier que le sous-traitant maîtrise les bases incontournables du test logiciel. Pour cela, un simple questionnaire peut suffire à déceler de vraies lacunes. Par exemple, un sous-traitant qui, à la question «Quel outil utilisez-vous pour gérer les défauts?» répond (comme cela m est arrivé récemment) «Nous utilisons l e-mail et le téléphone» aura à priori un niveau très faible en test logiciel. Il conviendra alors de définir un plan d amélioration pour le sous-traitant et de le suivre pour assurer la mise en place de pratiques incontournables, comme celles indiquées dans l exemple ci-dessous. Description Affecter un Test Manager à temps plein pour les activités de test du Sous-Traitant 1 Apporter la preuve de la couverture du code et des exigences par les tests (mesure et matrice de traçabilité) Revoir les cas de test unitaires du niveau composant Mettre en place un Outil de Gestion des Tests pour les tests 2 à 2 Mettre en place un Outil de Gestion des Anomalies partagé avec les différents sous-traitants Bénéfice attendu Meilleure gestion et efficacité de ses activités de test Disposer de preuves et garanties sur le nombre de tests exécutés et leur couverture Augmenter l efficacité des tests de ce niveau et leur documentation Aller plus vite, faire mieux et avoir une bonne visibilité sur ces tests Mieux gérer les anomalies, avoir de la visibilité sur l avancement de la gestion des défauts Attention : il n est pas acceptable d entendre un sous-traitant en charge du développement d un certain nombre de composants dire «Je suis responsable des développements, vous serez livrés, mais je n ai aucune preuve à vous donner sur les tests que je réalise» Si cela se produit, la séquence de questions suivante doit permettre d aider le sous-traitant à rapidement retrouver le bon sens qu il avait perdu : «Allez-vous me livrer un composant sans l avoir testé?» «Avez-vous réfléchi à la façon de le tester?» «Avez-vous documenté votre stratégie de test?» «Allez-vous exécuter des tests?» «Où ces tests sont-ils décrits?» «Quels sont les résultats de ces tests?» Bien sûr, toute réponse doit s accompagner d un document faisant office de preuve! IT-expert n 95 - janvier/février 2012 7
Conseil n 2 : identifier et définir le plus haut niveau de test Quand une partie des activités de développement et de test est externalisée, il devient plus difficile d avoir une vision globale sur l ensemble des activités de test d un projet. Pourtant, cet aspect est indispensable pour gérer correctement le projet de test et coordonner les activités qui se déroulent aux différents niveaux. La notion de «plan de test maître» («Master Test Plan») telle qu introduite par la norme IEEE 829-2008 prend alors tout son sens. Ce plan de test maître permettra non seulement de définir et contrôler une planification globale de l activité de test sur l ensemble du projet, mais aussi d identifier les différents niveaux de test et les plans de test associés. Pour un composant dont le développement est sous-traité, il conviendra alors de demander au soustraitant, s il est également en charge des tests. Un Plan de Test de niveau Intégration pourra aussi être exigé auprès d un sous-traitant en charge de l intégration. Externaliser une activité de test ne signifie pas «perdre contrôle et visibilité» sur celle-ci. Bien au contraire! Dans l exemple ci-dessous, un «Master Test Plan» a permis de définir une stratégie globale de test pour un projet complexe d évolution d un SI, faisant appel à de nombreux sous-traitants. Par exemple, chaque composant développé a donné lieu à la rédaction d un Plan de Test référencé par le Plan de Test maître. CCCCCCCi Description à haut niveau et pilotage Description détaillée pour chaque niveau BIT R2B Plan de Test OSS BIT R2B Plan de Test BSS DDSI DPS AAAAAAA Niveau Composant FIP S1D0 Master Test Plan BIT R2B Plan de Test Statique OSP Niveau Statique Test Manager global BAS2010 Network and Platform Plan de Test d Intégration DPS BIT R2B IT and IT with Network & Platforms Plan de Test d Intégration MMM Niveau Intégration FIP S1D0 Plan de Test UAT Internal Niveau Acceptation 8 IT-expert n 95 - janvier/février 2012
Conseil n 3 : Généraliser les revues qui sont un outil d une rentabilité exceptionnelle! Qu'est-ce qu une revue? C est tout simplement une «évaluation d un état d un produit ou projet pour déceler des déviations par rapport aux résultats planifiés et recommander des améliorations» [IEEE 1028] Qu est-ce qui peut être revu? Tout ou presque! Cependant, lorsque des activités de développement et de test sont externalisés, les revues présentent un intérêt particulier pour 3 produits qui sont rarement revus : les plans de test les tests les bordereaux de livraison Même si lorsqu un sous-traitant est en charge des tests unitaires du composant qu il développe, revoir le Plan de Test associé permettra d avoir des garanties sur la façon avec laquelle ce composant sera testé. L exemple suivant montre le résultat d une revue effectuée sur 5 plans de test réalisés par un sous-traitant sur la base d un même modèle (template). Chaque ligne correspond à un plan de test et chaque colonne à un chapitre du plan de test. Cette revue a mis en évidence une grande faiblesse concernant le test chez le sous-traitant et a donné immédiatement lieu à un plan d action d amélioration. Qualité des différentes sections des Plans de Test : n Bonne n Moyenne n Faible Revue des Plans de Test Unitaires (chapitre par chapitre) 1.1 INTRODUCTION 1.2 RÉFÉRENCES 2.1 JALONS DU PROJET GLOBAL 2.2 JALONS DU PROJET DE TEST 3 ÉLÉMENTS À TESTER 4 CARACTÈRISTIQUES À TESTER 5 CARACTÈRISTIQUES À NE PAS TESTER 6.1 CRITICITÉ DES CARACTÈRISTIQUES À TESTER 6.2 EFFORT DE TEST 6.3 NIVEAUX DE TEST 6.4 TECHNIQUES DE TEST 6.5 PRIORISATION DE L EXÉCUTION DES TESTS 6.6 AUTOMATISATION DES TESTS 6.7 SUIVI ET CONTRÔLE DE L AVANCEMENT DES TESTS 6.8 GESTION DE CONFIGURATION 6.9 GESTION DES ANOMALIES 6.10 UTILISATION DES OUTILS DE TEST 6.11 RESPECT DE LA QUALITÉ 7. BESOINS EN ENVIRONNEMENTS 8. BESOINS EN RESSOURCES ET FORMATIONS 9.1 RÔLES ET RESPONSABILITÉS 9.2 CONCEPTION DES TESTS 9.3 EXÉCUTION DES TESTS 10. CRITÈRES D ARRÊT ET DE REPRISE DES TESTS 11. LIVRABLES 12. RISQUES ET CONTINGENCES 13. CRITÈRES DE PASSAGE OU ÉCHEC Documents FIM_R2B_Plan Pruebas 2a2_ ACTIVACION_v1.0.doc FIM_R2B_Plan Pruebas 2a2_EAI Fijo_v1.0.doc FIM_R2B_Plan Pruebas 2a2_ FENIX_v1.0.doc FIM_R2B_Plan Pruebas 2a2_ SIAM_v1.0.doc FIM_R2B_Plan Pruebas 2a2_ TIBC05_v1.0.doc Les tests eux-mêmes peuvent aussi être revus. Bien entendu, il conviendra de vérifier que chaque test est associé à une caractéristique à tester (ou exigence), que le format est correct, mais aussi que le test est pertinent. La revue des tests doit être effectuée par des personnes disposant des compétences techniques ou fonctionnelles adéquates. Enfin, la revue des bordereaux de livraison peut également apporter beaucoup. En effet, ce document s avère primordial pour assurer le démarrage de l intégration dans de bonnes conditions. Un composant livré avec un bordereau de livraison incomplet, sans procédure d installation -par exemple, posera des problèmes à l intégration. L idéal serait même d organiser des revues anticipées des bordereaux de livraison. Rien n empêche d exiger d un sous-traitant qu il fournisse une première version de chaque bordereau de livraison une semaine avant la date de livraison finale. Cela permet aux personnes en charge de l intégration de les revoir, de vérifier leur qualité et de demander les corrections nécessaires, sans retarder la livraison! IT-expert n 95 - janvier/février 2012 9
Conseil n 4 : L analyse de code outillée : un outil à utiliser absolument, mais avec maîtrise! L analyse statique de code, à la différence des revues de code classiques faites par des développeurs, est en général réalisée avec un outil de test spécifique. Le principe est simple : le code développé est analysé, sans être exécuté, afin d évaluer sa qualité selon différents critères, bonnes pratiques ou règles de codage. Lorsque les développements sont sous-traités, l utilisation de ce type d outil est précieuse, car elle peut aider le sous-traitant à respecter les règles de développement et les exigences sur la qualité formulées par l entreprise cliente. L outil peut aussi permettre de vérifier la qualité d un code livré avant de l accepter. Toutefois, cet outil doit être bien maîtrisé, car différentes difficultés - nous en verrons deux ci-après - peuvent se présenter. Heureusement, à chaque difficulté correspond en général une solution! Première difficulté : si l utilisation d un tel outil, avec des critères d acceptation de livraison, n a pas été contractualisée avec le sous-traitant, il risque de refuser de modifier son code. L idéal consiste bien sûr à avoir défini les règles du jeu dès le départ et à permettre au sous-traitant d analyser son code au fur et à mesure du développement. Mais si cela n a pas été fait, rien n empêche d analyser le code livré. Il faudra alors considérer 2 types de violations de règles de codage : des règles basiques, incontestables, qui correspondent à l état de l art en matière de développement et qu il n est pas possible de contourner, au risque de mettre en péril le système dans lequel le code sera intégré. Sur ces règles, il est légitime de se montrer intransigeant et d exiger les modifications nécessaires de la part du sous-traitant, sans supplément de coût. des règles propres à l entreprise et à ses objectifs spécifiques en termes de qualité de code. Si ces règles n ont pas été précisées à l avance, il sera sans doute nécessaire d établir un avenant et d accorder des jours supplémentaires au sous-traitant pour les appliquer. Deuxième difficulté : le sous-traitant est chargé de faire évoluer un code existant pour ajouter, supprimer ou modifier des fonctionnalités. Il faudra bien sûr veiller à faire la distinction entre le code d origine et le nouveau code, mais cela ne suffit pas. En effet, faire évoluer un code qui ne respecte pas des règles de codage contraint souvent à rester dans le non-respect des règles. Par exemple, faire évoluer une fonction, ayant un nombre trop important de lignes de code ou un nombre insuffisant de commentaires ne permettra pas de respecter les règles relatives à la taille d une fonction et aux commentaires attendus. Dans ce cas il est conseillé de coopérer intelligemment avec le sous-traitant, d une part, pour fixer des objectifs réalistes sur une partie de ses développements ; d autre part, pour envisager la réécriture d une partie du code. Bien sûr, cela a un prix, comme tous les aspects contribuant à l amélioration de la qualité! Un outil comme CAST attribue une note globale sur la qualité du code analysé, mais également plusieurs vues aussi détaillées que souhaité, pour voir précisément quelles règles ne sont pas respectées et à quel endroit! 10 IT-expert n 95 - janvier/février 2012
Dossier Note globale Un exemple de vue détaillée IT-expert n 95 - janvier/février 2012 11
Conseil n 5 : Construire une relation de confiance avec le sous-traitant Cela va de soi, mais il est important de le rappeler : le moyen le plus efficace de travailler avec des sous-traitants, dans le domaine du test, mais aussi pour l ensemble des activités du développement logiciel, est de bâtir une relation de confiance intelligente. Des relations figées sur un contrat défini au début du projet avec des délais, des coûts et des critères d acceptation inflexibles, auront peu de chance de se transformer en succès mutuel. S il est essentiel de contrôler l activité de test des sous-traitants, il est tout aussi primordial de leur préciser des attentes et de les aider à les respecter. Être ferme mais coopérant! Cela peut, et doit même, se traduire par des échanges réguliers qui prendront la forme de réunions de suivi entre tous les acteurs, mais aussi de visites dans les locaux du sous-traitant. Établir un contact et dialoguer de temps en temps avec les équipes du sous-traitant pourront montrer aux personnes impliquées, manager ou «petites mains», qu ils travaillent pour un client qui a un visage et qui compte sur la qualité de leur travail. Lorsque plusieurs sous-traitants sont impliqués dans un grand projet, il est également très utile de les rassembler pour arbitrer les choix et gérer au mieux les difficultés et conflits éventuels entre sous-traitants. Au-delà des points de vigilance classiques mis en œuvre lorsque certaines activités de test sont externalisées, il existe des moyens simples et efficaces à appliquer pour augmenter les chances de succès de l externalisation. n Eric Riou du Cosquer, Trésorier du CFTL (Comité Français des Tests Logiciels) Secrétaire de l ISTQB, Test Manager Senior chez France Télécom Diplômé de l Ecole d Ingénieurs de Brest (Informatique Industrielle), Eric Riou du Cosquer a commencé sa carrière en 2000, en qualité de Chef de Projet au sein des sociétés CSC PeatMarwick, puis Softeam de 2000 à 2003, avant de rejoindre la division R&D de France Télécom. Depuis 2007, Eric exerce en qualité de Consultant et Formateur sur l ensemble du groupe France Télécom, en France et à l étranger. Il participe également à l amélioration continue des processus et pratiques de test et est amené à conduire des audits internes ou externes pour différentes divisions de France Télécom. Depuis 2002, il a dispensé plusieurs conférences et formations dans le domaine des tests de logiciels. En tant qu expert, Eric Riou du Cosquer est également membre du groupe de travail international pour la définition du Syllabus Avancé de l ISTQB, Responsable de la création de la version française et fût Président du Club utilisateurs de Mercury France, de 2008 à 2011. Site web : www.cftl.fr Email : tresorier@cftl.net 12 IT-expert n 95 - janvier/février 2012
IDC, filiale du leader mondial du conseil, et des études dans les technologies de l information. Dans un contexte de budgets sous tension et de récession rampante, les entreprises françaises ne cessent de relever leur niveau d exigence vis-à-vis de la DSI. IDC vous donne rendez-vous mercredi 14 mars 2012 (9h 15h00), à Paris, pour participer à la conférence «Gouvernance IT : la DSI exemplaire» http://www.idc.com/france/gouvit2012 Cette conférence se focalisera, à l aide de partages d expériences récentes, sur les axes de progrès suivants : Quelles approches et indicateurs pour rendre compte de la bonne gestion de la DSI et valoriser sa contribution à la performance et à l innovation de l entreprise? Comment construire des contrats de services toujours plus en phase avec les attentes des métiers? Comment opérer des transformations majeures comme la virtualisation des environnements critiques sans remettre en cause les acquis en termes de disponibilité, de fiabilité et de sécurité? Comment gagner en visibilité, en contrôle et en transparence sur les portefeuilles de projets? Comment prioriser et obtenir les arbitrages nécessaires? Comment dégager des marges de manœuvre et du temps disponible pour l innovation métier? Le cabinet IDC vous propose d aborder en trois temps l ensemble des réalités que couvre cette thématique: Vision IDC gouvernance IT : concilier rationalisation et innovation : quelles approches? Quelles solutions? La DSI exemplaire en période de tension La DSI partenaire des métiers pour innover Avec le témoignage de Jean-Philippe LABILLE, Relations métiers, Gouvernance du Schéma Directeur des SI, Sous-Direction des Systèmes d Information au Ministère de la culture Programme détaillé et inscription gratuite : http://www.idc.com/france/gouvit2012 Code invitation : ITX Contact : Valérie Rolland vrolland@idc.com tel : 01.56.26.26.85 Cette conférence gratuite est uniquement réservée aux entreprises utilisatrices. Conférence organisée par
Une dette technique ruineuse pour la DSI Une large part des 70 % du budget IT consacrés à la maintenance concerne la correction du code d applications en production. Souvent plusieurs centaines de milliers d euros. L enquête annuelle de CAST compare la qualité applicative des technologies et langages de 745 applications. 14 IT-expert n 95 - janvier/février 2012
Technique La notion de dette technique fait référence au coût nécessaire à l entreprise qui doit remédier aux défauts cachés de ses applications en production. Du moins, à ceux qui représentent un risque ou une menace pour l application concernée, et donc un impact négatif pour les activités de l entreprise dont elle contribue au fonctionnement. Cette dette technique s avère d autant plus dommageable qu elle est rarement budgétée, ou qu elle dépasse généralement les réserves financières estimées par les entreprises les plus prudentes. En 2010, de grandes affaires liées à une dette technique ont défrayé la chronique informatique : Toyota, Sony ou encore RIM, le constructeur du BlackBerry qui a plongé ses utilisateurs dans la nuit numérique pendant de longues heures Autant d exemples qui illustrent la réalité du phénomène. Dans son étude annuelle CRASH Report (pour CAST Report on Application Software Health), l éditeur CAST (leader mondial de l analyse et de la mesure des applications) explique le rôle majeur de la qualité et se propose de poser une «base objective et empirique pour discuter de la qualité structurelle des applications, c'est-à-dire dans quelle mesure les applications souffrent des défauts qui jalonnent leur code». «Les problèmes que nous avons remontés auraient dû être traités avant la mise en production. C est comparable au fait d ignorer les termites qui détruisent la charpente de votre maison» explique le Dr Bill Curtis, directeur scientifique, vice-président du centre de recherche de CAST et directeur du consortium pour la qualité logicielle (CISQ). Un trou de plusieurs milliards de dollars Première mondiale, l étude s appuie sur l analyse automatisée de la qualité structurelle de 745 applications issues de 160 sociétés dans 10 secteurs d activité. Pour un total de 365 millions de lignes de code! Une analyse visant à évaluer ces applications selon 5 facteurs : la sécurité, la performance, la robustesse, la «transférabilité» et l évolutivité (capacité à être modifié). Objectif : mettre en relief les problèmes générant les plus gros risques pour les directions fonctionnelles (ou métier). L estimation prudente des auteurs de l étude ramène la dette technique à 3,61 dollars par ligne de code. 24 % des 745 applications concernées comptent moins de 50 000 lignes de code, 33 % entre 50 000 et 200 000 lignes de code, 31 % en contiennent de 201 000 à 1000 000, et 12 % affichent plus d un million de lignes de code! Les applications Java-EE représentent 46 % de cet échantillon, tandis que.net, ABAP (Advanced Business Application Programming, langage de SAP) COBOL, et Oracle Forms sont représentés à hauteur de 7 % à 11 %. Cobol reste le plus sûr et.net le moins IT-expert n 95 - janvier/février 2012 15
Certes, toutes les applications ne sont pas critiques. Néanmoins, elles contribuent généralement toutes à des processus dont plusieurs aspects sont stratégiques pour l entreprise. C est pourquoi le volet sécurité se révèle primordial. Les applications Cobol tant décriées voire moquées, restent cependant les plus sécurisées, et de loin. Un résultat rassurant, car nombre d applications majeures et fortement transactionnelles sont écrites dans ce langage, dont les experts se font de plus en plus rares. Et l étude précise justement que les applications financières et des assureurs sont les mieux notées sur l aspect sécurité. Un constat logique, puisque la plupart de ces programmes est exécutée dans des environnements mainframe, plus fermés et hautement sécurisés. Les auteurs précisent que ces applications, souvent les plus anciennes, bénéficient pleinement d un historique en sécurité qui les a aussi rendus plus fiables. Les applications développées en.net ou Visual Basic enregistrent les plus faibles scores. Longtemps réservés à des applications moins stratégiques, ces technologies (et surtout.net) gèrent aujourd hui des applications critiques. Espérons que les responsables de ces projets se montreront plus vigilants sur tous ces aspects. Une tendance qui doit certainement se dégager aujourd hui face aux obligations de conformité réglementaire, et qui explique certainement qu une partie de ces applications obtiennent un score plus élevé. Autre constat intéressant, si l on examine la sécurité des applications par secteur d activité, les services financiers et la grande distribution arrivent en tête, tandis que le consulting informatique arrive bon dernier! L étude explique cela par le fait que les prestataires informatiques, hébergeur ou outsourcers, ont hérité d applications dont d autres entreprises leur ont confié la maintenance et l évolution. Or, ces dernières ont souvent été développées sans réelle stratégie et de sécurité et à une époque où les bonnes pratiques en la matière restaient encore confidentielles. Bref : ils ont accepté de prendre en charge la patate chaude 16 IT-expert n 95 - janvier/février 2012