Et donc là, j’ai repris en fait les étages de gouvernance, où derrière la gouvernance vous savez,
on a principalement l’idée de transparence. C’est-à-dire, on dit qui est responsable de quoi,
clarifier les rôles et les responsabilités, quels sont les objectifs stratégiques et puis qu’on va
décliner ensuite en stratégie et puis en tactique. Bref, quand on parle de gouvernance
d’entreprise et de grande direction d’entreprise, on commence par définir quelle est la vision de
l’entreprise. C’est-à-dire quel est l’état futur souhaité, idéal à terme qu’on souhaite atteindre.
Par exemple, on parle souvent de la vision comme étant une carte postale du futur. C’est-à-dire,
on est dans 10 ans et on s’envoie une carte postale à aujourd’hui pour dire, voilà quelle est la
situation, on est les leaders Européen de la voiture d’occasion dans le segment des particuliers,
et puis voilà, on a tel pourcentage de chiffre d’affaires etc. Et ça, ça nous permet d’avoir une
Page 1 sur 18
ligne de mire, d’avoir la lumière vers laquelle se diriger, si je peux m’exprimer comme ça. Et à
partir de là, on va définir quelles sont les missions de l’entreprise, c’est-à-dire, l’ensemble des
métiers, des compétences qu’il faut acquérir pour pouvoir atteindre la vision. Une fois qu’on a
ces différentes missions, si on reprend l’exemple de notre vendeur de voitures pour les
particuliers, c’est de maitriser peut-être l’achat des véhicules d’occasion ou l’achat en groupe
de véhicules neufs auprès des constructeurs. C’est peut-être aussi maitriser du financement,
faire des offres de service. Bref les différents métiers, les différentes compétences à acquérir, à
maitriser pour pouvoir remplir cette vision. Ensuite on va matérialiser les grands jalons par
lesquels il va falloir passer pour arriver jusqu’à l’état futur de l’entreprise, la vision. Et
connaissant ces jalons, il va falloir qu’on se mesure, et donc qu’on mette en place les objectifs
qui vont nous permettre de mesurer notre progression dans l’atteinte de cette vision, qui sont
des objectifs qui doivent être mesurables, donc on dit qui sont SMART : Specific, Measurable,
Attainable, Realistic et Time-bound. L’idée c’est qu’on puisse mesurer cette progression de
façon à savoir si on va dans la bonne direction ou si on n’arrivera pas à atteindre la vision.
Page 2 sur 18
Et pour ça, il y a un outil qui est très puissant, un outil de communication qui est le Balanced
Scorecard, qui est constitué de 4 grandes dimensions : une dimension financière bien étendu, le
nerf de la guerre à son importance. Mais résultats financiers, cette dimension, cette perspective
financière, elle s’appuie sur une politique client. D’où vient l’argent, évidemment des clients.
Quelle est la politique client, quelle est l’orientation client que l’entreprise a choisi d’utiliser
pour donner les résultats financiers attendus. Puis, cette politique client elle fonctionnera si on a
des processus qui sont efficients, qui sont efficaces. Et ces processus seront efficaces si on a
des ressources humaines qui sont compétents, qui sont motivées à faire ce qu’on leur demande
de faire. Et à ce moment-là, il y a de forte chances que les processus de l’entreprise
fonctionneront bien, que ces processus permettront la politique client de donner ses résultats, et
notamment ses résultats financiers. C’est ça le Balanced Scorecard, c’est Norton et Kaplan
dans les années 90 qui ont mis en œuvre cette outil, qui s’est beaucoup disséminer à travers les
entreprises. Et aujourd’hui on considère que c’est le meilleur outil d’alignement stratégique qui
permet de bien préciser les objectifs et la stratégie de l’entreprise et qui devrait être connu de
tous.
A partir de là, j’ai les objectifs, j’ai la stratégie de l’entreprise, l’idée pour que je puisse
articuler tout ça c’est que j’ai une vue à 360° de l’entreprise. Et ça c’est tout l’objet des cursus
de type MBA où on va regarder à quoi sert la financer, comment ça fonctionne, quel est rôle de
la comptabilité, le rôle des ressources humaines, de la logistique, des ventes, du marketing, bref
d’avoir une vue à 360° de l’entreprise de façon à bien comprendre comment est-ce qu’elle
fonctionne et comment il faut articuler ensuite les stratégies, les tactiques qui ont été données
par la direction générale. Alors, c’est ça aussi qui va nous permettre de comprendre
l’environnement. Ces fameux MBA vont nous permettre de savoir quelles sont les forces en
présence, de comprendre ces forces, de savoir comment agir sur ces forces, en tenir compte de
manière à définir une stratégie qui va aller dans la bonne direction, dans le sens de la direction
de l’atteinte des objectifs de l’entreprise. On n’est pas obligé de faire un MBA pour avoir ces
connaissances-là, il y a des programmes court qui existent, par exemple dans Skills4All vous
Page 3 sur 18
avez un programme de MBA allégé, MBA Boot Camp, qui vous donne une vue de l’ensemble
des grandes fonctions de l’entreprise sous la forme d’une chaine de valeurs et de bien savoir
comment positionner ces différentes fonctions de l’entreprise.
Page 4 sur 18
produits ou des services à une manière plus efficace. Voilà, l’analyse business c’est ça, c’est au
final l’entreprise est orientée vers la satisfaction du client et donc, il faut que je comprenne ses
besoins, ses attentes. C’est tout l’objet de l’analyse business et en relation avec BPM, c’est
pour ça que je les ai représentés sous 2 formes complémentaires dans le schéma.
Page 5 sur 18
mesure de mieux prendre en compte les besoins changeant des métiers, de pouvoir me
réorienter de manière plus fluide, plus rapide par rapport à de nouveaux besoins exprimés par
les métiers.
Et puis, la gouvernance des systèmes d’information c’est adresser des composant très
importants comme l’apport de valeurs de l’informatique aux métiers. Quelle est la valeur
apportée par l’informatique aux métiers ? Valeur tangible ou bien intangible. On va bien sur
parler pour la valeur tangible de coût, mais on va parler également de valeur intangible comme
la qualité des services informatiques, la qualité du service rendu.
Mais si cette valeur, on ne prend pas en compte également les risques liés à l’informatique, j’ai
tout un pan de ma problématique informatique qui n’est pas adressé. Si je mets en place des
services informatiques qui ne sont pas sécurisés et auquel cas, mon entreprise se retrouve avec
la liste, soyons fous, des cartes bleues de mes clients sur internet, là évidemment je vais perdre
considérablement en image et en valeur. Donc, la gouvernance bien sûr, elle adresse la
problématique de la valeur de l’informatique, mais également de la gestion des risques. Il ne
faut pas que l’informatique amène plus de risques métiers que ce qu’elle n’en enlève.
Vous avez également la problématique des ressources. Est-ce que je fais une utilisation
efficace, efficiente de mes ressources ? A la DSI, est-ce que mes ressources humaines, mes
ressources matérielles, en énergie etc. En matière. Est-ce que je fais une utilisation de mes
ressources qui est correcte. C’est un autre pan de ma gouvernance des systèmes d’information.
Et puis enfin, il faut que cette direction informatique, elle propose des services qui sont alignés
avec la stratégie de l’entreprise. La problématique de l’alignement, c’est une problématique très
Page 6 sur 18
importante pour les DSI, pour être sûr de livrer le produit, le service, la fonctionnalité qui va
bien, au bon moment, sous la bonne forme.
COBIT offre une réponse pour prendre en compte ces 5 dimensions en partant des objectifs
métiers de l’entreprise et en descendant jusqu’au objectifs informatiques. C’est un référentiel
très puissant, c’est l’ISACA qui propose ce référentiel. Sous peine de vous enregistrer, de
recevoir quelques mails, vous pouvez prendre connaissance de ce référentiel-là qui est
extrêmement riche. COBIT c’est le tableau de bord, c’est l’outil quotidien des directeurs
informatiques. Donc, COBIT, lui il permet de clarifier les responsabilités, de traduire les
business gold en IT gold, de monitorer, de contrôler la DSI de façon à être sûr que le niveau de
contrôle adéquat est posé sur la DSI. Et que les systèmes d’information, la DSI, fournissent la
valeur, gère ses risque, mesure sa performance, fasse une utilisation efficiente de ses ressources
et formule des solutions qui sont alignées avec la stratégie de l’entreprise. COBIT c’est un outil
extrêmement important qui va articuler les solutions informatiques dans l’axe des besoins de
business. C’est aussi COBIT qui va dire, mais attention, pour améliorer votre gestion de risque,
votre performance, il faut que vous, vous focaliser sur la sécurité par exemple. COBIT va
donner des objectifs vis-à-vis de la sécurité des systèmes d’information. COBIT ne dit pas
comment faire les choses, il dit simplement, voilà il faut que vous fassiez ceci, il faut que vous
réalisez ceci. COBIT dit quoi faire, mais il ne dit pas comment. Il faut donc s’appuyer sur un
certain nombre de référentiels pour pouvoir répondre à cette question, comment. Et ce n’est pas
une lacune en fait, COBIT attire l’attention sur les points qu’il faut mettre en œuvre dans le
système d’information, mais il vous laisse le choix de la meilleure pratique pour les mettre en
œuvre. Si on veut s’occuper de la sécurité des systèmes d’information, le meilleur référentiel
qui s’occupe de ça, qui traite de cette question, c’est quand même ISO 27000, la famille des
normes ISO 27 000 qui explique en détail comment mettre en place un système de gestion de la
sécurité, quelles sont les meilleures pratiques de gestion de la sécurité, ça c’est 27 002, quelles
sont les risques lié à la gestion de la sécurité, ça c’est 27 005. Bref, être en mesure de traiter de
Page 7 sur 18
la question de la sécurité de la manière la plus efficace possible. Ça, ça fait partie des objectifs
de la gouvernance des systèmes d’informations bien évidemment.
Toujours dans l’axe de COBIT, on va attirer l’attention sur les services fournis. Assurez-vous
que les services fournis apportent bien de la valeur, font une utilisation raisonnable des
ressources de l’entreprise. Et pour ça, le meilleur référentiel qui parle de ça, c’est ITIL. ITIL
c’est comment identifier, concevoir, mettre en œuvre une offre de services informatique
qui soit adaptée aux besoins des métiers, qui soit efficiente, sur lesquels on puisse prendre
des engagements et sur laquelle on puisse avoir une vue en terme de contrat, de garantie
et d’utilité. C’est également un référentiel qui explique comment améliorer continuellement
l’offre de service. Et c’est un des rares référentiels qui explique comment faire les choses. Il y a
beaucoup de référentiels, de normes qui expliquent quoi faire, ITIL explique lui, comment faire
les choses. Et c’est un référentiel extrêmement détaillé, un des plus abouti qui existe
actuellement, le plus abouti de manière tout à fait certaine sur la gestion des services
informatiques.
Une fois qu’on a ça, on a des processus informatiques, il faut qu’on s’occupe de leur efficience.
Vous, vous souvenez que dans la gouvernance, on attire l’attention sur l’utilisation des
ressources et sur la performance. L’efficience des processus IT c’est comment je fais en sorte
que mes processus informatiques, comme par exemple une gestion d’incident, comme par
exemple une gestion de changement, une gestion de la demande, une gestion des fournisseurs,
soit fluide, fonctionne de manière industrialisé, la plus fiable possible et fasse encore une fois
une utilisation efficiente des ressources. On a un outil qui s’appelle Lean-IT, qui traite de cette
problématique, qui provient du Lean Management, qui lui-même provient de Toyota des
années50 dont on parlera tout à l’heure. Et le Lean dit, on va essayer d’identifier tous les
gaspillages qui existent dans notre processus et on va essayer de les éradiquer pour faire en
sorte que le processus soit fluide. Et si mon processus est fluide, à ce moment-là, j’ai une
efficacité, une efficience maximum dans mon processus.
Page 8 sur 18
Voilà, tout ça c’est bien, mais à un moment donné, on commence à avoir un empilement
vertical, assez considérable. Il va falloir vérifier qu’à tout moment cette édifice-là tienne debout
verticalement. Et là on va parler d’architecture d’entreprise. Il n’y a pas beaucoup de référentiel
qui parle d’architecture d’entreprise, on a le modèle du CESA de l’Ecole Centrale, on a le
modèle de Zachman qui était un collaborateur d’IBM, qui a mis en place un modèle explicatif
de l’architecture des entreprises et de leur architecture dans les années 80. Mais le seul modèle
vraiment abouti, international, connu sur la question de l’architecture d’entreprise c’est
TOGAF. TOGAF dit, attention, quand on parle d’architecture, on parle d’architectures avec un
« s », parce qu’il y a différents niveaux d’architecture. Quand on parle d’architecture
d’entreprise, on a en fait, 5 niveaux différents. On a l’architecture du métier, où on retrouve les
processus métier, les processus qui vont s’occuper de la vente, du marketing, du support, de
tout ce que vous voulez. Et de quoi, ont besoin les métiers ? Ils ont besoin d’informations.
D’informations sur les ventes, sur le chiffre d’affaires, sur les clients, sur les comportements
clients, sur les produits, etc. Information qui est nécessaire au métier pour prendre des
décisions. Faut-il retirer ce produit du catalogue ? Faut-il en créer un nouveau ? Quel type de
produit est-ce qu’il faut créer ? Autant de questions qui ont besoin d’information. Cette
information vient d’où ? Elle vient d’applications qui manipulent des données. Des données qui
sont hébergées sur des systèmes. Ce qui constitue en fait un empilement de 5 couches
différentes. D’abord mes processus métier, mes processus métier qui ont besoin d’informations,
informations qui sont fournies par des applications manipulant des données hébergées sur des
systèmes. Et TOGAF dit, la difficulté c’est de garder alignées, verticalement ces différentes
couches d’architectures. C’est-à-dire que si je change quelque chose dans mes processus
métier, il va y avoir une conséquence dans mon référentiel d’information, une conséquence sur
mes applications, sur mes données et sur mes systèmes. Et puis TOGAF dit qu’il faut aussi
s’assurer une homogénéité horizontale, c’est-à-dire que toute ma couche applicative soit
cohérente, soit urbanisée. Et là on va faire justement le lien avec l’urbanisation des systèmes
d’information. TOGAF dit également que ma couche de données doit être homogène, et là, on
va faire le lien par exemple avec des référentiels de type, Data Master Management. Il dit, il
Page 9 sur 18
faut que vous ayez une couche d’information qui soit homogène. Et là on va faire le lien avec
COBIT. COBIT dit exactement, l’informatique est à pour fournir de l’information au métier.
L’information qui va permettre de prendre des décisions. De l’information secure, de
l’information réelle, fraiche, pour lesquelles on a l’autorisation de détenir. Parce qu’évidement
on a des lois et des réglementations sur tout ça. COBIT dit, voilà comment faire pour délivrer
de la bonne information aux métiers. Et les métiers bien sûr en font une utilisation à travers
leurs processus métiers. C’est-à-dire qu’on a le lien avec BPM bien entendu, les business
process de l’entreprise. Au niveau le plus bas, au niveau des systèmes on fait le lien avec ITIL.
Au niveau de l’infrastructure, il ne faut pas oublier que le 2e « i » de ITIL signifie
Infrastructure. Et donc ITIL décrit le mieux comment mettre en place des services, une
infrastructure dans un environnement de production, de manière à permettre la délivrance des
services derrière, qui soient utilisés par les métiers. Donc, TOGAF c’est un référentiel qui
permet d’aligner tout ça de manière stricte et permettre une transformation progressive
dans l’entreprise. C’est-à-dire avec des cycles de transformation réguliers, on va amener
l’entreprise à se transformer et à répondre aux besoins changeant des métiers.
Derrière, de quoi va-t-on devoir s’occuper ? Tout ça bien entendu c’est lancer des projets, c’est
s’occuper des programmes, c’est s’occuper d’organiser la transformation de l’entreprise en
livrant des produits et des services. Donc, l’idée c’est qu’on a besoin d’une gestion de projets.
Une gestion de projet, c’est de dire qu’est-ce qu’il faut livrer et sous quelle forme pour pouvoir
satisfaire les besoins des métiers. En gros il y a 2 grands types de référentiel de gestion de
projet, on a 2 grandes méthodologies de gestion de projet qui sont : Les méthodologies
classique, où là on retrouve PMP et puis PRINCE2. Et puis on a les méthodologies agiles, on
va revenir là-dessus, où on trouve principalement SCRUM. Alors, c’est quoi une méthodologie
de gestion de projet classique ? Déjà, qu’est-ce que c’est qu’un projet ? Un projet c’est quelque
chose qui livre un produit. Quand je dis projet, je dis, je livre un produit. C’est-à-dire en fait
que je réalise un périmètre, on va appeler ça le SCOPE du projet. Quel est le périmètre que je
dois livrer, la fonctionnalité, le produit que je dois livrer, le service que je dois livrer ? Quelles
Page 10 sur 18
doivent être ses caractéristiques ? Ça je vais le retrouver dans le SCOPE du projet. Et une fois
que j’ai le périmètre à réaliser du projet, je vais en déduire les activités qui vont être nécessaires
pour réaliser ce périmètre. On a parlé de TIME. Une fois que j’aurais les activités à réaliser
pour ce périmètre, eh ben je vais en connaitre le cout. Je vais savoir combien va me couter ce
projet à réaliser pour réaliser ce périmètre. Alors, vous, vous doutez bien que dans une gestion
de projet classique, parce que là je suis en train de parler de gestion de projet classique, toute la
difficulté résulte dans l’expression du périmètre du besoin. Si je me trompe dans mon
expression de besoin, derrière, les activités qui vont découler ne seront pas correctes. Les couts
qui vont être comptabilisés ne seront pas correctes. Bref, mon projet ne tiendra pas la route.
Toute la difficulté d’une méthodologie de gestion de projet classique, c’est de définir le
périmètre. C’est-à-dire déjà, identifier les bonnes parties prenantes. Si je n’ai pas les bonnes
personnes autour de la table, ils ne me feront pas une expression de besoin qui correspondra
aux besoins réels de l’entreprise vis-à-vis du projet. C’est là toute la difficulté des méthodes
classiques.
Après, quelle est la différence, entre PRINCE2 et puis PMP, qui sont les 2 grandes
méthodologies pour parler de ça, c’est le niveau de certification. En fait, PMP c’est un niveau
de certification assez élevé, qui justifie en plus d’un certain nombre d’années d’expérience.
Puisque si quelqu’un à un niveau bac+4 et supérieur, il doit justifier de 4 500 heures de gestion
de projets pour être PMP. Et si la personne ne justifie pas de de bac+4, eh bien elle doit justifier
de 7 500 heures de gestion de projet pour pouvoir passer l’examen PMP qui est d’un niveau
assez élevé. Ça demande pas mal de travail personnel. Pour PRINCE2, ce n’est pas du tout la
même chose, en fait, il suffit de passer la certification. Il y a 2 niveaux : il y a le niveau
Fondation, il y a le niveau Practitioner. Il n’y a pas de grande difficulté à l’obtention de cette
certification et au-delà de ça, il n’y a pas de prérequis en terme d’expérience. Vous pouvez être
tout nouveau chef de projet et vous certifier à PRINCE2. Une fois que vous disposez de
l’expérience nécessaire, il y a tout intérêt à passer PMP, parce que c’est une des certifications
Page 11 sur 18
les plus reconnues et les plus recherchée sur le marché. Parce qu’il y a vraiment un niveau qui
est reconnu, c’est cette certification qui a une grande valeur.
Si je ne sais pas définir mon périmètre, il y a la vraie question, comment je m’y prends ? Parce
que si je ne connais pas mon périmètre, je ne vais pas être en mesure de définir le scope, donc
le temps et les coûts. Et c’est là qu’intervient la méthodologie agile, où on dit en fait, le
périmètre je vais le construire au fur et à mesure. C’est-à-dire que je vais commencer par livrer
une fonctionnalité, et puis je vais avoir un retour de mon client, de mon utilisateur, et puis je
vais en livrer une seconde, puis une troisième, puis une quatrième. Ce qui a comme intérêt de
construire le produit, le service au fur et à mesure et d’avoir un retour des utilisateurs au fur et à
mesure qu’on construit le projet. C’est très intéressant. Ça implique l’utilisateur dans
l’expression de son besoin, ça le mobilise dans le projet, il voit des résultats et du coup c’est
des méthodes qui marchent très, très bien pour le développement de logiciel, mais également
pour tout ce qui est développement de produit à cycle de vie court. Si on a des produits qui ne
durent que, quelque mois, ça ne sert à rien de mettre en place une méthodologie classique, on
n’a pas le temps d’exprimer le besoin dans un cahier de charge, le scope, on n’a pas le temps de
le formaliser. Par contre, ce n’est pas parce qu’on est dans une méthode agile, qu’on fait
n’importe quoi au niveau du temps. On a un mécanisme qui s’appelle le time boxing, où le
mécanisme de base c’est une unité temporelle qui s’appelle un Sprint, qui dure 30 jours et pas
un de plus. Et dans ce temps imparti, on doit réaliser la fonctionnalité qui a été demandée. De
la même manière que pour les coûts, ce n’est pas parce qu’on est en mode agile qu’on est open
bar sur les coûts. On définit l’ordonnancement des fonctionnalités, par rapport à un bénéfice.
C’est ce ratio qui doit être pris en compte pour prioriser le lancement des différents
développements de fonctionnalités.
Donc, méthode agile, par rapport à classique, l’idée c’est de dire, en méthodologie classique je
dois définir une expression de besoin bien précise, tandis qu’en méthode agile, je construis en
fait mon produit au fur et à mesure que je découvre, que je développe. Et c’est quelque chose
Page 12 sur 18
de très, très puissant dans ce cas de figure là. Maintenant, il y a des projets, on sait bien tous
qu’il y a des projets qui ne donnent pas les résultats attendus. Quand vous regardez des grands
projets transversaux, par exemple les ERP, ce genre de choses-là, ils ne sont pas tous des
succès, bien au contraire, il y a une majorité de projets d’ERP ou de grands projets transversaux
qui ne sont ni dans le périmètre, ni dans les délais, ni dans les coûts. Parce qu’en fait ce ne sont
pas des projets. En fait, quand vous mettez en place un ERP, vous ne faites pas que déployer
une application, vous transformez l’organisation, vous transformez l’entreprise. En fait, ça ce
n’est pas un projet, ça c’est un programme. Autant, un projet vise à délivrer un produit, un
service, autant un programme vise à délivrer une transformation. Une transformation, c’est-à-
dire qu’il y a tout un volet de la gestion de programme qui n’existe pas dans la gestion de
projets qui est celui d’un accompagnement au changement. Dans une gestion de programme,
on a du Business Change Management. Gestion de programme, ça vise à délivrer une
transformation, ça va plus loin. Donc, je vais organiser la livraison des produits et des services
délivrés par les différents projets bien entendu, mais c’est aussi faciliter l’appropriation des
différents produits de projet. C’est garantir l’adéquation entre les différents services, les
différents produits livrés par les projets et les besoins de l’entreprise. Donc, gérer un
programme, ça va bien au-delà de gérer un gros projet. Ça vise également à s’assurer que les
produits sont appropriés. Donc, on a du Business Change Management, on a des personnes très
hauts placés dans l’entreprise qui vont piloter les programmes, en générale des personnes au
niveau du bord, du Comex de l’entreprise. Parce que les projets, les programmes, ça nécessite
des investissements très important, notamment les programmes. Du coup, on se pose la
question de la priorisation de ces différents projets, programmes. Et pour ça, on recommande
de mettre en place une gestion de portefeuille. Gestion de portefeuille c’est quoi ? Le
portefeuille, il a 3 objectifs. La gestion de portefeuille, elle vise à prioriser des investissements,
à choisir entre différents projets et programmes qui vont permettre à l’entreprise d’atteindre ses
objectifs. C’est prioriser les investissements et c’est équilibrer les différents projets et
programmes qu’il y a dans le portefeuille. Typiquement, je ne sais pas par quel projet ou
programme commencer, mais j’ai un outil qui me permet de prioriser mes investissements, mes
Page 13 sur 18
programmes, et de choisir de lancer le projet, le programme qui va être le plus bénéfique pour
l’organisation. Donc là, on parle pour la gestion de portefeuille de MoP, Management of
Portfolios. Pour la gestion de programmes, on parle de MSP, Management Succesful Program.
Et pour la gestion de projet, on l’a vu, PRINCE2, PMP.
Tout ça nous emmène à la question, j’ai des processus, mais comment est-ce que je les
améliore ? J’ai des processus de production, j’ai des processus de vente, des processus IT, ils
ne sont pas parfaits dès le 1er coup, comment je fais pour améliorer ces processus ? Ben là on
est une méthodologie qui est extrêmement intéressante, qui est Lean Six-Sigma et qui vise la
jonction de 2 méthodologies le Lean et puis le Six-Sigma comme son nom l’indique. Qui va
permettre de prendre un processus, n’importe quel type de processus, production, informatique,
tout ce que vous voulez et de l’améliorer sans cesse, d’être dans une démarche d’amélioration
continue pour être au plus près de la commande du client et être complètement conforme aux
exigences des clients. Alors, le Lean Six-Sigma, en fait de quoi ça parle ? Pour être dans
l’amélioration de processus, comme l’aurait dit La Palice, il faut d’abord avoir un processus.
Donc, il faut avoir un processus qu’on va traiter par le Lean Management d’un côté et ensuite
pas le Six-Sigma. Il n’y a pas de dualité entre Lean et Six-sigma, ils adressent 2 pans différents
de l’amélioration continue. Le Lean, déjà c’est Toyota années 50 et le Six-sigma c’est Motorola
années 80.
Le Lean lui, il dit, si vous avez un processus qui n’est pas fluide, eh bien, vous avez un
problème de production. Dans les années 50 d’après-guerre, le Japon avait des problèmes de
production automobile, ils n’arrivaient pas à produire suffisamment. Donc, ils ont cherché à
Page 14 sur 18
fluidifier leurs processus de production. Parce que dans un process de production par exemple,
automobile, si vous avez une étape qui n’a pas le même, rythme que les autres, c’est cette
étape-là qui imprime le rythme de l’ensemble de la chaine de processus. Donc, l’idée du Lean
c’était d’identifier tous les gaspillages dans le processus et ensuite de fluidifier ce processus.
Les gaspillages, ce sont les causes de non fluidité en fait. Le gaspillage, on en a
majoritairement 7, on a le transport, on l’attente, on a la surproduction, faire plus d’activité que
ce qui est nécessaire, on a les mouvements, etc. Tout un tas de gaspillage. Et si on éradique ces
gaspillages, on va avoir une fluidité dans le processus qui est maximum. Donc, le Lean adresse
la fluidité du processus et les gaspillages. Ça a donné naissance au Lean IT quand on a un
processus informatique tout simplement.
Le Six-Sigma lui il dit quelque d’autre. A l’origine, c’était Motorola qui avait des problèmes de
qualité dans ses puces informatiques, ses puces électroniques. Et en fait, ils ont remarqué que
ces problèmes de qualité, c’est-à-dire en fait, l’apparition de défauts, étaient lié au fait que le
processus n’était pas maitrisé. Il y avait de la variation dans le processus. En fait, il y a un lien
direct entre les défauts générés par le processus et la variation du processus. Comment se
matérialise ce lien ? En fait, imaginez, vous êtes une petite entreprise qui fabrique des barres
métalliques d’une certaine longueur. Vous avez un gros équipementier automobile qui vous
passe des commandes de centaines de milliers de pièces par mois. Et il vous dit, moi je veux
des barres métallique de 200 mm de longueur. Mais par contre, jusqu’à 201 mm je prends, à
partir de 199 mm je prends. Mais par contre tout ce qui est au-delà, je ne veux pas en entendre
parler. Si vous mesurez vos longueurs de barre métallique en sortie de chaine de production,
bien entendu elles ne vont pas être toutes alignées exactement sur les 200 mm. Il va y avoir des
variations de longueur liées à la température du métal, à l’usure des outils de coupe, à la
composition du métal, tout un tas de paramètres. Et on voit bien ici… Là je viens de faire une
magnifique gaussienne qui vous rappelle certainement de bons souvenirs d’étudiant. Il y a un
lien direct entre le sigma du processus et puis le nombre de défaut qui est généré. Vous êtes
bien d’accord que si, le sigma, c’est-à-dire la variation de mon processus augmente, eh bien je
Page 15 sur 18
vais générer de plus en plus de défauts ici. Si j’ai une autre courbe qui est beaucoup plus étale,
on voit que la variation est encore plus importante ici, on va générer énormément de défauts.
Donc, il y a un lien direct entre le niveau de sigma, c’est-à-dire la variation de mon processus et
puis le nombre de défauts générés. Et c’est tout l’objet justement de Six-Sigma, c’est de dire,
on va faire en sorte de resserrer la variation du processus de telle manière qu’elle va être
tellement maitrisée ce processus, que je vais pouvoir faire rentrer 6 fois dans mes spécifications
client, les limites supérieures et inférieures sont mes spécifications client. Je vais pouvoir faire
rentrer 6 fois ma courbe de Gausse dans mes spec client. C’est ce qui a donné naissance au Six-
Sigma. Et quand j’ai un processus tellement maitrisé, qu’il est au niveau Six-Sigma, eh ben en
fait, je génère 3 défauts par million de pièces. C’est-à-dire si je sortais un million de barres
métalliques de ma chaine de production, eh bien je n’aurais que 3 défaut, 3 non-conformités
dans mon processus.
Donc, on imagine qu’on arrive avec cette méthodologie Lean Six-Sigma, en fait à améliorer
des processus, originellement de production, des gros processus lourds et complètement
transversaux à l’entreprise et qu’on est capable de faire la même chose pour les processus
informatiques. Vous prenez une gestion d’incident ou une gestion de changement, vous pouvez
très bien faire du Lean et du Six-Sigma dessus. D’ailleurs, le processionner de ce genre de
processus devrait mettre en place des outils de Six-Sigma. Je vous encourage à regarder tout ce
qui est chez nous en termes de formation Six-Sigma, sur Skills4All on a tout un cursus très
intéressant sur le sujet qui devra vous donner de nombreux outils.
Voilà on arrive presque à la fin. Mais tout ça, quand est-ce qu’on parle de changement, quand
est-ce qu’on parle de changement organisationnel, quand est-ce qu’on parle de changement
humain et comment est-ce qu’on adresse ce changement ? Eh bien, là on a des lectures qui
parlent de gestion de changement organisationnel et humain. On a monsieur Kotter qui a publié
un livre là-dessus « Leading change », qui est une référence dans le domaine de l’étude du
changement organisationnel. John Kotter. Et puis on a d’autres livres comme par exemple
Page 16 sur 18
« Making sens of Change », qui est un excellent livre sur la gestion du changement
organisationnel et humain et qui met en avant le fait qu’on a plusieurs types de changement. On
a des changements organisationnels où finalement l’entreprise produit un peu comme une
machine. C’est-à-dire si on doit changer le type de produit qui sort de la machine, on va
appuyer, on va tourner sur un certain nombre de boutons. Donc, l’entreprise est vue comme une
machine et la transformation de l’entreprise c’est en fait une histoire de réglage. Par contre
quand on est dans une entreprise où on veut bouleverser les habitudes de l’entreprise, où on
veut faire un changement culturel, là ce n’est plus du tout le même type de changement, c’est
un changement de type organique, où en fait, on va agir sur les relations de pouvoir, sur
l’influence des différents parties prenantes les unes sur les autres. Et là, il faut un autre attirail
pour gérer le changement, il nous faut par exemple des Change agents. C’est-à-dire, des relais
qui vont aider à l’appropriation des nouvelles méthodologies, de la nouvelle façon de voir de
l’entreprise de manière à irriguer l’entreprise dans toute ses ramifications et être en mesure de
l’influencer jusqu’au plus près des activités opérationnelles. Et ces changes agents également
remontent des informations de baromètre social, d’organisation, au change leader qui pilote le
changement. Il y a des tas d’outils, de techniques, de méthodologies pour également adresser la
problématique du changement organisationnel. Sachant que le changement ce n’est pas une
surprise, va rencontrer de la résistance. Celui qui pense qu’il ne recevra pas de résistance
lorsqu’il imprime un changement, lorsqu’il guide un changement, c’est être dans un autre
monde. Parce qu’on sait bien que la façon naturelle de tout animal sur terre, d’adresser la peur
de l’inconnu qui représente le changement c’est de résister.
Donc, adresser le changement c’est tout simplement impératif dans une gestion d’entreprise,
dans une transformation d’entreprise et il faut que ça soit prévu dès le départ. D’où les
différentes lectures dont je vous ai parlé, il en existe bien sur de nombreuses sur le sujet, il ne
faut pas hésiter à en prendre connaissance. Parce qu’en réalisant ce changement, il peut faire
tout simplement basculer le projet du bon côté ou dans le côté obscure. Evidemment on a tous
connu ça.
Page 17 sur 18
Voilà en quelques mots, les différents types de référentiel et en quoi est-ce qu’ils peuvent vous
servir. N’hésitez pas à regarder les cursus de Skills4All, vous avez des formations qui traitent à
peu près de tout ça et qui vont certainement vous apporter beaucoup de valeur. Surtout
n’hésitez pas à regarder, faites-vous une idée, faites nous des retours. On est très friand de vos
retours. Je vous remercie, à bientôt.
Page 18 sur 18