Ce me semble être un des secrets les mieux gardés du moment en informatique : nous opérons souvent sur un paradigme qui est faux en utilisant la métaphore de l’usine et de la production « industrielle ».

A quoi bon des métaphores ?

De nos jours, la métaphore la plus fréquemment utilisée pour désigner une organisation en charge de développement logiciel est celle d’une usine, ou software factory en bon franglais. Nous parlons également de spécification et de conception de logiciel, laissant entendre que le reste n’est plus une tâche de création, qu’il n’y a plus qu’à faire comme c’est prévu, à suivre le plan de fabrication.

Ainsi, avec l’arrivée des concepts issus du Lean Management, nous sommes tentés d’utiliser de plus en plus des méthodes et outils organisationnels issues des chaînes d’assemblage – et il n’y aurait plus qu’à assembler des composants prédéfinis, réutilisables, et tous nos soucis seraient résolus. Nous pourrions donc nous inspirer des méthodes utilisées pour monter des voitures ou des ordinateurs, et plus de projets en retard, plus de besoins métier inassouvis ! Cette métaphore a remplacé celle de la construction de bâtiment et de ponts – je ne suis pas trop sûr de savoir pourquoi, d’ailleurs. Peut-être la précédente n’était-elle pas suffisamment fertile en concepts associés permettant de guider nos organisations informatiques, ou peut-être s’est-on rendu compte que la métaphore ne fonctionnait pas.

Oui, mais quel est le problème ?

La question est liée à l’utilité d’une métaphore. Une métaphore est bonne et utile si elle « fonctionne » et inspire par analogies de nouvelles idées, démarches, concepts, analyses, etc. par un rapprochement de domaines distincts. Une bonne métaphore donne des outils pour imaginer et décider, par jeu d’analogies. Par exemple, la fenêtre est une métaphore pratique pour l’espace d’interaction avec une application informatique, parce qu’elle permet d’imaginer l’accès à des « domaines » différents, de voir ce qui se passe dans ces « zones ». Elle permet d’imaginer de l’ouvrir, de la fermer, d’attacher un contexte mental à une fenêtre. La métaphore touche à ses limites lorsqu’on parle de superposer plusieurs fenêtres, ce qu’on ne peut pas avec des vraies fenêtres dans des murs….

Ou alors, un pont peut être une bonne métaphore pour une interface applicative: il permet de faire passer des objets (métaphores pour les données) d’un côté à l’autre; il est une construction particulière, supplémentaire, nécessitant un effort; il faut se mettre d’accord sur le point de départ et d’arrivée. Par contre, il ne représente qu’une interface point à point, et ne permet pas d’imaginer de réutiliser des interfaces pour faire des services partagés.

Nous voyons donc qu’une métaphore peut être utile, mais peut également avoir des limites, et il faut dans ce cas en être conscient pour l’utiliser correctement. Une métaphore peut être complètement nocive si la plupart des décisions que l’on prend en l’utilisant ne sont pas pertinentes- ou encore si elle amène naturellement à prendre des décisions « évidentes » dans le contexte de la métaphore mais qui en fait sont nuisibles.

Imaginons par exemple un chef de projet informatique qui a un problème de retard prévu sur les livraisons. Dans les usines, pour augmenter rapidement la quantité produite, on fait des heures supplémentaires. Le chef de projet utilise la métaphore de l’usine et la pense pertinente. Il demande donc à ses développeurs de venir travailler le samedi. Sauf qu’en l’occurrence le problème n’était pas sur la quantité produite, mais sur la clarté du besoin et les arbitrages associés. Le résultat est que les développeurs ont produit plus, mais plus de choses non conformes aux attentes. Du coup il y a plus de corrections à apporter sur la base de retours utilisateurs, et le « retard » augmente !

Pourquoi la métaphore de l’usine est-elle un mauvais guide ?

Mon propos aujourd’hui est donc d’affirmer que cette nouvelle métaphore de l’usine appliquée au développement de logiciel est fausse, incorrecte. Complètement et tout simplement. Et elle n’a jamais été même proche de la réalité. Et donc les analogies et orientations que nous pourrions prendre en nous appuyant sur cette métaphore seront au mieux hasardeuses, au pire nocives.

Comparons les modèles d’usine de fabrication et de développement logiciel:

Ces quelques critères de comparaison font apparaître des obstacles à une transposition directe de méthodes issues de la fabrication d’objets physique au développement de logiciel, et donc autant de faiblesses de l’application de la métaphore de l’usine dans le domaine informatique.

Pouvons-nous illustrer ce propos ?

En synthèse, pourquoi cette métaphore ne fonctionne-t-elle pas ?

En fait, le développement d’un logiciel, au sens très large, incluant l’analyse du besoin, conception technique, conception fonctionnelle, le développement lui-même, les tests et la mise en production, tout ceci est une activité de conception de produit et pas de fabrication. Le produit en question est un produit logiciel, qui vise à satisfaire un certain besoin, à couvrir un certain « marché », bien souvent à usage unique comme les logiciels d’entreprise, ou au moins dont la duplication se fait rapidement et sans difficulté particulière, comme les logiciels grand public. Cette conception est d’abord génération d’information, et non pas mouvement d’atomes, et c’est elle qui crée la quasi-totalité de la valeur du produit logiciel.

Pourquoi essayons-nous néanmoins d’appliquer les modèles de fabrication issus de l’industrie ?

Souvent, cette application de modèles issus de l’industrie se fait dans un objectif de rationalisation et d’amélioration d’efficacité. Les projets informatiques ne vont pas bien, et/ou coûtent trop cher, et nous cherchons donc des solutions issues de domaines où les activités tournent mieux, où elles sont prévisibles et répétables – plus rassurantes donc. Nous cherchons aussi les (objectivement impressionnantes) économies d’échelle et gains (réels) d’efficacité que la production industrielle a permis, et que nous n’avons pas atteints dans le logiciel. Un regard très – trop – rapide sur le développement logiciel fait apparaître des zones « d’amateurisme », que l’on va s’empresser de corriger en demandant un fonctionnement plus « professionnel », plus « industriel ».

Mais tout ceci est illusion. Reprendre les mots et les pratiques de la fabrication en série ne permet pas de mieux « fabriquer » du logiciel « en série ».

Que faire alors ?

Est-ce une bonne ou une mauvaise nouvelle ? Les deux. La mauvaise est que nous allons devoir changer nos métaphores, ce qui va entraîner un changement dans l’espace des solutions et des outils. La bonne est que nous allons pouvoir nous tourner vers des espaces sémantiques nouveaux et une littérature différente pour nous inspirer dans la compréhension de nos processus et la recherche de pistes d’amélioration. Nous pouvons par exemple nous inspirer des méthodes et démarches de conception de produit utilisées dans l’industrie, comme décrit dans Managing the Design Factory, et nous découvrons que les problématiques, les enjeux, et même certaines des solutions et outils utilisées peuvent réellement nous aider à mieux comprendre et gérer nos systèmes d’information.

Les constructeurs automobiles savent que la conception de nouveaux modèles de voiture n’est pas un processus de fabrication « industriel », sur lequel on peut adapter les métaphores d’une usine. Ma réponse à la question du titre est donc: oui, changeons, inspirons-nous de leurs pratiques et d’autres, mais des bonnes, sans copie servile mais en transposant avec pertinence.

Suggestion d'articles :

1. Des rituels pour changer
2. Changer c’est aussi ne pas vouloir changer
3. Ce que la science nous dit de la colocalisation

La conduite du changement est une activité récurrente dans notre métier, et l’un des quatre thèmes fondamentaux du savoir chez OCTO Technology. C’est aussi accessoirement un sujet vital et je l’espère bientôt central pour notre société, notre pays,  notre civilisation.

Une définition du changement : Changer, c’est changer les lois implicites ou explicites qui régissent une organisation.

De nombreux auteurs ont prédit que la démocratisation des moyens de communication allait entraîner des changements majeurs dans nos sociétés, comme la participation de chacun au contrôle de l’économie et de l’écologie.
Bien que la première partie des prédictions se soient avérées justes, nous n’observons pas encore d’effet majeur permettant d’être optimiste concernant l’avenir de notre écosystème, ou de notre économie.
Pourquoi, alors que l’on nous a annoncé de profondes mutations de notre civilisation eut égard à la démocratisation des nouvelles technologies de l’information, on ne constate pas de modification structurelle et durable des lois implicites ou explicites qui régissent nos entreprises, notre civilisation ?

Je vous propose d’explorer cette question en traitant les points suivants :

• La prédiction s’est en partie réalisée
  • Le web permet la diffusion gratuite, l’information de masse
  • L’open source et le web 2.0( que l’on peut regrouper sous le terme Open Web) permet la collaboration de masse
• Alors que manque-t-il pour que se produise un changement rapide et massif ?
  • De la solution aux faits il y a la légitimité et la contrainte
  • « Observons la nouveauté dans les nouvelles » ( Michel Serres)
  • La décision de masse
• Dynamocracy

Prédiction

Joël de Rosnay dans Le macroscope en 1975 décrit le Web, pressent le Web 2.0, et annonce un changement majeur dans la gouvernance de nos sociétés. Ce changement est ensuite expliqué et annoncé à nouveau dans La révolte du pronétariat, dont voici les premières lignes :

« Les citoyens du monde sont en train d’inventer une nouvelle démocratie. Non pas une « e-démo-cratie », caractérisée par le vote à distance via Internet, mais une vraie démocratie de la communication. Cette nouvelle démocratie, qui s’appuie sur les « média des masses », émerge spontanément, dynamisée par les dernières technologies de l’infor-mation et de la communication auxquelles sont associés de nouveaux modèles économiques. Ni les média traditionnels, ni les hommes politiques n’en comprennent véritablement les enjeux. Les média des masses, seuls véritables média démocratiques, vont radicalement modifier la relation entre le politique et le citoyen, et, par voie de conséquence, avoir des impacts considérables dans les champs culturel, social et politique. Les internautes commencent seulement à réaliser à quel point le Net du futur va leur permettre d’exercer leur pouvoir, si tant est qu’ils parviennent à se montrer solidaires et organisés. »

Voici que l’Histoire lui donne raison :

• Le web en 1989 permet à chacun de diffuser massivement de l’information pour un prix dérisoire.
• En 1998 le concept d’open source, puis le Web 2.0, permettent de bâtir collectivement des oeuvres colossales comme Wikipedia ou Linux.
• Depuis 2005, de nombreux auteurs soulignent l’importance et l’opportunité que représentent ces nouveaux outils pour l’humanité.

Deux phénomènes importants, nommés parfois révolutions, sont en effet observables : d’une part les informations et les idées de rupture sont désormais rendues disponibles par tous et pour tous, immédiatement. D’autre part une nouvelle manière de produire des informations structurées, par une multitude et sans gouvernance, est née.

Alors pourquoi ces nouvelles capacités ne produisent-elles pas de changements à la mesure des défis auxquels nous sommes collectivement confrontés  :

• Écologie, économie, santé pour nos civilisations
• Innovation, mondialisation, durabilité pour nos entreprises.

De la solution aux faits, la légitimité et la contrainte

Ces nouvelles capacités permettent pourtant d’identifier les problèmes, de diffuser l’information disponible à leur résolution, et de construire collectivement des solutions.
Que manque-il pour que ces solutions, parfois déjà disponibles, s’exécutent dans la réalité?
L’obtention d’un changement est conditionné par le choix d’une solution parmi les solutions disponibles pour un problème identifié. L’efficacité du choix, c’est à dire son application effective dans la réalité, est conditionnée par deux facteurs : le consentement issu de sa légitimité et/ou la contrainte.
La légitimité est la qualité de ce qui est fondé en droit, en justice, ou en équité. La contrainte est exercée par le pouvoir sur le groupe.

« Observons la nouveauté dans les nouvelles » (Michel Serres)

Imaginons que ces nouvelles technologies permettent de produire collectivement non plus seulement de la mémoire, des nouvelles, ou des logiciels, mais de la décision et de l’action.
Est-il raisonnable de penser qu’un outil pourrait produire une décision massivement collective? Est-il raisonnable de penser qu’un tel outil pourrait produire des décisions ayant une très forte légitimité, et donc très efficaces en termes de changement ?
Observons qu’il n’y a pas de sanction à ne pas noter un produit d’Amazon, à ne pas produire de page Wikipedia, ou à ne pas Twitter. Pas de récompense tangible non plus pour les noteurs, contributeurs, ou twitters anonymes ou masqués.
Le principal moteur de cette production est la légitimité. On participe à la production parce que l’on pense que notre contribution est légitime, que l’on a sa part d’universalité.
Observons par ailleurs que si l’on consomme massivement cette production, c’est précisément parce qu’elle s’avère légitime.
Ce n’est pas la contrainte qui me fait chercher dans Wikipedia plutôt que dans Britanica, Twitter plutôt que le 20h, Amazon plutôt que le guide littéraire. Ma motivation première est la légitimité des produits de ces outils.
On peut s’interroger sur ce qui confère la légitimité aux produits de ces outils. Mon intuition est que la réponse se trouve dans le processus de production induit par l’outil. C’est parce que je sais que toute page de Wikipedia est susceptible d’être modifiée par toute personne ayant une réponse qui lui parait plus légitime que celle présente, et qu’elle arrive cependant dans un état stable, c’est à dire qu’elle fait consensus, que j’imagine que c’est la plus proche d’une vérité universelle sur un sujet. C’est parce que je sais que chacun est libre de re-Twitter l’information qui lui semble importante, que les nouvelles les plus twittées me paraissent comme universellement les plus importantes à cet instant.
C’est donc le processus de production induit par les outils collaboratifs qui permettent de construire un produit massivement légitime.
Alors peut-on imaginer construire un plan d’action, une règle, massivement, comme on le fait pour des classements, de la mémoire, ou des nouvelles?

Dynamocracy

Il n’y a pas d’outil informatique simple permettant de produire massivement des plans d’action ou des règles. Les technologies permettent très largement de construire un tel outil, et il existe déjà des outils permettant de prendre des décisions dans un domaine étroit.

Dynamocracy est un projet visant à définir, construire, promouvoir et diffuser au plus grand nombre un outil ouvert de décision de masse.

Fort de cette nouvelle information, le groupe ayant légitimé telle action ou telle règle, peut on s’attendre à observer une modification des comportements?

J’avais de nombreux exemples plutôt orientés autour de l’écologie, mais l’actualité nous propose un cas d’école : la votation de la poste. Notons en premier lieu que le fait ne passe pas inaperçu puisque les grands médias traditionnels en ont fait les gros titres. Notons ensuite que cette votation souffre d’être contestable, tant sur le fond, c’est à dire sur la question posée, que sur la forme.

Est ce qu’un outil permettrait l’incontestabilité de la décision, sa légitimité?

• Sur le fond, « il suffirait » que l’outil soit ouvert, c’est à dire que n’importe qui puisse proposer des problèmes et des questions. Il devient dès lors très difficile d’argumenter la légitimité de la question posée, et des réponses proposées. Comme nous l’avons vu, de tels systèmes existent pour produire des encyclopédies ou des classements. Nous développerons ce point dans un prochain article( Dynamocracy : comment ?)
• Sur la forme, « il suffirait » que la poste ou un autre organisme (l’état par exemple) contrôle l’identité des votants, comme elle le fait de manière légitime pour vos recommandés.

Quelque soit le résultat obtenu par ce type d’outil, qu’il soit en faveur ou non des solutions proposées, il me parait difficile de penser que ces résultats restent sans effets. Il me parait vraisemblable qu’un tel résultat accélèrerait le nécessaire changement, et qu’il constitue un pas important vers une résolution collective de problèmes.

Résumons nous avec trois sigles puisque c’est la mode

• Web 1.0 => Web 2.0 => Web 3.0
• Information de masse => Production de masse => Décision de masse (= action de masse, cette idée sera également développée dans l’article Dynamocracy : comment ?)
• Web => Open-Web=> Dynamocracy

La décision de masse sera probablement bientôt permise par un outil issu des deux dernières révolutions de l’information. Ces décisions de masse constitueraient un puissant vecteur de changement, qui finirait de donner raison à nos penseurs.

Soyons donc optimistes, nous savons faire des outils, et nous allons pouvoir produire collectivement un changement rapide et massif.

MAG

PS : Participer ou suivre l’élaboration de Dynamocracy : mag@dynamocracy.org

Liens

Prédictions

• Paul Otlet - Wikipédia
• The Macroscope: Chap. 4
• La revolte du Pronetariat

Changement

• Changement – Wikipédia
• Changement: Définition universitaire de changement
• Changement: Changement : textes de référence
• Luc de Brabandere à L’USI Les dix paradoxes de la créativité

Le monde meurt

• Proof of climate change ‘unequivocal’
• Troubled waters (the Economist)
• Dailymotion - Home de Yann Arthus-Bertrand – Le Film 1/5 …
• Al Gore on averting climate crisis | Video on TED.com

Révolutions

• Les nouvelles technologies, que nous apportent-elles ? Michel Serres
• Clay Shirky: How social media can make history | Video on TED.com
• The Blogging Revolution: Government in the Age of Web 2.0 E -G ov

• Social software - Wikipedia, the free encyclopedia
• Ning - Wikipedia, the free encyclopedia
• Commons-based peer production - Wikipedia, the free encyclopedia
• Mass collaboration - Wikipedia, the free encyclopedia
• Citizen science - Wikipedia, the free encyclopedia
• Howard Rheingold on collaboration | Video on TED.com
• Lee Smolin on science and democracy | Video on TED.com
• Clay Shirky on institutions vs. collaboration | Video on TED.com
• Seth Godin on the tribes we lead | Video on TED.com
• Charles Leadbeater on innovation | Video on TED.com
• Yochai Benkler on the new open-source economics | Video on TED.com

Outils de masse

• Tech_of_cooperation_map.jpg (Image JPEG, 1944×792 pixels)
• Resources | Cooperation Commons
• en:other_projects [demexp]
• Marko A. Rodriguez
• Enlightened Self-Interest « The Connective
• Inequity aversion – Wikipedia, the free encyclopedia
• Ultimatum game – Wikipedia, the free encyclopedia
• Howard Rheingold on collaboration | Video on TED.com
• Motivating Workers by Giving Them a Vote – WSJ.com

Suggestion d'articles :

1. Pourquoi aucun Wikipedia ne peut aujourd’hui émerger dans l’entreprise ?
2. Pourquoi les méthodes agiles peinent-elles à pénétrer l’entreprise ?
3. Accélération du changement et Dr House

Chaque modèle, norme et corpus de connaissances décrit une partie des activités de l‘entreprise avec un niveau de précision et un niveau de spécificité qui lui est propre. Ils peuvent décrire aussi des activités non présentes au sein de l‘entreprise et omettre certaines activités quant à elles bien présentes. George Box disait « Tous les modèles sont faux ! Certains sont utiles ». Cette citation reprend bien l‘idée que, par définition, un modèle ne peut représenter de manière intégrale la réalité de l‘entreprise. Sa description s‘en approche avec un niveau de précision plus ou moins grand suivant le modèle.

Généralement, on retrouve au sein de deux modèles la description d‘activités communes et des activités spécifiques à chaque modèle. Ces deux types d‘activités peuvent être ou ne pas être en place au sein de l‘entreprise.

En se basant sur ces constatations, je vais vous présenter deux expériences rencontrées:

1. La mise en place d’un référentiel qualité (de processus) unique intégrant les recommandations d’ISO 9001v2000 et CMMI
2. Un audit d’une Direction des études selon différentes vues (CMMI, COBIT et VAL IT)

Le cas CMMI-ISO 9001v2000

Ce cas concerne une SSII française déjà certifiée ISO et souhaitant implémenter les recommandations de CMMI v1.1 (et viser ultérieurement la certification). A première vue, une comparaison haut niveau entre les deux standards donne le résultat suivant:

Analogies

Nous avons commencé par explorer les similarités entre les huit principes de management de la qualité d‘ISO 9001v2000 et CMMI. A priori, ces principes de management de la qualité devraient correspondre aux pratiques génériques de CMMI puisque ces dernières fournissent une base pour l‘institutionnalisation de processus. Voici le résultat de l?exploration :

1. L‘orientation client : ce principe est traité par CMMI à travers la pratique générique GP 2.7 « Identifier et impliquer les parties prenantes » et la pratique spécifique SP 2.6 « Prévoir l‘implication des parties prenantes identifiées » du domaine de processus « Planification du projet ». Ce principe est traité aussi dans les Process Area « Développement Exigences » et « Solution Technique ». Cependant, l‘orientation client est plus fortement représentée dans ISO 9001v200 que dans CMMI ;
2. Le leadership : ce principe est couvert par de nombreuses pratiques génériques de CMMI : GP 2.1 « Établir et maintenir une directive organisationnelle », GP 2.4 « Assigner la responsabilité et l‘autorité » et le GP 2.10 « Passer en revue avec la hiérarchie les activités, le statut et les résultats ». En plus, le domaine de processus OPF « Focalisation de l‘Organisation sur les Processus » couvre des aspects de leadership ;
3. L‘implication du personnel : ce principe est couvert par CMMI à travers l‘implémentation des pratiques génériques GP 2.3 « Fournir les ressources adéquates », GP 2.5 « Former selon les besoins les personnes » et GP 2.7 « Identifier et impliquer les parties prenantes concernées » ;
4. L‘approche processus : ce principe est amplement couvert par les pratiques génériques GP 2.2 « Établir et maintenir le plan » et le GP 3.1 « Établir et maintenir la description d‘un processus ». L‘approche processus est explicitement supportée par les domaines de processus OPD « Définition des Processus de l‘Organisation » et IPM « Gestion de Projet Intégré » et implicitement par le reste des domaines de processus ;
5. La gestion par approche système : ce principe est explicitement couvert par le GP 3.1 « Établir et maintenir la description d‘un processus » ainsi que tous les domaines de processus ;
6. L’amélioration continue : CMMI est un modèle de bonnes pratiques pour l‘amélioration continue. Donc, tout CMMI, spécialement avec ses niveaux de maturité, fournit une base pour réaliser ce principe ;
7. L’approche factuelle pour la prise de décision : CMMI supporte ce principe à travers les pratiques génériques GP 2.8 « Surveiller et contrôler le processus » et à travers de nombreux domaines de processus et spécialement les domaines de processus PMC « Maîtrise et suivi de projet », MA « Analyses et mesures », IPM « Gestion de Projet Intégré » et DAR « Résolution et Analyse pour Décision » ;
8. Les relations mutuellement bénéficiaires avec les fournisseurs : CMMI couvre la relation avec les fournisseurs spécialement à travers le domaine de processus SAM « Gestion des ententes avec les fournisseurs », du point de vue commande plutôt que du point de vue collaboration.

Différences

La différence majeure entre ces deux standards réside dans leurs langages. Tandis que les recommandations d‘ISO 9001v2000 sont clairement prescriptives, CMMI ne liste pas ses recommandations en utilisant l‘impératif. Par exemple, ISO 9001v2000 spécifie ses recommandations pour le QMS (Quality Management System = Système de Management de la Qualité) sous la forme « L‘organisation doit identifier les processus requis pour le QMS… » alors que la description de la pratique spécifique correspondante de CMMI SP 1.1 (du domaine de processus OPD « Définition des Processus de l‘Organisation ») est « Établir et maintenir l‘ensemble de processus normalisés de l‘organisation » puis continue en énumérant neuf sous-pratiques décrivant les détails requis pour implémenter avec succès cette pratique. Une autre différence majeure réside dans la compacité du langage d‘ISO 9001v2000 qui utilise
des expressions comme « établir et maintenir » ou « déterminer fournir ». Par exemple, pour ISO 9001v2000 la recommandation « L‘organisation doit déterminer et fournir… » définit deux actions différentes : d‘abord déterminer les ressources puis fournir ces mêmes ressources. Pour CMMI, cette recommandations correspond au domaine de processus PP « Planification du Projet » pour la détermination des ressources (« déterminer« ) puis à la pratique générique GP 2.3 « Fournir les ressources adéquates » de tous les domaines de processus pour assurer que les ressources sont disponibles (« fournir« ).

À cause de leur différence de cibles et de buts, la quantité de détails présentée par les deux standards est différente. D‘un côté, CMMI couvre tous les détails nécessaires pour le développement des systèmes complexes. De l‘autre côté, ISO 9001v2000 décrit simplement un ensemble de recommandations nécessaires pour développer des produits de haute qualité et satisfaire les exigences du client. Les détails pour répondre à ces exigences sont laissés à l‘utilisateur, mais pour être conforme à ISO 9001v2000, toutes exigences doivent être satisfaites.

La possibilité de combiner ISO 9001v2000 et CMMI

En se basant sur la comparaison précédente, le modèle CMMI et la norme ISO 9001v2000 sont non seulement compatibles, mais aussi complémentaires.Le modèle CMMI et le standard ISO 9001v2000, sont tous deux basés sur une approche processus. Cependant, du fait de leur historique différent, quelques différences majeures doivent être relevées :

1. Le modèle CMMI est applicable dans un contexte de développement d‘applications et de systèmes logiciels, alors que le domaine d‘application du standard ISO 9001 couvre tous les secteurs d‘une entreprise, parmi lesquels le développement logiciel. Par contre, le modèle CMMI identifie les pratiques opérationnelles à mettre en oeuvre dans son domaine d‘application, contrairement au standard ISO 9001 où l‘on se limite à la définition des principes de gestion du système qualité.
2. Les pratiques de gestion de système qualité au niveau société telles que requises par le standard ISO 9001 ne sont reprises dans le modèle CMMI qu‘au niveau 3. Ceci s‘explique par le fait que, dans le modèle CMMI, la mise en oeuvre opérationnelle des pratiques de développement sur les projets prime sur la définition d‘un système qualité applicable à tous les développements de l‘organisation.
3. Du fait de son domaine d‘application plus large, le standard ISO 9001 reprend des pratiques annexes aux développements de logiciel, mais « oubliées » par le CMMI. Notons par exemple le manque d‘attention par rapport aux clients, aux équipements d‘infrastructure et au contrôle des équipements de mesure.

Ceci étant, la certification ISO 9001v2000 d‘une entreprise ayant atteint le niveau 3 CMMI engendrera moins d‘efforts et aucune modification majeure de son système qualité ; en effet, les pratiques opérationnelles préconisées par le CMMI répondent en grande partie à l‘ISO 9001v2000 en matière d‘amélioration continue des processus et de définition d‘objectifs en matière de qualité. Par ailleurs, les acquis du programme d‘amélioration basé sur le CMMI ne seront nullement remis en question par la certification ISO 9001v2000. En dépit de priorités différentes (le standard ISO 9001 requiert d‘abord un système qualité défini au niveau de l‘entreprise, alors que le modèle CMMI se concentre d‘abord sur la mise en oeuvre des bonnes pratiques au niveau des projets de développement) les pratiques de développement logiciel du modèle CMMI des niveaux 2 et 3 constituent une base idéale pour la certification ISO 9001v2000 : l‘effort requis pour la certification des entreprises ayant atteint le niveau 3 CMMI restera réduit.

La mise en place du référentiel

La première étape a été la définition d’un mapping entre ISO 9001v2000 et CMMI.

Il est toujours difficile de déterminer la granularité appropriée pour réaliser un « mapping » entre deux modèles. D‘un côté, un « mapping » haut niveau peut ne pas fournir assez d‘informations sur les similitudes et les différences. D‘un autre côté, un « mapping » de très bas niveau peut engendrer un nombre très important de connexions entre les deux modèles rendant la correspondance très complexe.

Le « mapping » que nous avons réalisé est un compromis entre les deux niveaux (très haut niveau et très bas niveau). On a effectué un « mapping » de chaque chapitre d‘ISO 9001v2000 vers une pratique (ou plusieurs) de CMMI et vice versa. Chaque relation est spécifiée avec un niveau de corrélation (fort, moyen ou faible). Le « mapping » ainsi réalisé sert comme indicateur de correspondance permettant une implémentation des deux standards.

La deuxième étape a été d’utiliser ce mapping afin de compléter le référentiel ISO existant en implémentant les pratiques CMMI complémentaires. Ces pratiques CMMI complémentaires sont de 2 catégrories:

• Non existantes dans le mapping, donc pas de correspondance avec ISO;
• Ayant un niveau de corrélation faible ou moyen.

Le référentiel ainsi réalisé a été auto-audité et il était conforme aux recommandations des niveaux de maturité 2 et 3 de CMMI.

Le cas CMMI-COBIT-VAL IT

Ce cas a été initié à la demande d’une assurance afin d’étudier le niveau de performance de sa direction des études. Le niveau de performance a été mesuré sur différents niveaux (correspondants à des vues différentes d’une direction des études) :

1. Ingénierie logicielle : Dans ce cadre, nous avons utilisé un questionnaire CMMI (issu du document présenté plus haut) afin de réaliser un diagnostic des pratiques de gestion de projet et d’ingénierie avec identification des points forts et à améliorer;
2. Gouvernance des projets : Pour cela, nous nous sommes basés sur le référentiel COBIT pour l’évaluation;
3. Gestion du portefeuille projets : Cet audit s’est basé sur VAL IT.

Ce cas montre la complémentarité entre les différents référentiels utilisés en fournissant des vues différentes d’une direction des études.

Suggestion d'articles :

1. Autres standards de gestion des processus IT
2. La gestion des processus IT
3. Synergies entre CMMI et les Méthodes Agiles

PMBoK : Project Management Body of Knowledge

Le Project Management Body of Knowledge, ou PMBoK, est un standard international élaboré par le PMI (Project Management Institute) qui décrit l‘ensemble des pratiques et des techniques avancées intervenant dans le management d‘un projet (corpus de connaissances). Il fournit un référentiel commun avec une terminologie claire et précise des phases, livrables et compétences nécessaires au chef de projet. Tous les aspects du management de projet y sont traités avec une approche  » process  » qui permet de systématiser les meilleures pratiques et donc de s‘améliorer en permanence.

Le PMI a catégorisé les groupes de processus en cinq groupes cohérents :

• Démarrage ;
• Planification ;
• Réalisation ;
• Contrôle ;
• Clôture.

Comme le montre la figure, ces groupes de processus, qui se répètent dans chacune des phases du projet, s‘avèrent critiques pour s‘assurer qu‘aucune étape n‘est involontairement oubliée. De même, les disciplines que le chef de projet sera amené à maîtriser sont divisées en neuf domaines de Management :

• management de l‘intégration du projet ;
• management du contenu du projet ;
• management des délais du projet ;
• management des coûts du projet ;
• management de la qualité du projet ;
• management des ressources humaines du projet ;
• management de la communication du projet ;
• management des risques du projet ;
• management des approvisionnements du projet.

Le PMBoK s‘intègre parfaitement dans une démarche d‘amélioration continue des processus basée sur une approche CMMI ou ISO 9001 en proposant des pratiques éprouvées issues de l‘expérience de plus de 90000 personnes travaillant ensemble au sein du PMI dans plus de 100 pays.

Le PMBoK sert également de support à la certification de chef de projet PMP (Project Management Professional) actuellement décernée à 44000 personnes à travers le monde par le PMI.

SWEBoK : SoftWare Engineering Body of Knowledge

Version génie logiciel du PMBoK, SWEBoK est un corpus de connaissances en génie logiciel. Ce corpus a été élaboré par l‘IEEE entre 1998 et 2004. La version de 2004 a reçu l‘approbation de  » Industrial Advisory Board  » américain.

L‘IEEE a reconnu 8 disciplines reliées au génie logiciel :

• Computer engineering ;
• Project management ;
• Computer science ;
• Quality management ;
• Management ;
• Software ergonomics ;
• Mathematics ;
• Systems engineering.

Comme le montre la figure suivante, à travers ce guide, l‘IEEE traite 10 domaines du génie logiciel :

• Software requirements ;
• Software design ;
• Software construction ;
• Software testing ;
• Software maintenance ;
• Software configuration management ;
• Software engineering management ;
• Software engineering process ;
• Software engineering tools and methods ;
• Software quality.

Six Sigma

Présentation de Six Sigma

Six sigma est à l‘origine une démarche qualité née au coeur même de Motorola en 1979. Limitée dans un premier temps aux techniques de SPC (Statistical Process Control / MSP Maitrise Statistique des Procédés), elle est rapidement devenue une véritable méthode de management englobant l‘ensemble des fonctions de l‘entreprise. Six sigma a ensuite été perfectionnée par d‘autres groupes, comme General Electric, l‘ayant mise en oeuvre avec succès. Six sigma est une méthode de management du progrès particulièrement efficace. Issue d‘une démarche fortement connotée qualité à l‘origine, Six sigma est relativement simple sur le plan du principe. Elle est fondée sur une règle : pour satisfaire les clients, il faut délivrer des produits de qualité .

La méthode Six Sigma offre techniques et outils pour améliorer drastiquement la capacité de production des processus tout en réduisant les défauts. Orientée processus de production à l‘origine, la méthode a été généralisé à tous les domaines, IT y compris, et recherche la régularité absolue. En fait la variabilité de la qualité finale est essentiellement la conséquence de l‘instabilité des composants entrant dans la fabrication du produit, de l‘imprécision des procédures de travail et plus globalement de la complexité des processus. 6 sigma impose de rester dans les limites en appliquant le principe : « if you can measure how many defects you have in a process, you can systematically figure out how to eliminate them and get as close to zero defects as possible ». Autrement dit, en résumé : « Si on peut mesurer on peut corriger ».

Six Sigma, la culture de la mesure au service de l‘amélioration continue

Six Sigma n‘est pas une amélioration ponctuelle. C‘est une réforme de fond de l‘ensemble de l‘organisation et des mentalités. Il faut ainsi soigner la formation, l‘accompagnement du changement et la mesure continue de la performance. L‘effort doit être continuellement soutenu.

La réussite du projet repose sur des paramètres bien précis :

• une approche par projet, chacun bien délimité en termes de périmètre d‘action, de délais et de budget ;
• des objectifs clairs, concrets, précis et connus ;
• une formation extensive de l‘ensemble des acteurs directs et indirects du projet ;
• une coopération et une participation de tous les instants ;
• un système de mesure performant.

La généralisation de la mesure est à la base de la méthode Six Sigma. Cependant, cet esprit de mesure ne se limite pas à la phase de mise en oeuvre du projet. C‘est en fait une véritable culture de la mesure qu‘il s‘agit d‘instaurer au sein même de l‘organisation. Il existe deux méthodes de mise en oeuvre de Six Sigma :

DMAIC : Define, Mesure, Analyse, Improve, Control

La méthodologie DMAIC doit être utilisée quand un produit ou un processus sont déjà existants au sein de l‘entreprise, mais ne rencontrent pas la spécification de client ou n‘exécutent pas en juste proportion.

Définir répond à : Quel problème doit être résolu ? Il permet d‘identifier :

• le produit ou le processus à améliorer ;
• ce que le client souhaite avec le CTQ (Critical to Quality).

Mesurer répond à : Quelles sont les performances du processus ? Il permet de mesurer :

• les caractéristiques clefs du produit ;
• les critères de performance du processus.

Analyser répond à : Où et quand apparaissent les défauts ? Il permet de :

• Analyser les différentes parties du processus ou du produit qui affectent la qualité ou contribuent au problème ;
• Trouver les causes de ce problème.

Améliorer répond à : Comment améliorer les performances du processus ? Il permet de :

• Résoudre les problèmes en appliquant les bonnes pratiques.

Contrôler répond à : Quels contrôles mettre en place pour maintenir le gain acquis ? Il permet de :

• Partager les leçons apprises ;
• S‘assurer de la pérennité des acquis.

DMADV : Define, Measure, Analyze, Design, Verify

DMADV, encore appelé DFSS pour Design For Six Sigma, est utilisé pour concevoir de nouveaux produits ou services.

• Définir les objectifs de projet et les exigences client (interne et externe) ;
• Mesurer et déterminer les besoins clients et cahier des charges, benchmark des concurrents ;
• Analyser les options de processus afin de rencontrer les besoins client ;
• Concevoir les processus afin de rencontrer les besoins client ;
• Vérifier l‘exécution de la conception et sa capacité à valider les besoins clients.

ISO 9001v2000 « Systèmes de management de la qualité – Exigences »

Présentation d’ISO 9001v2000

Les normes ISO 9000 ont été originellement écrites en 1987, puis elles ont été révisées en 1994 et à nouveau en 2000. La norme ISO 9001v2000 porte essentiellement sur les processus permettant de réaliser un service ou un produit.

La présente norme internationale encourage l‘adoption d‘une approche processus lors du développement, de la mise en oeuvre et de l?amélioration de l‘efficacité d‘un système de management de la qualité, afin d‘accroître la satisfaction des clients par le respect de leurs exigences. Lorsqu‘elle est utilisée dans un Système de Management de la Qualité (SMQ), cette approche souligne l‘importance de :

• comprendre et de satisfaire les exigences ;
• considérer les processus en termes de valeur ajoutée ;
• mesurer la performance et l‘efficacité des processus ;
• améliorer en permanence des processus sur la base de mesures objectives.

Le Système de Management de la Qualité (SMQ) s‘appuie ainsi sur divers documents permettant de décrire, avec un niveau de précision grandissant, les activités de l‘entreprise et leurs interactions :

• Le Manuel de Management de la Qualité (MMQ) qui présente la politique, l‘organisation et les principes mis en oeuvre dans le cadre du SMQ ainsi que les dispositions pour assurer la conformité aux exigences contractuelles, internes et réglementaires;
• Le Plan Qualité Projet (PQP) qui décrit l‘organisation de l‘équipe de projet, la gestion des configurations, les processus de réalisation et les règles établies au sein du projet en adéquation avec le SMQ mis en place et les souhaits des clients.
• Les processus décrivent l‘enchaînement des activités réalisées, les responsabilités, les éléments d‘entrées et de sorties.
• Les procédures qui décrivent les tâches à réaliser pour une activité donnée faisant partie d‘un processus.
• Les instructions qui décrivent la façon d‘effectuer une tâche donnée.
• Les documents d‘enregistrement qualité sont mis en place pour faciliter la gestion et l‘enregistrement des activités. Constitués de modèles de document, ils permettent de rendre compte, d‘établir et de conserver l‘information.

La réalisation du Système de Management de la Qualité (SMQ) doit répondre aux exigences des 8 chapitres de la norme décrits ci-dessous :

PDCA : Plan, Do, Check, Act, « la roue de Deming »

Défini par Deming, PDCA est basé sur le concept de la remise en cause des méthodes de travail, des flux d‘information, des fonctions, des documents de travail utilisés… afin de mettre en place l‘amélioration continue. La remise en cause comprend l‘analyse de toutes les anomalies rencontrées dans la vie d‘une entreprise, vues ou pas encore vues par les clients. Ce processus constitué de 4 phases (Planifier, Faire, Vérifier, Améliorer) permet de structurer la démarche d‘amélioration continue définie par ISO 9001v2000. En effet, le cycle PDCA est une méthode qui permet d‘exécuter un travail de manière efficace et rationnelle.

Références

Les livres de référence :

• PMI Project Management Institute. « A Guide to the Project Management Body of Knowledge (Pmbok Guide) Third Edition ». Project Management Institute, 2004.
• Maurice Pillet. « Six Sigma : Comment l‘appliquer ». Editions d‘Organisation, 2003.
• Thomas Pyzdek. « The Six Sigma Handbook : A Complete Guide for Green Belts, Black Belts, and Managers at All Levels ». McGraw-Hill Companies, 2003.
• DIN. « Systèmes de management de la qualité ; Exigences ; (ISO 9001 :2000), Version trilingue EN ISO 9001:2000″. DIN, 2000.

Suggestion d'articles :

1. La complémentarité entre les standards de gestion des processus IT
2. La gestion des processus IT
3. ITIL : Information Technology Infrastructure Library

Pourquoi VAL IT?

Value for IT, c’est à dire la création de la valeur pour l’informatique, permet de répondre à la question fondamentale : Est-ce que les investissements en SI sont réellement managés de sorte à :

• obtenir la contribution maximale à la création de valeur?
• à un coût supportable?
• et avec un niveau de risque acceptable?

La réponse de VAL IT est dans la mise en oeuvre de processus qui vont permettre de répondre à vos questions en connaissance de cause, et de bonnes pratiques.

Quels sont les principes de VAL IT?

Val IT distingue 3 domaines de gouvernance des projets SI :

• la gouvernance de la valeur (GV), ou comment s‘organiser pour piloter, maîtriser les projets, décider de leur poursuite et savoir, en toute connaissance de cause d‘où vient la valeur pour l‘entreprise et comment la valoriser;
• la gestion de portefeuille (GP), ou comment organiser les projets élémentaires pour obtenir une vision exploitable des projets lancés ou en cours, et se donner les moyens de piloter le portefeuille de projets;
• la gestion des investissements (GI), qui relève d‘une analyse des projets élémentaires et de construction de programmes qui les englobent, et s‘appuie sur une logique de démonstration de la valeur créée, au travers de l‘outil fondamental qu‘est le business case.

Comment dérouler VAL IT?

Chaque domaine de VAL IT est composé de processus :

• 6 Processus pour la gouvernance de la valeur (GV):
  • GV1 Assurer un leadership informé et engagé
  • GV2 Définir et mettre en oeuvre les processus
  • GV3 Définir les caractéristiques du portefeuille
  • GV4 Aligner et intégrer la gestion de valeur avec la planification financière de l’entreprise
  • GV5 Établir un contrôle de la gouvernance efficace
  • GV6 Améliorer continuellement les pratiques de gestion de la valeur
• 6 Processus la gestion de portefeuille (GP):
  • GP1 Établir une direction stratégique et cibler un investissement mixte
  • GP2 Déterminer la disponibilité et les financements
  • GP3 Gérer la disponibilité des ressources humaines
  • GP4 Évaluer et choisir des programmes pour le financement
  • GP5 Contrôler et rapporter la performance des portefeuilles d’investissement
  • GP6 Optimiser la performance du portefeuille d’investissement
• 10 Processus pour la gestion des investissements (GI):
  • GI1 Développer et évaluer le programme initial du business case
  • GI2 Comprendre le programme candidat et les options d’implémentation
  • GI3 Développer le plan du programme
  • GI4 Suivre les coûts et les bénéfices sur le cycle de vie complet
  • GI5 Développer le programme candidat du business case détaillé
  • GI6 Lancer et gérer le programme
  • GI7 Mettre à jour le portefeuille opérationnel IT
  • GI8 Mettre à jour le business case
  • GI9 Contrôler et suivre le programme
  • GI10 Retirer le programme

Afin de déterminer le niveau de maturité relativement à VAL IT, chacun de ces processus est évalué sur une échelle de 6 valeurs (0 à 6):

• 0 : Non existant;
• 1 : Initié;
• 2 : Répétable;
• 3 : Défini;
• 4 : Géré;
• 5 : Optimisé.

Conclusion

Val IT constitue un complément indispensable à CobiT pour traiter la performance des investissements informatiques et leurs apports à la valeur de l’entreprise. En effet, VAL IT fournit un cadre de référence pour la gestion d’un portefeuille de projets informatiques avec un double focus : gouvernance de la valeur et gestion des investissements.

L’ensemble CobiT v4 et Val IT constituent un cadre de référence complet de la gouvernance des systèmes d’information en traitant respectivement la performance de la fonction informatique, sous l’angle excellence opérationnelle, et celle de la création de valeur via les investissements maîtrisés.

Références

• Les liens :
  • Le site de l’ISACA : http://www.isaca.org/Template.cfm?Section=Val_IT4&Template=/ContentManagement/ContentDisplay.cfm&ContentID=39994
  • Le site de l’AFAI : http://www.afai.asso.fr/index.php?m=29

Suggestion d'articles :

1. COBIT : Control Objectives for Business & Related Technology
2. La complémentarité entre les standards de gestion des processus IT
3. ITIL : Information Technology Infrastructure Library

Créé à la fin des années 80, à l‘initiative du secteur public britannique, ITIL (Information Technology Infrastructure Library) est un référentiel de bonnes pratiques pour la gestion des services informatiques (internes et externes).
ITIL s‘intéresse à la production, qu‘il s‘agisse de fourniture de services informatiques ou d‘exploitation interne.

Principe d’ITIL

ITIL vise à améliorer les services informatiques (prestation de service, service aux utilisateurs…) suivant plusieurs principes :

• constituer un catalogue de bonnes pratiques à partir de démarches reconnues ;
• mettre le client au centre de la démarche de la DSI ;
• organiser les activités suivant des processus bien établis ;
• jeter les bases d‘une évolutivité dans le temps des processus et services.

ITIL met en place plusieurs moyens pour :

• organiser les processus informatiques :
  • définir les processus et leurs interactions ;
  • définir les rôles et les responsabilités.
• améliorer les relations clients-fournisseurs :
  • instituer un point central de relation entre client et fournisseur : le service desk ;
  • définir des moyens d‘échanges entre l‘entreprise et sa DSI aux niveaux stratégique, tactique et opérationnel.
• définir des moyens de contrôle des résultats obtenus ;
• utiliser des processus ou des méthodologies connues par ailleurs.

Description d‘ITIL

Comme le montre la figure, ITIL comporte 6 modules principaux :

• Service Support : support aux utilisateurs ;
• Service Delivery : gestion du service ;
• Software Asset Management : gestion des logiciels ;
• ICT Infrastructure Management : contrôle des processus ;
• Application Management : gestion des projets ;
• Security Management : gestion de la sécurité.

ITIL comporte aussi un module sur l‘utilisation d‘ITIL et un autre sur l‘avenir des services IT. Les 2 premiers (Service Support et Service Delivery) constituent la base d‘ITIL. Dans le Service Support, le Service Desk est le point de contact avec l‘utilisateur.

Le Service Support est destiné au support des utilisateurs et à la gestion des services, suivant 6 processus :

• Service Desk : point central de relation entre client et fournisseur ;
• Incident Management : définition des activités et opérations pour la reprise rapide après incident ;
• Problem Management : surveillance du niveau de service et analyse des incidents ;
• Configuration Management : description détaillée du SI et de ses processus ;
• Change Management : méthodes et procédures pour supporter le changement;
• Release Management : processus de mise en service des nouvelles activités.

Le Service Delivery organise la gestion des services (besoins, ressources, niveau de service, contrôle des coûts…) suivant 6 processus :

• Service Level Management : description des services et mises en place avec l‘utilisateur. Niveaux de service (SLA) ;
• Capacity Management : gestion des ressources et dé‘nition des objectifs de l‘entreprise ;
• Availability Management : contrôle de la conformité du niveau de service par rapport aux engagements ;
• Service Continuity Management : définition et utilisation d‘un plan de surveillance de la continuité du service (sécurité) ;
• Financial Management : définition des seuils de rentabilité, décisionnel financier ;
• Customer Relationship Management.

Conclusion

Pour la gestion d’infrastructure, ITIL constitue le meilleur référentiel à adopter. Les modules les plus exploités par les entreprises sont la gestion opérationnelle des services : Service Support et Service Delivery. Ils regroupent 12 processus appliqués aujourd’hui essentiellement à la production.

La certification ITIL est attribuée uniquement à des individus. Si une entreprise veut démontrer la bonne application des processus, elle devra aller vers la certification ISO 20000, laquelle impose une application exhaustive de ces processus.

Références

• Les livres de référence :
  • Thierry Chamfrault and Claude Durand. « ITIL et la gestion des services : Méthodes, mise en oeuvre et bonnes pratiques ». Dunod, 2006.
  • Christian Dumont. « ITIL : Pour un service informatique optimal ». Eyrolles, 2007.
• Les liens :
  • Le site officiel : http://www.itil-officialsite.com/home/home.asp
  • Le site francophone et gratuit d’ITIL : http://www.itilfrance.com/

Suggestion d'articles :

1. COBIT : Control Objectives for Business & Related Technology
2. ITIL v3: La gestion du cycle de vie de services
3. La gestion des processus IT

Le modèle COBIT (Control Objectives for Business & Related Technology) est une méthode de Maîtrise des Systèmes d’Information (IT Gouvernance) et d’audit de systèmes d’information, éditée par l’Information System Audit & Control Association (ISACA) en 1996. C’est un modèle qui vise à aider le management à gérer les risques (sécurité, fiabilité, conformité) et les investissements.

Les 5 parties de la méthode COBIT

La synthèse est une présentation des concepts et principes de COBIT. Elle présente les domaines, les objectifs de contrôle généraux (aussi appelés processus) et le cadre de référence. Le modèle COBIT constitue une structure de relations et de processus (cadre de référence ou framework) visant à diriger et contrôler l‘entreprise pour qu‘elle atteigne ses objectifs, par l‘utilisation des technologies pour améliorer l‘activité et répondre aux besoins métiers.

Le cadre de référence se décline en check lists méthodiques couvrant 4 domaines, 34 objectifs de contrôle généraux et 302 objectifs de contrôle détaillés. Chacun de ces objectifs répond à 3 familles d‘impératifs : fiduciaire, sécurité et qualité. Comme le montre la figure suivante, la liste des domaines du cadre de référence de COBIT sont :

• le domaine Planification & Organisation : 11 objectifs couvrent tout ce qui concerne la stratégie et les tactiques. Ils identifient les moyens permettant à l‘informatique de contribuer le plus efficacement à la réalisation des objectifs commerciaux de l‘entreprise ;
• le domaine Acquisition & Mise en Place : 6 objectifs concernent la réalisation de la stratégie informatique, l‘identification, l‘acquisition, le développement, l‘installation des solutions informatiques et leur intégration dans des processus commerciaux ;
• le domaine Distribution & Support : 13 objectifs regroupent la livraison des prestations informatiques exigées (l‘exploitation, la sécurité, les plans d‘urgences et la formation) ;
• le domaine Surveillance : 4 objectifs permettent au management d‘évaluer la qualité et la conformité des processus informatiques aux exigences de contrôle.

Le guide d‘audit permet d‘évaluer et de justifier les risques et les faiblesses des objectifs généraux et détaillés et de mettre en place des actions correctives. Ce guide d‘audit répond à 4 principes :

• l‘acquisition d‘une bonne compréhension ;
• l‘évaluation des contrôles ;
• la vérification de la conformité ;
• la justification du risque de ne pas atteindre les objectifs de contrôle.

Le guide de management fournit des indicateurs clés d‘objectifs et de performances et des facteurs clés de succès. C‘est aussi dans ce guide que l‘on trouve le modèle de maturité. Il évalue l‘atteinte d‘un ou plusieurs objectifs généraux sous forme d‘une échelle de 0 à 5:

• 0 : Inexistant;
• 1 : Existant mais non organisé (initialisé au cas par cas) ;
• 2 : Décrit (reproductible mais intuitif) ;
• 3 : Défini (avec documentation) ;
• 4 : Surveillé et mesuré ;
• 5:Optimisé.

Les outils de la mise en oeuvre contiennent une présentation de « success story » d‘entreprises qui ont mis en place rapidement et avec succès la méthode COBIT. Cette partie intègre deux outils d‘analyse de sensibilisation du management et de diagnostic de contrôle informatique.

Le COBIT est donc étroitement lié aux objectifs de l‘entreprise tout en s‘intéressant plus particulièrement à l‘informatique. Il permet de rassurer le management, d‘uniformiser les méthodes de travail et de garantir la sécurité et les contrôles de leurs services informatiques.

Conclusion

COBIT est un outil fédérateur qui permet d’instaurer un langage commun pour parler de la gouvernance des systèmes d’information tout en intégrant les apports d’autres référentiels comme l’ISO 9000, ITIL ou CMMI. Cette spécificité résulte essentiellement du fait que COBIT adresse une population un peu différente que les autres référentiels, en effet COBIT a une coloration plus MOA.

Il a l’avantage d’avoir été conçu pour une approche globale et le désavantage, pour le pilotage, d’être issu de l’audit, ce qui fait que son volet guide de management est méconnu.

Enfin, il existe un COBIT Quickstart permettant un démarrage encore plus rapide et une bonne appropriation du référentiel.

Références

Les liens :

• Le site de l’ISACA : http://www.isaca.org/Template.cfm?Section=COBIT6&Template=/TaggedPage/TaggedPageDisplay.cfm&TPLID=55&ContentID=31519
• Le site de l’AFAI : http://www.afai.asso.fr/index.php?m=29

Suggestion d'articles :

1. ITIL : Information Technology Infrastructure Library
2. VAL IT : Value for IT
3. OCTO Technology participe à la construction de BforBank

Le Capability Maturity Model Integration (CMMI) SE/SW/IPPD/SS v1.1 a été publié en 2003 par le Software Engineering Institute (SEI) de l’université Carnegie Mellon. Une mise à jour a été publiée en 2006 portant le nom de CMMI for Development, Version 1.2. La version 1.3 est en cours d’élaboration. CMMI est un modèle de bonnes pratiques qui repose sur une amélioration progressive des processus de développement informatique de l’entreprise.

CMMI intègre d’anciens modèles développés dans les années 90. Chacun de ces modèles est spécifique à des domaines distincts de l’ingénierie informatique:

• SE (Systems Engineering) : Ingénierie système;
• SW (SoftWare) : Développement logiciel;
• SS (Supplier Sourcing) : Gestion des fournisseurs;
• IPPD (Integrated Product and Process Development) : Développement intégré des produits et processus.

CMMI for Dev. 1.2 regroupe 22 domaines de processus « Process Area » (PA).

Deux modèles de représentation coexistent, correspondant à deux points de vue légèrement différents. Les deux représentations s’appuient sur les mêmes PAs mais ceux-ci sont utilisés différemment :

• Représentation continue : La représentation continue privilégie de regarder l’évolution au niveau de chaque domaine de processus (PA) et d’y associer des stades de développement de la capacité du processus;
• Représentation étagée : La représentation étagée préconise une évolution par étage au niveau de toute l’organisation de développement. Elle permet ainsi de définir le niveau de maturité (ML) de l’organisation.

CMMI représentation étagée

Comme le montre la figure, la représentation étagée exprime l’évolution des pratiques de développement en fonction d’une vue organisationnelle. La première étape est de définir le périmètre à observer : « l’organisation ». Puis, on observe son comportement au regard des 5 niveaux de maturité (ML) regroupant les 22 PAs:

• ML 1 : Niveau « Initial » où les processus sont non répétables et non maîtrisés.
• ML 2 : Niveau « Géré » où les processus sont planifiés et répétables. Le ML 2 traduit la mise en oeuvre effective de pratiques de base au niveau des projets mais sans harmonisation au niveau de l’organisation (par exemple chaque projet gère différemment sa planification, ses configurations…); il s’adresse essentiellement aux Chefs de Projet.
• ML 3 : Niveau « Défni » où les processus sont organisés, réactifs et maîtrisés. Le ML 3 traduit le déploiement harmonisé de pratiques définies au niveau de l’organisation ; il s’adresse à toute la population et met l’accent sur l’engineering produit et l’organisation centrale.
• ML 4 : Niveau « Quantifié » où les processus sont mesurés et contrôles. Le ML 4 traduit une gestion quantitative des processus, basée sur des analyses statistiques (les performances de l’organisation sont prévisibles ).
• ML 5 : Niveau « Optimisé » où l’organisation est en amélioration continue. Le ML 5 traduit la maturité de l’organisation où veille technologique et amélioration continue concourent à l’excellence du livrable.

Chacun des Processus Areas (PA) doit répondre à des objectifs qui peuvent être :

• spécifques (SG), intrinsèquement reliés à la nature de l’activité couverte par le PA;
• génériques (GG), transversaux et identiques d’un PA à l’autre.

Ces objectifs se déclinent en pratiques qui décrivent le comportement attendu de la part de l’organisation ou d’un projet (Pratique spécifique (SP), Pratique générique (GP)).

Afin de prouver la bonne implémentation de chacune des pratiques, des preuves PII (Practice Implementation Indicator) doivent être collectées.

Le document ci-joint récapitule toutes les pratiques de CMMI et les questions à se poser lors d’une évaluation : support

CMMI représentation continue

La représentation continue utilise une vision ciblée de l’évolution des pratiques de développement. Contrairement à la représentation étagée qui regroupe sous des niveaux de maturité les différents PAs, la représentation continue exprime la capacité de chaque PA au sein de l’organisation suivant une échelle de 6 niveaux.

Cette représentation permet à l’entreprise d’entreprendre un programme d’amélioration sur un bouquet de PAs qu’elle a sélectionnés.

Une décomposition proposée par le SEI regroupe les 22 Process Area en 4 catégories (comme le montre le tableau précédent) définissant le CMMI Framework :

• Engineering Process Areas (Ingénierie) : Ils couvrent les activités de développement et de maintenance qui sont partagées entre les différentes disciplines d’ingénierie (ingénierie système, ingénierie logiciel)
• Project Management Process Areas (Gestion de projet) : Ils couvrent les activités de gestion de projet liées à la planification, au suivi et au contrôle du projet
• Support Process Areas (Support) : Ils couvrent les activités qui soutiennent le développement et la maintenance du produit. Ce sont des processus qui permettent d’exécuter d’autres processus. En général, ils s’adressent à des processus liés au projet mais peuvent aussi s’adresser aux processus de l’organisation. Par exemple, le PA « Process and Product Quality Assurance » peut être utilisé avec tous les autres PAs pour fournir une évaluation objective des processus et des produits de travail décrits dans tous les secteurs de processus
• Process Management Process Areas (Gestion des processus) : Ils concernent toutes les activités transversales du projet liées à la définition, la planification, le réapprovisionnement, le déploiement, l’exécution, le contrôle, la direction, l’évaluation, la mesure et les processus d’amélioration

IDEAL : Initiating, Diagnosing, Establishing, Acting, Learning

Le SEI a défini un modèle de support d’amélioration continue. Les paragraphes suivants fournissent une définition générale de chaque étape du modèle

• Phase initiale : C’est ici que l’infrastructure d’amélioration initiale est établie, que les rôles et les responsabilités de l’infrastructure sont définis et que les premières ressources sont assignées. Au cours de cette étape, un plan d’amélioration continue des processus est établi pour guider l’organisation jusqu’à la fin des phases initiales, de diagnostic et d’établissement. L’approbation de l’initiative est obtenue de pair avec un engagement relatif aux ressources futures requises pour le travail qu’il reste à faire. Les objectifs généraux du programme sont définis au cours de la phase initiale. Ils sont établis en fonction des besoins de gestion de l’organisation et seront peaufinés et précisés au cours de la phase d’établissement du modèle IDEAL.
  Deux éléments clés sont habituellement établis, soit un groupe directeur de gestion et un groupe d’exécution des processus. En outre, au cours de la phase initiale, des plans sont établis pour annoncer le démarrage de l’initiative et il est suggéré d’effectuer des évaluations organisationnelles pour établir l’état de préparation de l’organisation à l’égard d’une initiative d’amélioration.
• Phase de diagnostic : La phase de diagnostic du modèle IDEALSM lance l’organisation sur la voie de l’amélioration continue des processus. Elle sert à établir les fondements pour les prochaines étapes. Au cours de cette phase, le plan d’action est mis en oeuvre conformément à la vision de l’organisation, à son plan d’activités stratégiques, aux leçons tirées à la suite d’efforts d’amélioration antérieurs, aux questions de gestion clés que doit régler l’organisation et à ses objectifs à long terme. Des activités d’évaluation sont exécutées afin d’établir la ligne de référence de l’état actuel de l’organisation. Les résultats obtenus et les recommandations formulées à partir de ces évaluations et de toutes les autres activités servant à établir la base de référence seront comparés aux efforts d’amélioration en cours ou prévus afin d’être intégrés dans le plan d’action
• Phase d’établissement : Au cours de la phase d’établissement, les enjeux sur lesquels l’organisation a décidé de se pencher dans le cadre de ses activités d’amélioration sont classés par ordre de priorité. Des stratégies en vue d’apporter des solutions sont mises au point. Le projet de plan d’action sera élaboré conformément à la vision de l’organisation, à son plan d’activités stratégiques, aux leçons tirées à la suite d’efforts d’amélioration antérieurs, aux questions de gestion clés que doit régler l’organisation et à ses objectifs à long terme.
  Au cours de la phase d’établissement, des objectifs mesurables sont dégagés à partir des objectifs généraux définis au cours de la phase initiale et seront inclus dans la version finale du plan d’action. Les paramètres requis pour surveiller les progrès réalisés sont également définis, des ressources sont engagées et la formation est dispensée aux groupes de travail technique ou aux équipes d’exécution des processus. Le plan d’action mis au point servira à orienter les activités d’amélioration puisqu’il tient compte des constatations et des recommandations priorisées de la phase de diagnostic. En outre, au cours de cette phase, des gabarits de plan d’action tactique sont créés et mis à la disposition des équipes d’exécution des processus qui les compléteront et les réaliseront.
• Phase d’exécution : La phase d’exécution du modèle IDEAL sert à l’élaboration de solutions touchant les secteurs d’amélioration relevés au cours de la phase de diagnostic, à leur mise à l’essai et à leur diffusion dans toute l’organisation. Des plans seront élaborés afin d’exécuter des projets pilotes pour vérifier et évaluer les processus nouveaux ou améliorés. Lorsque l’exécution réussie de projets pilotes aura démontré que les nouveaux processus peuvent être adoptés, diffusés et institutionnalisés dans toute l’organisation, des plans pour les instaurer seront alors élaborés et mis en oeuvre.
• Phase d’amélioration : La phase d’amélioration a pour objectif de rendre la prochaine utilisation du modèle IDEAL plus efficace. À cette étape, les solutions ont été élaborées, les leçons ont été tirées et les paramètres relatifs au rendement et à la réalisation des objectifs ont été cernés. Ces objets ont été ajoutés à la base de données sur les processus qui deviendra une source d’information pour le personnel chargé d’utiliser à nouveau le modèle. À l’aide de l’information recueillie, il sera possible d’évaluer la stratégie, les méthodes et l’infrastructure utilisées au cours du programme d’amélioration. Ainsi, des correctifs ou des ajustements peuvent être apportés à la stratégie, aux méthodes ou à l’infrastructure avant le début du prochain cycle d’amélioration des processus. Les questions à se poser sont notamment les suivantes : Le rendement de l’infrastructure (groupe directeur de gestion, groupe d’exécution des processus, équipes d’exécution des processus…) a-t-il été adéquat? Les méthodes employées par les équipes d’exécution des processus au cours de leurs activités d’élaboration des solutions ont-elles été satisfaisantes ? Les activités de communication du programme ont-elles été suffisantes ? Le parrainage doit-il être réaffirmé ? Faut-il accomplir une autre activité de référence ? Le point de réinsertion dans le modèle IDEAL au cours du prochain cycle dépend étroitement des réponses données à des questions comme celles-ci.

SCAMPI : Standard CMMI Appraisal Method for Process Improvement

SCAMPI, Standard CMMI Appraisal Method for Process Improvement, est une méthode qui utilise le CMMI comme référentiel pour identifier les forces et faiblesses du processus logiciel et/ou système d’une entreprise ou d’un organisme. Cette méthode s’appuie sur une discipline et des règles rigoureuses qui assure l’exhaustivité et l’objectivité de l’évaluation. Elle se caractérise par la large place faite au consensus (c’est une équipe qui accomplit l’évaluation) et à l’implication de l’entité évaluée dans sa propre évaluation. Le SEI a développé cette méthode, gère un programme d’accréditation de chefs évaluateurs et diffuse périodique ment des statistiques.

Bien que conçue pour pouvoir évaluer des projets d’envergure, la méthode SCAMPI n’est pas réservée qu’aux grandes entreprises ou aux grands organismes. Plusieurs variations définies dans la méthode permettent de moduler un SCAMPI en accord avec chaque profil d’entreprise ou organisme à évaluer.

Il existe trois types de SCAMPI : SCAMPI Class C, Class B et Class A. La distinction principale entre ces trois évaluations est leur centre d’application :

• SCAMPI C est une évaluation d’ »Approche » ;
• SCAMPI B est une évaluation de « Déploiement » ;
• SCAMPI A est une évaluation d’ »Institutionnalisation ».

Seule l’évaluation SCAMPI Class A pourra déterminer officiellement le niveau de maturité de l’entreprise. Elle est généralement précédée d’une ou plusieurs évaluation SCAMPI Class B et/ou C.

• SCAMPI Class C : L’évaluation initiale SCAMPI Class C mesure la cohérence du référentiel de l’organisation avec les exigences du modèle CMMI. Les objectifs d’évaluation Class C :
  • fournir une formation sur CMMI et SCAMPI ;
  • s’assurer d’une interprétation appropriée des pratiques ;
  • fournir une compréhension commune du référentiel de l’entreprise ;
  • identifier les forces et les faiblesses ;
  • aider le SEPG à planifier des actions d’amélioration de processus ;
  • aider la direction à identifier les objectifs d’organisation ;
  • fournir les informations stratégiques pour des activités d’amélioration de processus ;
  • identifier ou valider les membres clefs pour l’amélioration de processus.
• SCAMPI Class B L’évaluation SCAMPI Class B analyse la profondeur du déploiement des pratiques du référentiel. Elle permet de :
  • examiner l’adéquation entre l’approche sélectionnée et le contexte :
    • comprendre les variations entre les pratiques actuelles ;
    • déterminer les membres qui vont guider la mise en oeuvre ;
    • identifier les corrections nécessaires
  • comprendre les diverses mises en oeuvre du référentiel :
    • impliquer et ouvrir le dialogue avec les équipes techniques sur ce qui fonctionne ;
    • examiner les  » direct artefacts  » résultant de la mise en oeuvre ;
    • chercher des éléments d’entrée pour mettre à jour l’approche
  • s’assurer d’avoir centré l’approche avec les objectifs business :
    • valider le plus d’éléments possible du modèle ;
    • réfléchir aux éléments restant du modèle.
  • préparer l’évaluation de Class A.
• SCAMPI Class A Les entreprises souhaitant faire reconnaître et communiquer leur niveau de maturité CMMI doivent soumettre leurs processus à une évaluation SCAMPI Class A, seule évaluation déterminant le niveau de maturité de l’organisation. Cette approche intègre des intervenants internes formés à l’évaluation de maturité organisationnelle. Les résultats définitifs indiquent la notation obtenue (niveau de maturité) ainsi que la description des forces et opportunités d’amélioration de chaque domaine de processus du périmètre évalué. La figure suivante montre les étapes de la préparation et de l’évaluation SCAMPI A.

Conclusion

CMMI peut être défini comme un modèle d’amélioration continue. En effet, CMMI est basé sur des pratiques spécifiques qui peuvent assimilées à des buts à atteindre en terme d’organisation et qui se définissent effectivement par des résultats observables (« Gérer les modifications aux exigences au fur et à mesure de leur évolution en cours de projet »…). D’un autre coté, il y a des pratiques génériques constituant une base d’institutionnalisation des processus.

Le challenge pour les entreprises souhaitant respecter CMMI est le choix de l’implémentation des pratiques. Le danger résulte en général d’un mauvais choix d’implémentation; car si sur le terrain chaque entreprise est libre d’implémenter les pratiques comme elle le souhaite, elle risque, par manque de créativité, inspiration heureuse ou conseils avisés, de mettre en place des solutions très lourdes, contraignantes et sans réelle valeur ajoutée (grands volumes de documentation, circuits de communication à rallonge…). Ce point est à l’origine de beaucoup de préjugés concernant CMMI (CMMI = de la documentation à n’en pas finir). Donc l’enjeu principal de la mise en place d’une démarche CMMI est le bon choix d’implémentation des pratiques afin de ne pas alourdir inutilement le quotidien des participants aux projets.

Références

• Les livres de référence :
  • Richard Basque. « CMMI un itinéraire fléché vers le Capability Maturity Model Integration ». Dunod, 2004
  • Richard Basque. « CMMI : Un itinéraire fléché vers le Capability Maturity Model Integration Version 1.2″. Dunod, 2006
  • Mary Beth Chrissis, Mike Konrad, and Sandy Shrum. « CMMI : Guidelines for Process Integration And Product Improvement ». Addison-Wesley Professional, 2006
  • SEI Software Engineering Institute. « CMMI for Development, Version 1.2″. SEI, 2006
• Les liens :
  • http://www.sei.cmu.edu/cmmi/index.html
  • Cette page contient tous les documents officiels de CMMI : http://www.sei.cmu.edu/cmmi/models/

Suggestion d'articles :

1. Synergies entre CMMI et les Méthodes Agiles
2. La complémentarité entre les standards de gestion des processus IT
3. Intégration continue performante (Part #3)

La gestion des processus IT constitue un enjeu majeur pour tout entreprise quelque soit sa taille. C’est pour cela que les plus grands organismes travaillant sur les processus IT (SEI, ISACA, PMI, IEEE…) ont défini leurs normes ou référentiels de bonnes pratiques. Ces référentiels constituent en général une base de capitalisation des bonnes pratiques observées au niveau des projets IT. Mais la question primordiale est comment se retrouver entre tous ces standards. C’est à cette question qu’on va essayer de répondre au travers de l’enssemble des articles qui vont suivre en présentant les standards les plus connus et/ou utilisés ainsi que leur spécificité. Le dernier article permettra de montrer la complémentarité qui peut exister entre ces standards.

• Présentation des principaux standards et référentiels de bonnes pratiques:
  • CMMI : Capability Maturity Model Integration
  • COBIT : Control Objectives for Business & Related Technology
  • ITIL : Information Technology Infrastructure Library
  • VAL IT : Value for IT
  • Autres standards
• La complémentarité entre ces standards

Au delà de l’implémentation de ces standards, le plus important reste de définir et de connaître la cible et le but à atteindre. Le meilleur practice model (comme CMMI pour l’ingénierie logicielle ou ITIL pour les infrastructures) n’est qu’une aide. C’est un moyen pour atteindre le but et assurer le suivi et l’exécution des étapes, mais il ne doit jamais devenir un but en soi.

Suggestion d'articles :

1. La complémentarité entre les standards de gestion des processus IT
2. Autres standards de gestion des processus IT
3. ITIL v3: La gestion du cycle de vie de services