Archives de catégorie : Documentation

Mise en place d’une plateforme d’hébergement web automatisée basée sur Docker, pour ENGIE LAB CRIGEN

ENGIE LAB CRIGEN a récemment été accompagné par Microsoft et Docker lors d’un hackfest ayant pour objectif d’améliorer la manière dont ils mettent à disposition des applications dans l’entreprise.

Les principaux axes de travail abordés lors de ce POC ont été la mise en place des bonnes pratiques DevOps pour déployer en continu une application composée de services Node.js, d’une base de données MongoDb, le tout sur la plateforme Microsoft Azure à l’aide de conteneurs Docker.

Voilà les différentes pratiques DevOps et technologies mises en place lors de ce POC:

  • Continuous Integration
  • Continuous Deployment
  • Infrastructure as Code
  • Azure Container Service
  • Docker Datacenter
  • GitLab
  • Visual Studio Team Services

Le hackfest s’est déroulé en deux phases : une première permettant l’établissement d’un Value Stream Map (VSM), afin de mettre en évidence la manière dont ENGIE LAB CRIGEN met à disposition l’application à ses utilisateurs et les points d’améliorations qui sont possibles. La seconde phase a consisté à prototyper la plateforme d’hébergement basée sur Docker, en y incluant directement les bonnes pratiques DevOps mises en évidence lors de la première phase.

Voilà la liste des différentes personnes ayant travaillé sur ce sujet :

ENGIE LAB CRIGEN :

  • Delphine Leblanc, Chef de projet
  • Kévin Mencé, Chef de projet IT
  • Eric Sablonière, Activité Informatique
  • Jean-François Philippe, Ingénieur de recherche
  • Alain Chenuaud, Architecte Infrastructure
  • Thomas Roueche, Chef de projet
  • Nabil Debbou, Responsable DevOps
  • Didier Morhain, Expert Cloud
  • Cao Truong Hoang, Ingénieur
  • Gregory Chatelain, Consultant

Docker :

  • Stéphane Woillez (@swoillez)

Microsoft :

  • Julien Corioland, Technical Evangelist (@jcorioland)
  • Benjamin Guinebertière, Technical Evangelist (@benjguin)
  • Pascal Sauliere, Technical Evangelist (@psauliere)
  • Benoît Touzé, Consultant MCS
  • Pascal Veque, Cloud Solution Architect

Présentation du client

ENGIN LAB CRIGEN est le centre de recherche et d’expertise opérationnelle du Groupe ENGIE dédié aux métiers du gaz, aux énergies nouvelles et aux technologies émergentes. Situé en région parisienne, à la Plaine Saint-Denis et Alfortville, il regroupe 350 collaborateurs.

Contexte et problématiques

ENGIE LAB CRIGEN se charge d’héberger des applications développées dans le cadre de projets de recherche, reponsant sur des stacks LAMP (Linux, Apache, PHP, MySQL), Node.js + MongoDb et autres technologies issues du monde open source.

Le principal objectif fixé dans le cadre des différents ateliers effectués avec Microsoft était de pouvoir travailler sur la mise en place de cette plateforme.

Pour réaliser cet objectif, l’accompagnement de Microsoft s’est déroulé en deux phases :

  • Un atelier de deux jours pour réaliser un Value Stream Mapping (VSM) en se basant sur une application hébergée existante d’ENGIE LAB CRIGEN afin de comprendre comment ils travaillent, gèrent le cycle de vie de l’application et ainsi mettre en œuvre les pratiques DevOps à conserver, améliorer et ajouter dans la future plateforme
  • Un atelier (hackfest) de 3 jours, pour prototyper la plateforme et mettre en place des processus automatisés d’intégration continue et de déploiement continu.

Atelier 1 : Value Stream Mapping

Architecture

L’application qui a été utilisée pour réaliser le VSM est composée des services suivants :

  • Une API développée en Node.js
  • Un site web d’administration développé en Node.js
  • Un site web “front” développé en Node.js
  • Une base de données MongoDb

Il y a également une application mobile qui consomme l’API mais qui n’a pas été traitée dans le cadre de l’atelier.

Vue globale de l'application

Value Stream Map

Afin de mettre en évidence les points d’améliorations possibles dans la manière de gérer le cycle de vie complet de l’application, nous avons donc réalisé une Value Stream Map :

Version finale du VSM

Cette phase extrêmement importante permet de faire en sorte que tous les acteurs autour de la table prennent le temps d’échanger sur la manière dont ils travaillent, dans le but de cartographier les différents processus et mettre en évidence des points d’amélioration possibles.

En effet, l’un des premiers retours fait par le client en séance était de dire qu’avant même de voir les résultats de l’exercice, cela avait au moins permis de réunir tous les acteurs travaillant sur le projet dans une même salle de réunion pendant deux jours. Certains d’entres-eux ne travaillant pas sur les mêmes sites.

Le fait de réunir des profils très différents à discuter ensemble de comment ils travaillent sur le projet permet de comprendre les enjeux et objectifs de chacun, mais aussi de mettre en évidence des points de défaut à améliorer.

Dans le cas présent, nous avons notamment identifié qu’un certains nombre d’opérations étaient réalisées manuellement ou déclenchées par des envois d’emails, ce qui est potentiellement source d’erreurs et de latence dans le processus de déploiement en continu. Nous avons également mis en évidence que l’ajout de certaines pratiques DevOps permettraient d’automatiser un certains nombre de ces tâches :

  • De l’infrastructure as code, pour la mise en place des environnements (Azure Container Service pour la recette et Docker Datacenter pour la production)
  • De la configuration as code, à base de Dockerfile et Docker Compose pour définir les stacks applicatives à déployer sur la nouvelle plateforme
  • De l’intégration continue, pour la création des images Docker et le push de celles-ci dans une Docker Trusted Registry
  • Du Release Management pour la fluidification du déploiement en recette, et en production, avec certaines étapes d’approbation entre les différents environnements

Dans un second temps, nous avons également défini la stratégie de branches à appliquer et la manière dont une nouvelle release devrait se faire sur la nouvelle plateforme :

Stratégie de branches à mettre en place

En résumé, l’idée ici est de dire :

  • Une branche de développement pour le travail en cours sur le sprint courant, avec éventuellement des features branches par développeur, si nécessaire
  • Une branche d’intégration, avec une opération de merge manuelle faite par le chef de projet pour être capable de déployer l’application en l’état sur un environnement d’intégration, dans les cas où c’est nécessaire pour le projet
  • Une branche master, sur laquelle on merge la branche de développement au travers d’une pull request, et donc d’une approbation (avec également la possibilité de créer des branches depuis master, pour appliquer un hotfix, par exemple)

Une fois la PR acceptée sur la branche master, une release est déclenchée avec un déploiement automatique sur l’environnement de recette, puis après approbation, un déploiement sur la production.

La dernière étape de cet atelier était de fixer la liste des environnements et technologies à utiliser lors du hackfest, à savoir :

Les développeurs utilisant déjà GitLab, le choix a été fait de conserver cet outil qui est totalement interopérable avec les autres. Certaines équipes utilisent déjà Visual Studio Team Services, aussi le choix de cet outil a été fait pour cette application, dans le souci de prototyper son usage pour cette équipe. Enfin,

ENGIE LAB CRIGEN souhaitait avoir deux environnements dans le Cloud, un pour la recette et un pour la production. En production, ils souhaitent pouvoir bénéficier du support de Docker (CS Docker Engine) qui est fourni avec les licences Docker Datacenter. Pour la recette en revanche, pas besoin de support, nous avons donc opté pour Azure Container Service qui permet de déployer simplement et rapidement la version open source de l’orchestrateur Docker Swarm.

Atelier 2 : Hackfest

La deuxième phase de l’atelier d’accompagnement d’ENGIE LAB CRIGEN a été la réalisation d’un hackfest de 3 jours pendant lequel nous avons prototypé la mise en place de la plateforme d’hébergement d’application web basée sur des conteneurs Docker, en y ajoutant des pratiques DevOps comme de l’intégration en continue, de l’infrastructure as code et du release management. Le but étant de permettre à ENGIE LAB CRIGEN de pouvoir déployer n’importe quelle application en continue !

Cet atelier a été divisé en 3 grandes étapes :

  • la mise en place de l’infrastructure des environnements de recette et de production, sur lequel les profils opérationnels ont travaillé
  • le packaging de l’application existante afin de pouvoir l’exécuter dans des conteneurs Docker, sur lesquel les profils plutôt développeurs ont travaillé
  • et enfin la mise en place du pipeline complet de CI/CD à l’aide de VSTS, avec à la fois des développeurs et opérationnels.

Afin d’être sûr de toujours garder le bon cap, nous avions des points de synchronisation régulier (après maximum 1/2 journée) pour toujours bien valider que toutes les briques s’assemblaient entre elles. Tout le monde était dans la même salle, ce qui facilite clairement la collaboration.

Travail sur la mise en place de la plateforme

Environnement de recette

Automatisation de l’environnement de recette

L’environnement de recette est hébergé dans Microsoft Azure dans un cluster Docker Swarm mis en œuvre par Azure Container Service (ACS).

Schéma de principe d’un cluster ACS en mode Docker Swarm :

ACS en mode Docker Swarm

Le principe est d’utiliser la ligne de commande Azure Xplat CLI pour déployer un nouveau cluster ACS. Cela se fait en une seule commande azure acs create, avec les paramètres appropriés et après avoir créé un groupe de ressources pour accueillir le cluster.

1. Préparation

Pour tester les commandes et le script dans Ubuntu ou dans Bash sur Ubuntu sur Windows 10 (Windows Subsystem for Linux), l’installation d’Azure CLI se fait de cette manière :

sudo apt-get install nodejs-legacy
sudo apt-get install npm
sudo npm install -g azure-cli

Pour que l’installation de l’environnement de recette soit automatisée dans un script, il faut que l’authentification dans Azure se fasse sans interaction. Pour ce faire, il faut utiliser un Service Principal dans Azure AD, ainsi que documenté ici.

Création du Service Principal et assignation des permissions sur l’abonnement Azure :

azure ad sp create -n <service principal name> -p <password> --home-page <homepage> --identifier-uris <uris>

azure role assignment create --objectId <Service Principal Object ID> -o Contributor -c /subscriptions/<Subscription ID>/

Les paramètres homepage et uris sont obligatoires, doivent être uniques, et vous seront utiles pour gérer le SPN plus tard, si besoin. Exemple :

$ azure ad sp create -n demosp1 -p Passw0rd! --home-page https://demo.com --identifier-uris https://demo.com/demo
info:    Executing command ad sp create
+ Creating application demosp1                                                 
+ Creating service principal for application 8dd44fe4-0290-4a51-b652-b8473015528d
data:    Object Id:               02b739e5-d5e7-43aa-b296-176f9b326b71
data:    Display Name:            demosp1
data:    Service Principal Names:
data:                             8dd44fe4-0290-4a51-b652-b8473015528d
data:                             https://demo.com/demo
info:    ad sp create command OK

$ azure role assignment create --objectId 02b739e5-d5e7-43aa-b296-176f9b326b71 -o Contributor -c /subscriptions/ca8358b6-1ae3-4ccd-860e-82c9dc9a9539/
info:    Executing command role assignment create
(...)
info:    role assignment create command OK

Une fois le Service Principal créé et autorisé comme contributeur sur l’abonnement Azure, il faut conserver ces trois éléments :

  • l’App ID du Service Principal
  • le mot de passe du Service Principal
  • le Tenant ID de l’abonnement Azure

Pour afficher l’App ID du Service Principal et le Tenant ID de l’abonnement :

azure ad sp show -c <Service Principal Name> --json
azure account show

Dans un script automatisé, il faudra utiliser cette commande pour l’authentification :

azure login -u "<App ID>" -p "<password>" --service-principal --tenant "<Tenant ID>"

2. Fichier de paramètres ACS

Le déploiement automatique d’un cluster ACS utilise un fichier de paramètres JSON. Ce fichier est généré par le script proposé avec les paramètres fournis.

Pour information, un fichier de paramètres ACS est créé, vide, par cette commande :

azure acs config create --parameter-file acsparam.json 

Complété avec des paramètres d’exemple, il ressemble à cet exemple (la clé publique SSH a été supprimée de l’exemple) :

{ 
  "provisioningState": "", 
  "orchestratorProfile": { 
    "orchestratorType": "Swarm" 
  }, 
  "masterProfile": { 
    "count": 1, 
    "dnsPrefix": "acsdemomaster", 
    "fqdn": "acsdemomaster.westeurope.cloudapp.azure.com" 
  }, 
  "agentPoolProfiles": [ 
    { 
      "name": "acsdemoagent", 
      "count": 2, 
      "vmSize": "Standard_D2_v2", 
      "dnsPrefix": "acsdemoagent", 
      "fqdn": "acsdemoagent.westeurope.cloudapp.azure.com" 
    } 
  ], 
  "linuxProfile": { 
    "adminUsername": "acsadmin", 
    "ssh": { 
      "publicKeys": [ 
        { 
          "keyData": "(...)"
        } 
      ] 
    } 
  }, 
  "diagnosticsProfile": { 
    "vmDiagnostics": { 
      "enabled": null, 
      "storageUri": "" 
    } 
  }, 
  "id": null, 
  "name": null, 
  "type": null, 
  "location": "westeurope", 
  "tags": {} 
} 

Remarquons que les noms DNS ne doivent pas déjà exister.

3. Script de déploiement automatique

Le script automatisé est joint : recette.sh.

Il effectue les tâches suivantes :

  • Récupération des paramètres (à finaliser)
  • Génération du fichier de paramètres ACS : /tmp/acsparam.json
  • Authentification Azure avec le Service Principal
  • Création du groupe de ressources
  • Déploiement du cluster ACS
  • Mise à jour de l’exécutable docker-compose avec la version 1.8.1 sur le master 0

4. Test et suppression de l’environnement

Une fois le cluster déployé, on peut se connecter en SSH sur un master :

ssh -p 2200 -i <private key file> acsadmin@<master fqdn> 

Pour connecter le client Docker au Swarm :

export DOCKER_HOST=:2375 

En cas de besoin, pour supprimer entièrement l’environnement, il suffit de supprimer le groupe de ressources :

azure group delete RG_acsdemo

Environnement de production

Contrairement à l’environnement de recette, l’environnement de production n’est pas destiné à être redéployé / cloné régulièrement. Les applications y sont bien déployées en continue, par contre le choix a été fait de ne pas recréer l’environnement à chaque déploiement d’une nouvelle version d’un service, pour la simple et bonne raison que cet environnement est destiné à être mutualisée entre plusieurs équipes.

L’accent a donc été mis sur le déploiement d’un environnement répondant aux exigences de la production, plutôt que sur l’automatisation de ce déploiement.

Le choix s’est porté sur Docker Datacenter dans Azure. Docker Datacenter est l’environement d’entreprise proposé par Docker, composé des éléments suivants :

  • Docker Engine : runtime, orchestration, réseau, volumes, avec support
  • Docker Trusted Registry (DTR) : gestion et distribution sécurisées des images
  • Docker Universal Control Plane (UCP) : portail de gestion du cluster

Docker Datacenter est disponible directement dans le Marketplace d’Azure, avec support conjoint de Microsoft et de Docker.

Docker Datacenter

Voici l’architecture que nous avons mis en place dans Azure :

Docker Datacenter

Nous avons regroupé toute les ressources au sein d’un groupe de ressources Microsoft Azure :

Docker Datacenter

Les 3 grandes composantes sont : les noeuds UCP, DTR et les agents, créés dans des groupes de haute disponibilité différents et derrière des load balancers différents.

Toutes les machines virtuelles exécutent des Ubuntu 14.04.

Une fois l’infrastructure déployée, nous avons suivi la procédure d’installation disponible sur le site de Docker pour l’installation et la configuration de Docker Datacenter.

Travail sur le packaging de l’application avec Docker

Le travail de cette partie de l’équipe consiste à partir des sources de l’application. L’application a des sources dans des repos git différents :

  • api. C’est l’API elle-même, ainsi que la base MongoDB qu’elle utilise.
  • vitrine.
  • supervision.

Il s’agit de trois applicatoins en Node.js.

première approche: un repo pour déployer les sources

Notre première approche a été de créer un repo git qui serait destiné à contenir les outils pour packager le code en Docker et ainsi l’envoyer vers les autres environnements (recette, production).

L’idée était de ne pas toucher aux repos existant et d’uniquement en ajouter pour le déploiement.

Nous n’avons finalement pas suivi cette piste car nous aurions eu des dépendances entre les fichiers Dockerfile de ce repo et les fichiers sources eux-mêmes. Par exemple, cela aurait consisté à copier dans un même répertoire, typiquement sur une VM de build, des fichiers venant du repo api et des fichiers venant du repo de packaging. La gestion du cycle de vie des sources aurait été complexe.

De plus, dans une démarche DevOps, il semble nécessaire que les Dev créent eux-mêmes les conteneurs Docker de façon à avoir une idée plus précise de ce dont les Ops disposeront.

Il sera à nouveau question de cela plus bas, à propos de la livraison de MongoDB.

seconde approche

Nous avons donc plutôt opté pour une approche consistant à mettre les fichiers Dockerfile dans les mêmes repos que les sources qu’ils embarquent.

Les fichiers Dockerfile peuvent embarquer des fichiers via la commande ADD. Ces fichiers doivent nécessairement se trouver sous le Dockerfile dans la hiérarchie des répertoires. C’est pourquoi, le fichier Dockerfile principal se trouve à la racine du repo git.

Dans le cadre du repo api, nous avions besoin de deux images Docker et non d’une seule:

  • une image Docker pour packager api lui-même
  • une image Docker pour packager la base MongoDB (nous y reviendrons plus en détail)

Pour cela, nous avons choisi de mettre les deux fichiers Dockerfile à la racine, avec des noms différents évidemment. Le fichier principal s’appelle Dockerfile et celui pour les outils de déploiement de la base de données Dockerfile-tools.

Ainsi, depuis chacun des fichiers, on peut ajouter tout ou partie des fichiers du repo. Par exemple, dans le cas d’api, on inclut tous les fichiers dans un dossier de travail du conteneur appelé /data par les deux commandes suivantes :

WORKDIR /data
ADD . .

Le contenu complet du fichier Dockerfile du repo api est le suivant:

# obfuscated1.westeurope.cloudapp.azure.com/crigen/obfuscated10-api
#
# VERSION   0.2

FROM obfuscated1.westeurope.cloudapp.azure.com/crigen/obfuscated10-nodejs:0.1

WORKDIR /data
ADD . .
RUN chmod a+x containerimage/init.sh
RUN npm install

ENTRYPOINT ["/bin/sh", "-c"]
CMD ["/data/containerimage/init.sh", ""]

NB: obfuscated* correspondent à des noms volontairement masqués dans cette documentation.

On remarque que l’image d’api hérite d’une image obfuscated1.westeurope.cloudapp.azure.com/crigen/obfuscated10-nodejs:0.1 qui est d’ailleurs la même pourvitrine et pour supervision.

C’est pourquoi nous avons aussi un repo base-container-images pour cette image et d’autres; en l’occurrence mongodb-base et mongodb-replicaset. Dans ce repo base-container-images, on a un dossier par image Docker visée avec chacun son fichier Dockerfile:

Le nom des images Docker est du type obfuscated1.westeurope.cloudapp.azure.com/crigen/obfuscated10-nodejs:0.1 et non pas crigen/obfuscated10-nodejs pour indiquer que l’image peut être téléchargée depuis la registry obfuscated1.westeurope.cloudapp.azure.com et avoir pour numéro de version 0.1 ici.

Lors de nos tests, l’équipe de packaging Docker n’avait pas accès à cette registry, de façon à vérifier que nous pouvions travailler sur une VM de build ou dev sans problème.

Ce fut le cas. Ce nom contenant la registry fonctionne aussi en local.

La gestion des numéros de versions des images Docker est dans les sources, plus précisément dans les fichiers Dockerfile pour que le développeur ne dépende pas d’un processus de build en aval pour avancer.

Autrement dit, le numéro de version des images Docker est déterministe à partir des sources.

Le processus de build peut le récupérer à partir des commentaires à l’intérieur du Dockerfile.

Il en est de même pour le nom des images Docker.

Déploiement de la base de données MongoDB

La base de données est toujours un cas spécial quand il s’agit de déploiement car, par définition, elle contient des données. Ces données ont un cycle de vie différent de l’application. Ce n’est pas parce qu’on passe de la version n à la version n+1 de l’application que les données changent.

Nous avons évoqué différentes hypothèses, regardé la façon dont le processus de livraison était documenté par les développeurs (il s’agit d’un document PDF qui décrit les opérations à effectuer suivant les cas rencontrés). Nous en avons déduit que la meilleure option était de fournir aux ops des outils permettant d’exécuter les commandes nécessaires sur la base pour la créer, restaurer ses données, modifier le schéma etc. en fonction du contexte.

Ce que Docker apporte dans ce cas est le fait que les développeurs qui rédigent la documentation, et les ops qui sont dans un environnement contraint, peuvent ici avoir accès aux mêmes environnements. En effet, le développeur peut packager dans un conteneur d’outils, tous les scripts, outils et autres binaires qui sont nécessaires. De plus, le développeur peut sur son environnement de développement tester dans les mêmes conditions que ce qu’auront les ops.

La seule différence est que les conteneurs Docker en dev s’éxécutent sur un seul hôte (une seule VM), alors que les conteneurs des ops sont a priori plutôt exécutés sur un cluster de plusieurs hosts. Cette différence est gérée par les moteurs Docker et sont donc assez transparentes une fois que tout est en place.

Voici le contenu du fichier Dockerfile-tools:

# obfuscated1.westeurope.cloudapp.azure.com/crigen/obfuscated10-api-tools
#
# VERSION   0.1

FROM obfuscated1.westeurope.cloudapp.azure.com/crigen/obfuscated10-api:0.2

RUN apt-key adv --keyserver hkp://keyserver.ubuntu.com:80 --recv EA312927 && \
    echo "deb http://repo.mongodb.org/apt/debian wheezy/mongodb-org/3.2 main" | tee /etc/apt/sources.list.d/mongodb-org-3.2.list && \
    apt-get update && \
    apt-get install -y \ 
        mongodb-org-shell \
        mongodb-org-tools 

RUN chmod a+x containerimage-tools/*.sh

ENTRYPOINT ["init"]

Ici, il n’y a pas de commande ADD parce qu’on hérite de l’image obfuscated1.westeurope.cloudapp.azure.com/crigen/obfuscated10-api:0.2 qui a elle-même inclus tout le repo api où se trouve aussi Dockerfile-tools. Cela inclut donc par exemple les fichiers containerimage-tools/*.sh sur lesquels on fait un chmod.

On aurait tout aussi bien pu opter pour une stratégie plus fine, avec des ADD différents dans les deux fichiers Dockerfile d’api.

On trouvera plus bas un exemple d’utilisation du conteneur généré par Dockerfile-tools, pour restaurer la base MongoDB.

Composition des conteneurs

Reste à composer tout cela dans une composition Docker. Le fichier docker-compose.yml et d’autres fichiers annexes se trouvent dans un 5ème repo: compose-containers.

Suivant qu’on est en dev/build, recette, production ou autre environnement, certains éléments de contexte changent. Il a été choisi d’avoir ces éléments de contexte sous forme de variables d’environnement.

Chaque environnement est responsable du positionnement des valeurs des variables. Les sources, dans l’environnement de dev, et les repos git, fournissent les variables nécessaires et des exemples de valeurs que sont celles de développement.

Exemples, dans le repo compose-containers, avec le fichier set_environment_variables.sh:

export DOCKER_NETWORK_TYPE=bridge

et le fichier docker-compose.env référencé par docker-compose.yml:

MONGODB_HOSTS_PORTS=mongodb:27017,slave1:27017,slave2:27017
MONGODB_USER=obfuscated3
MONGODB_PASSWORD=obfuscated4
MONGODB_DB=crigen
MONGODB_DEBUG=true

En ce qui concerne la montée en charge, il nous a semblé prudent de se limiter à une montée en charge statique au niveau du fichier docker-compose.yml, plutôt qu’avec des conteneurs génériques sur lesquels on demande a posteriori une montée en charge. Les raisons principales sont les suivantes:

  • une montée en charge dynamique n’était pas prioritaire dans le cadre du projet
  • une montée en charge statique (ex: vitrine1, vitrine2) permet
    • une résolution de nom simple, sans mise en place de services tels que CONSUL,
    • de connaître le nombre de noeuds à indiquer dans les chaînes de connexion MongoDB par exemple,
  • au moment du hackfest, Docker ne permet pas un docker-compose en indiquant directement le nombre de conteneurs nécessaires pour un service. Il faut le faire après ledocker-compose up.
  • il n’est pas très compliqué d’ajouter statiquement des conteneurs dans le docker-compose.yml par copie de blocs et changement des numéros de ports publics.

Au final, le fichier docker-compose.yml a le contenu suivant:

version: '2'
services:
  vitrine1:
    image: obfuscated1.westeurope.cloudapp.azure.com/crigen/obfuscated10-vitrine:0.1
    container_name: vitrine1
    ports: 
      - "50001:3001"
    networks:
      - obfuscated10net
  vitrine2:
    image: obfuscated1.westeurope.cloudapp.azure.com/crigen/obfuscated10-vitrine:0.1
    container_name: vitrine2
    ports: 
      - "50002:3001"
    networks:
      - obfuscated10net
  api1:
    image: obfuscated1.westeurope.cloudapp.azure.com/crigen/obfuscated10-api:0.2
    container_name: api1
    ports: 
      - "50011:8894"
    networks:
      - obfuscated10net
    env_file:
      - docker-compose.env
  api2:
    image: obfuscated1.westeurope.cloudapp.azure.com/crigen/obfuscated10-api:0.2
    container_name: api2
    ports: 
      - "50012:8894"
    networks:
      - obfuscated10net
    env_file:
      - docker-compose.env
  supervision1:
    image: obfuscated1.westeurope.cloudapp.azure.com/crigen/obfuscated10-supervision:0.1
    container_name: supervision1
    ports: 
      - "50021:3001"
    networks:
      - obfuscated10net
    env_file:
      - docker-compose.env
  supervision2:
    image: obfuscated1.westeurope.cloudapp.azure.com/crigen/obfuscated10-supervision:0.1
    container_name: supervision2
    ports: 
      - "50022:3001"
    networks:
      - obfuscated10net
    env_file:
      - docker-compose.env
  mongodb-master:
    image: obfuscated1.westeurope.cloudapp.azure.com/crigen/obfuscated10-mongodb-replicaset:0.1
    networks:
      - obfuscated10net
    environment:
      ROLE: "master"
      SLAVE1: "slave1"
      SLAVE2: "slave2"
    hostname: mongodb
    container_name: mongodb
  mongodb-slave1:
    image: obfuscated1.westeurope.cloudapp.azure.com/crigen/obfuscated10-mongodb-replicaset:0.1
    networks:
      - obfuscated10net
    hostname: slave1
    container_name: slave1
    depends_on:
      - mongodb-master
  mongodb-slave2:
    image: obfuscated1.westeurope.cloudapp.azure.com/crigen/obfuscated10-mongodb-replicaset:0.1
    networks:
      - obfuscated10net
    hostname: slave2
    container_name: slave2
    depends_on:
      - mongodb-master
  api-tools:
    image: obfuscated1.westeurope.cloudapp.azure.com/crigen/obfuscated10-api-tools:0.1
    container_name: api-tools
    networks:
      - obfuscated10net
    env_file:
      - docker-compose.env
    depends_on:
      - mongodb-master
      - mongodb-slave1
      - mongodb-slave2
      - api1
      - api2
networks:
  obfuscated10net:
    driver: ${DOCKER_NETWORK_TYPE}

On notera le réseau Docker de type bridge en build/dev pour fonctionner sur un host unique. Il sera de type overlay sur plusieurs hosts.

Construction des images et exécution du code dans les conteneurs sur la VM de build/dev

Voici la façon dont nous contruisons les images depuis une VM de build ou de dev (sous Ubuntu 16.04 dans le cadre de nos tests):

Récupération des sources depuis les différents repos:

cd $obfuscated10_HOME
git clone git@obfuscated2.westeurope.cloudapp.azure.com:atelier/vitrine.git 
git clone git@obfuscated2.westeurope.cloudapp.azure.com:atelier/api.git
git clone git@obfuscated2.westeurope.cloudapp.azure.com:atelier/supervision.git
git clone git@obfuscated2.westeurope.cloudapp.azure.com:atelier/base-container-images.git
git clone git@obfuscated2.westeurope.cloudapp.azure.com:atelier/compose-containers.git

Potentiellement, reset des images:

docker rmi obfuscated1.westeurope.cloudapp.azure.com/crigen/obfuscated10-mongodb-base:0.1
docker rmi obfuscated1.westeurope.cloudapp.azure.com/crigen/obfuscated10-mongodb-replicaset:0.1
docker rmi obfuscated1.westeurope.cloudapp.azure.com/crigen/obfuscated10-nodejs:0.1
docker rmi obfuscated1.westeurope.cloudapp.azure.com/crigen/obfuscated10-api:0.2
docker rmi obfuscated1.westeurope.cloudapp.azure.com/crigen/obfuscated10-api-tools:0.1
docker rmi obfuscated1.westeurope.cloudapp.azure.com/crigen/obfuscated10-vitrine:0.1
docker rmi obfuscated1.westeurope.cloudapp.azure.com/crigen/obfuscated10-supervision:0.1

Construction des images:

cd $obfuscated10_HOME/base-container-images
docker build -t obfuscated1.westeurope.cloudapp.azure.com/crigen/obfuscated10-nodejs:0.1 ./nodejs
docker build -t obfuscated1.westeurope.cloudapp.azure.com/crigen/obfuscated10-mongodb-base:0.1 ./mongodb-base
docker build -t obfuscated1.westeurope.cloudapp.azure.com/crigen/obfuscated10-mongodb-replicaset:0.1 ./mongodb-replicaset

cd $obfuscated10_HOME
docker build -t obfuscated1.westeurope.cloudapp.azure.com/crigen/obfuscated10-api:0.2 ./api
docker build -t obfuscated1.westeurope.cloudapp.azure.com/crigen/obfuscated10-api-tools:0.1 --file ./api/Dockerfile-tools ./api
docker build -t obfuscated1.westeurope.cloudapp.azure.com/crigen/obfuscated10-vitrine:0.1 ./vitrine
docker build -t obfuscated1.westeurope.cloudapp.azure.com/crigen/obfuscated10-supervision:0.1 ./supervision

Depuis cette même VM, on peut exécuter l’ensemble des conteneurs. Dans notre cas, nous avons fait fonctionner cela depuis une VM Azure avec 14 Go de RAM, plus que sur mon ordinateur portable ;-).

cd $obfuscated10_HOME/compose-containers
. set_environment_variables.sh
docker-compose up -d

Ces différentes commandes sont globalement celles qui sont ensuite exécutées depuis Visual Studio Team Services pour la construction automatisée des images docker depuis le code source.

Exemple d’utilisation du conteneur outils pour MongoDB

Voici par exemple ensuite comment on peut restaurer la base MongoDB:

docker exec -ti api-tools bash
cd database/export/db-pwz-v2-20161005
mongorestore --host rs0/$MONGODB_HOSTS --db $MONGODB_DB --drop ./dump/crigen
cd /data
mongo --host rs0/$MONGODB_HOSTS $MONGODB_DB
use crigen
show collections

Mise en place du déploiement en continu

Intégration Continue

La première tâche sur laquelle nous avons travaillé est la mise en place d’intégration continue pour faire en sorte de déclencher une build Visual Studio Team Services à chaque fois qu’une pull request est acceptée sur la branche master du projet GitLab.

L’objectif principal de la build est de packager l’application dans une image Docker à partir de son Dockerfile est de la pousser automatiquement dans la Docker Trusted Registry du projet. Pour réaliser cet objectif, il a été nécessaire de :

  • Installer et configurer un agent de build Visual Studio Team Services sous Linux
  • Installer l’extension Docker pour Visual Studio Team Services depuis la Marketplace
  • Configurer une connexion externe vers le dépôt GitLab et la Docker Trusted Registry dans Visual Studio Team Services
  • Créer une nouvelle définition de build et la connecter au dépôt GitLab
Installation d’un agent de build Visual Studio Team Services sous Linux

Visual Studio Team Services propose des agents hébergés sous Windows (fournis par la plateforme). Pour les workloads Linux, comme c’est le cas ici, il est nécessaire de créer sa propre machine et d’y installer un agent.

La procedure d’installation et de configuration est décrite sur cette page. Dans le cas présent, nous avons créé une machine Ubuntu 16.04 dans Microsoft Azure, nous y avons installé Docker en suivant la procédure décrite sur le site de Docker, puis nous avons configuré l’agent en suivant la documentation ci-dessus.

Nous avons choisi de créer l’agent dans un nouveau pool, nommé Crigen-docker. Une fois l’installation et la configuration terminées, on peut voir cet agent disponible dans les paramètres du projet d’équipe, dans Visual Studio Team Services :

Agent Queue

Nous configurerons ensuite chaque build et la release pour s’exécuter sur cet agent.

Installation de l’extension Docker pour VSTS

Afin de pouvoir générer les images Docker dans une build Visual Studio Team Services, il est nécessaire d’installer une extension développée par Microsoft et disponible dans la MarketPlace. Ceci se fait très simplement en cliquant sur le bouton Install et en suivant les instructions données par le site :

Définitions des différentes builds

Connexion de GitLab et Docker Trusted Registry dans VSTS

Visual Studio Team Services supporte la connexion à des dépôts Git externe, pour cela il faut se rendre dans les paramètres du projet d’équipes, onglet Services puis d’ajouter une nouvelle connexion vers un Git externe :

Définitions des différentes builds

Il suffit ensuite de renseigner l’URL du dépôt Git (ici hébergé sur une machine virtuelle dans Azure, dans GitLab) et les informations de connexion :

Définitions des différentes builds

De la même manière, il est possible de configurer une connexion vers la Docker Trusted Registry dans laquelle devront être poussées les images :

Définitions des différentes builds

Mise en place de la définition de build

Une fois la configuration des différents services externes et l’installation de l’extension Docker pour Visual Studio Team Services terminées, nous pouvons passer à la création des différentes définitions de Build (une pour chaque repository).

La première étape consiste à configurer le dépôt Git auquel se lier, via l’onglet Repository :

Configuration du dépôt

Nous avons ensuite besoin de 4 étapes pour chaque image Docker à envoyer dans la trusted registry :

1. La récupération du nom de l’image à l’aide d’un script Bash dans le Dockerfile (cf. astuce ci-dessous) 2. La récupération de la version de l’image à l’aide d’un script Bash dans le Dockerfile (cf. astuce ci-dessous)

Script Bash

3. Le build de l’image

Build Docker image

4. Le push de l’image dans la trusted registry

Push Docker Image

Enfin, il est possible de configurer la build pour s’exécuter sur l’agent Linux créé au préalable. Ceci se fait dans l’onglet General :

Configuration du pool

Après avoir réalisé ces quelques étapes simple, à chaque fois que des modifications sont poussées sur la branche master du projet GitLab, une build se déclenche automatiquement et se charge de recréer l’image Docker et de la pousser dans la Docker Trusted Registry.

Ils nous a ensuite suffi de répéter ces opérations pour chaque dépôt GitLab :

Définitions des différentes builds

ASTUCE

Pour le versionnage des images, nous avons utilisé des commentaires en en-tête des fichiers Dockerfile :

# URL_DOCKER_TRUSTED_REGISTRY/crigen/api
#
# VERSION   0.2

Pour récupérer le nom de l’image, nous utilisons :

/bin/bash -c "grep \"# URL_DOCKER_TRUSTED_REGISTRY\" .../Dockerfile | awk '{print \"##vso[task.setvariable variable=image.name;]\"$2}'"

Pour récupérer la version, nos utilisons :

/bin/bash -c "grep \"# VERSION\" .../Dockerfile | awk '{print \"##vso[task.setvariable variable=image.version;]\"$3}'"

Nous pouvons ensuite directement utiliser une tâche d’exécution d’un script bash pour pouvoir extraire le nom de l’image et numéro de version afin de l’affecter à des variables de la build que nous réutilisons par la suite :

Affectation de la variable au moment de la build

Utilisation des variables

Pour plus d’information concernant les “logging commands” qui permettent notamment d’affecter des variables en cours de build, consultez cette page.

Release Management

Le but du Release Management est de pouvoir déclencher une séquence de déploiement après la fin d’une build. Dans le cas présent, l’application est composée de micro-services et chaque build permet de créer et d’envoyer l’image Docker qui correspond au service dans la Trusted Registry Docker. Afin de garder une certaine maîtrise sur le déploiement de l’application, il a été choisi de stocker les scripts de déploiement (basés sur Docker Compose) dans un autre dépôt GitLab.

Ce choix nous a permis de déclarer une build d’intégration continue qui se déclenche automatiquement à chaque fois que les scripts de déploiement sont modifiés et uniquement quand ceux-ci sont modifiés. Cette nouvelle build ne se charge que de copier ces scripts en sortie, pour qu’ils soient disponibles en tant qu’artefacts réutilisables dans le processus de release :

CI Deploiement

Ainsi, on retrouve bien les fichiers nécessaires au déploiement en sortie de build :

CI artefacts

A partir de là, nous pouvons définir une nouvelle définition de Release dans Visual Studio Team Services, et la lier à la build précédente afin d’en récupérer les artefacts :

CI artefacts

Ensuite, nous avons défini nos deux environnements de Recette (Azure Container Service) et de Production (Docker DataCenter) :

CI artefacts

Pour chacun des environnements, le déploiement se fait à l’aide de deux étapes :

  1. La copie des fichiers de déploiement issus de la build à l’aide de SCP
  2. L’exécution d’un script de déploiement via SSH : ce script est très simple puisqu’il ne fait que manipuler la ligne de commande docker-compose: il commence par faire un pull, pour récupérer la dernière version des images à utiliser, puis stop les services, les supprime, et démarre les nouveaux !

Pour pouvoir faire cela, nous avons tout simplement déclaré les connexions SSH dans les services externes de Visual Studio Team Services :

CI artefacts

Enfin, ENGIE LAB CRIGEN souhaitait pouvoir valider le passage sur l’environnement de production, nous avons donc utilisé la fonctionnalité d’approbation de Visual Studio Team Services pour faire en sorte qu’une validation manuelle soit obligatoire entre l’environnement de Recette et l’environnement de Production. Pour cela, il suffit de cliquer sur les “…” au niveau de l’environnement de Production et de cliquer sur Assign approvers :

CI artefacts

Cela étant fait, à chaque fois qu’une étape de release sur la Recette se termine, le processus reste en attente d’une approbation manuelle :

CI artefacts

Conclusion

Dans cet atelier, Microsoft a accompagné le centre de recherche ENGIE LAB CRIGEN dans le prototypage d’une plateforme d’hébergement d’application web “as a service”, totalement bâtie sur la plateforme Microsoft Azure et capable d’exécuter n’importe quelle application web, quelle que soit la technologie utilisée pour la développer, et ce grâce aux conteneurs Docker. Cette plateforme a été pensée pour être totalement automatisée pour faire en sorte que les applications puissent y être déployées en continu, en utilisant Visual Studio Team Services.

Quelques mots du d’ENGIE LAB CRIGEN pour conclure:

Nous avons souhaité faire cet atelier, car nous cherchons à mettre en place une infrastructure nous permettant de déployer rapidement des applications dans le cadre de nos activités de recherche (POC …).

Ce workshop nous a permis de tester l’association de Docker sur Azure et de découvrir les produits commerciaux de Docker (Docker Datacenter, Trusted Registry…)

L’accompagnement de Microsoft a permis de voir de nouvelles « bonnes pratiques » concernant pour la mise en place d’un process devops, notamment sur l’automatisation des différentes étapes et de nous aider à mettre rapidement des choses en place pendant l’atelier

Références externes

Deep Learning : définition, concept et usages potentiels

Nous avons vu que le Machine Learning est un domaine de l’intelligence artificielle qui vise à étudier comment des algorithmes peuvent apprendre en étudiant des exemples.

Le Deep Learning est une méthode particulière d’apprentissage, qui ouvre de nouvelles possibilités.

Des exemples connus et visibles tirant partie de ces procédés de Deep Learning sont AlphaGo qui s’est imposé face aux champions du jeu de Go, DeepDream de Google ou même Watson d’IBM.

Afin de qualifier le Deep Learning un rapide rappel sur le Machine Learning s’impose.

Le Machine Learning

Le Machine Learning vise à entraîner un algorithme en se basant sur des exemples, avec pour objectif la construction d’un modèle prédictif.

Le Machine Learning vise à entraîner un algorithme en se basant sur des exemples, avec pour objectif la construction d’un modèle prédictif.

Le but est d’être capable de déterminer ce qui lie une sortie à une entrée.

Nous avons pris un exemple simple basé sur les données suivantes :

Notre objectif était de déterminer la fonction ou l’algorithme qui transforme les nombres en entrées en ceux en sortie.

Pour cela le Machine Learning va étudier les exemples fournis, puis essayer de déterminer l’algorithme de transformation. Cette phase s’appelle l’apprentissage.

C’est là que l’algorithme se sert des exemples fournis pour trouver un lien entre les données en sorties et les données en entrées. Ainsi il sera capable, peu importe le nombre en entrée, de déterminer le nombre en sortie.

Pour parvenir à cet objectif, l’algorithme va définir une fonction f(x)=aX, et faire varier a, jusqu’à ce qu’il trouve la bonne valeur. “a” est une caractéristique permettant de déterminer la sortie en fonction de l’entrée. Ici c’est a =2, et donc la fonction liant les entrées aux sortie est Y = f(x) = 2x.

Ensuite il sera capable de déterminer quelle sera la sortie (Y) pour n’importe quelle valeur de X, même si cette valeur n’est pas présente dans les exemples utilisés pour l’apprentissage.

Cette deuxième phase, c’est la prédiction. Simplement, l’algorithme est maintenant capable de déterminer que si X = 5, Y= 10.

Dans notre article précédent, nous nous en étions arrêté là. Maintenant comment modéliser des problématiques plus compliquées avec des dizaines de caractéristiques comme “a” différentes ?

Les réseaux de neurones

Prenons un exemple concret et cherchons à construire un algorithme qui exprime le temps qu’il a fait dans une journée (beau temps ou mauvais temps).

Pour cela, il faut lui fournir un certain nombre de paramètres en entrée :

  • La température
  • L’hygrométrie
  • La pression atmosphérique
  • La vitesse du vent

Et lui donner des exemples pour s’entraîner.

Evidemment plus le nombre d’exemple sera grand et varié, plus l’entraînement permettra d’arriver à un modèle précis et pertinent. Ici il faudrait un grand nombre de cas exposés pour être capable de généraliser la subjectivité liée au beau temps ou au mauvais temps. Pour la simplicité de l’exemple, nous nous en tiendrons à ces quelques valeurs.

Au final, nous aurons un algorithme qui pourra déterminer pour n’importe quel ensemble de ces entrées (Température, pression, hygrométrie, vitesse du vent) s’il fait beau ou non.

Pour modéliser et appréhender cette relation complexe, une simple fonction ne suffit pas, nous avons besoin d’un réseau de neurones.

Ce réseau de neurones aura deux couches (et sera donc extrêmement simple) :

L’intérêt du réseau de neurones est de modéliser l’impact des différents facteurs et leur relation entre eux. Lorsque la complexité des facteurs est grande, plutôt que de les traiter tous ensemble, on décompose l’analyse en étapes, les plus petites possibles.

Chaque étape est représentée par un neurone. Un neurone reçoit un certain nombre d’informations, chacune pondérée (p), et renvoi une réponse binaire 0 ou 1.

Ensuite cette réponse va venir alimenter le neurone suivant dans le réseau, qui lui-même produira une réponse binaire, et ainsi de suite jusqu’au dernier neurone du réseau.

La sortie du dernier neurone du réseau représente la réponse que l’on cherche à obtenir.

Pour affiner ce modèle, on joue sur la pondération de chaque entrée et le seuil qui déclenche la sortie 0 ou la sortie 1.

Autrement dit, un neurone : est une fonction mathématique qui met en relation une entrée X et une sortie Y. L’importance de chaque critère d’entrée est pondéré par un coefficient “p”. Avec le seuil “s”, d’activation de la sortie (qui va définir à quel moment la sortie va afficher 0 ou 1, soleil ou pluie ici), ce sont les deux variables qui vont pouvoir évoluer pour affiner et donc entraîner notre réseau de neurone pendant la phase d’apprentissage.

Le réseau de neurones permet donc de traiter des cas complexes avec de multiples entrées. Toutefois que se passe t’il lorsque les entrées sont encore plus nombreuses ?

Machine Learning et concepts abstraits

Dans le cas d’une image où l’objectif est d’identifier automatiquement ce qu’elle représente, les entrées seraient les pixels. Une image de 300x300px, représente 90 000 pixels et donc 90 000 valeurs en entrées potentielles. Tout traiter dans un réseau de neurones traditionnel serait bien trop complexe, et ce dernier serait incapable d’intégrer les concepts nécessaires à l’abstraction de l’image pour en déduire quoi que ce soit.

Intuitivement, nous serions tentés de penser qu’il faut traiter l’image par groupe de pixels pour faire ressortir des arbres, des constructions, des personnages etc…

C’est exactement ce qu’il manque pour pouvoir traiter ces images : des caractéristiques représentatives qui vont représenter au final, les entrées à traiter par le réseau de neurones.

Dans ce cas un algorithme tiers (non lié au réseau de neurone ou au machine learning) identifiera des caractéristiques prédéfinies.

Par exemple, si l’on veut que l’algorithme soit capable de distinguer sur des photos les motos des voitures, les caractéristiques à identifier en amont seraient

  • Nombre de roues
  • Nombres de vitres
  • La forme
  • Présence d’un casque…

Une fois ces caractéristiques identifiées il “suffit” de les passer au réseau de neurones qui, comme pour l’exemple de la météo, les traitera à partir d’exemples et identifiera une logique pour distinguer moto et voitures.

Cette solution nous laisse néanmoins avec deux problèmes :

  • Les performances de tels algorithmes sont loin d’être parfaites (15% d’erreurs)
  • Les caractéristiques à identifier dépendent de l’expertise humaine. Que faire alors dans une situation où les caractéristiques distinctives d’une situation ne sont pas identifiables par l’homme ? Autrement dit lorsqu’on ne sait pas déterminer intuitivement le lien entre la sortie et l’entrée ?

Le Deep Learning

Le Deep Learning construit lui-même ses caractéristiques d’analyse.

Ce qui rend le deep learning différent des méthodes de machine learning traditionnelles c’est que lors d’analyses complexes, les caractéristiques essentielles du traitement ne seront plus identifiées par un traitement humain dans algorithme préalable, mais directement par l’algorithme de Deep Learning.

En effet, si le réseau de neurones est suffisamment bien entraîné, il sera en mesure deconstruire lui-même ces caractéristiques, et sera donc capable d’identifier ce qu’il y a sur une image. Dans notre cas une moto ou une voiture, sans lui avoir transmis au préalable des informations sur ce qui caractérise une voiture ou une moto.

Pour ce faire, il construira à partir des exemples à disposition, ses propres caractéristiques (parfois similaires à celles qu’un humain aurait identifiées : Nombre de roues, Vitres, forme, casque…) et s’en servira pour analyser l’image et définir s’il s’agit d’une moto ou d’une voiture.

Pour parvenir à cela on utilisera un réseau de neurone profond (plusieurs couches), auquel, une fois entraîné, on passera directement l’image en entrée.

Pour résumer, lorsque les méthodes traditionnelles d’analyse d’images, résument au préalable l’image selon des caractéristiques définies par des experts, le Deep Learning construit lui-même ses caractéristiques d’analyse.

Le Deep Learning permet donc implicitement de répondre à des questions du type “que peut on déduire de ces données ?” et ainsi décrire des caractéristiques parfois cachées ou des relations entre des données souvent impossibles à identifier pour l’homme.

Nous disions plus tôt que passer des images sans les résumer à des réseaux de neurones serait trop complexe, et c’était le cas jusqu’en 2012 environ.

Même si leur origine remonte à aux années 90 avec Yann Le Cun, c’est donc au début des années 2010 avec les travaux de Geoffrey Hinton, que les algorithmes de Deep Learning ont commencé à démontrer leur efficacité.

Qu’est ce qui a changé ?

Cela est rendu possible par le partage de bases de données d’images catégories, qui permettent d’entraîner ces réseaux de neurones

Les architectures des réseaux de neurones se sont améliorés et la puissance de calcul disponible a grimpée en flèche (grâce au Cloud notamment).

Mais la plus grande révolution, c’est la disponibilité des données. En effet, le grand enjeu pour le Deep Learning (encore plus que pour le machine learning) reste la capacité à être correctement entraîné et à avoir à disposition un nombre virtuellement infini d’exemples pour parfaire le modèle à construire.

Dans l’exemple précédent, pour qu’un tel réseau de Deep Learning fonctionne, il faut un nombre très élevé d’exemples de photos catégorisées représentant des voitures et des motos.

Cela est rendu possible par le partage de bases de données d’images catégories, qui permettent d’entraîner ces réseaux de neurones (Image Net, par exemple).

Et concrètement ?

Plus ambitieux, le Deep Learning permet d’établir des relations et d’identifier des causes qui restent indétectable par l’homme.

Maintenant que le concept de Deep Learning est précisé, qu’est-ce que cela peut apporter ?

Evidemment, en allant dans le sens de l’exemple, analyser et décrire des images ou des vidéos pour faciliter des études ou automatiser des actions. Par exemple, pour un service client, être capable de préqualifier un défaut sur un produit, à partir de l’analyse automatique de la photo envoyée par le client insatisfait, en améliorant drastiquement le délai de traitement de sa demande.

Plus ambitieux, le Deep Learning permet d’établir des relations et d’identifier des causes qui restent indétectable par l’homme. On peut penser à un système de détection de fraudes avancées dans des contextes Big Data bancaires ou une optimisation de l’infrastructure de son informatique en fonction d’une demande qui serait anticipée par un réseau Deep Learning traitant en temps réel les actions des utilisateurs.

Enfin, le plus intriguant (et le plus étonnant), reste la capacité à transformer les réseaux Deep Learning en modèle génératif.

Le concept est simple : une fois le modèle entraîné (et donc les caractéristiques de traitement identifiées), on est en capacité d’inverser le processus en fournissant des entrées aux caractéristiques de traitement en sortie de réseau, pour obtenir une image originale.

Dans le cas de notre réseau qui permettait d’identifier motos et voitures, on peut imaginer lui fournir une information en entrée étant “Moto” et le voir créer des images originales de motos.

Une réponse à des pannes de créativité ou d’originalité dans le design des produits ?

Pour aller à la source, visitez https://www.tensorflow.org/ Un MOOC par Vincent Vanhoucke, Principal Scientist at Google Brain Team : https://www.udacity.com/course/deep-learning–ud730

Performance de projet et tableaux de bord

Objectifs

  • Comprendre ce qu’on appelle la performance d’un projet.

  • Identifier les différentes composantes de la performance d’un projet

  • Comprendre ce qu’est un indicateur de performance

  • Comprendre les buts et objectifs d’un bon tableau de bord

Notion de performance

Définition

Dans le domaine de la gestion de projet, la notion de performance peut donc être acceptée comme suit :

« … Est performance du projet tout ce qui, et seulement ce qui, contribue à atteindre les objectifs du projet ».

C’est donc une notion qui est empreinte de résultat.

Fondamental

Évoquer la performance induit donc que le jugement est porté sur :

  • L’efficacité (ou l’aptitude à atteindre l’objectif)

  • L’économie de coût voire l’efficience (maximiser par exemple la production à partir de quantités données de ressources, ou de minimiser ces dernières pour une production)

Le projet en tant que système

Rappel

Le projet est un système complexe, ouvert sur son environnement, avec des objectifs généraux subdivisés en objectifs sectoriels et en sous-objectifs.

Le « Projet système » reçoit des flux d’entrée et des flux de sortie.

Entre les deux flux, le projet système permet la transformation efficace entrées-sorties.

Le tableau de bord permet au pilote de réguler le système.

La nécessité de s’adapter aux évolutions de l’environnement

Rappel

Pour rendre le projet efficace et productif, il faut qu’il s’adapte aux évolutions et aux exigences de l’environnement.

Si la capacité d’adaptation est faible, le projet peut être confronté à 3 types de difficultés :

  • La sclérose

  • L’introversion

  • La crise

La performance de projet dans un cadre systémique

Définition

C’est un résultat positif obtenu par l’utilisation optimale des ressources mise en œuvre.

C’est une complémentarité entre trois niveaux :

  • La qualité réalisée ou recherchée

  • L’efficacité du travail

  • La productivité des ressources

Qui englobe cinq facteurs clés de succès :

  • La planification

  • La compétence

  • L’efficacité

  • L’esprit d ‘équipe

  • La recherche de l’innovation et du progrès

Le triangle d’or de la performance de projet

Fondamental

Pour assurer la recherche de performance il faut prendre en compte trois facteurs qui entrent dans la composition du « triangle d’or de la performance :

  • L’efficience

  • L’efficacité

  • La compétence

La performance une recherche d’équilibre

Fondamental

La performance est fonction de l’optimisation de la compétitivité.

Elle prend en compte les processus de recherche d’efficience dans le cadre de la réalisation du projet.

Elle souligne la recherche de l’efficacité.

De fait la performance est une combinaison de l’efficience, de l’efficacité et de la compétence.

L’absence d’un de ces trois éléments conduit à un manque de performance du projet.

 

Les composantes

Définition

L’efficacité renvoie à un objectif donné et indique si l’objectif a été atteint.

L’efficience désigne l’obtention d’un extrant donné à partir d’un minimum d’intrants.

Le rendement se réfère à l’efficience financière.

La productivité se réfère au degré d’efficience de la main-d’œuvre.

L’économie désigne l’acquisition de ressources selon les critères suivants: coût moindre, quantité et qualité conformes aux normes établies, moment et lieu opportuns.

L’interconnexion des composantes

Complément

Pertinence :

C’est le rapport entre les besoins, et en amont les constats d’où découlent ces besoins, et les objectifs assignés au projet.

Les objectifs du projet répondent-ils bien aux besoins ?

Cohérence :

C’est le rapport entre les objectifs à atteindre et le projet. Le projet est-il bien adapté ?

Réalité ou effectivité :

C’est le rapport entre ce qui est voulu et ce qui est réellement mis en œuvre

Efficience :

C’est le rapport entre les moyens, le projet, sa mise en œuvre et les résultats obtenus.

Les résultats sont-ils à la hauteur des moyens mis en œuvre par l’action ?

Efficacité :

C’est le rapport entre les objectifs et les résultats.

Les résultats attendus sont-ils atteints ?

Utilité :

Les effets et les impacts constatés répondent-ils aux problèmes posés ?

Vers une vision stratégique

Systèmes de mesure de la performance traditionnelle versus stratégique

Vision traditionnelle

Vision stratégique

Focalisation financière :

  • Orientation financière passée

  • Flexibilité limitée (un système sert à la comptabilité financière et à la comptabilité de gestion)

  • Pas de lien entre la stratégie et la gestion

Focalisation stratégique :

  • Performance orientée vers la satisfaction future des clients

  • Système dédié aux activités opérationnelles

  • Identifier les stratégies des concurrents

  • Système orienté vers l’apprentissage

Optimisation locale :

  • Faire baisser les coûts

  • Reporting vertical

Optimisation systématique :

  • Amélioration de la performance

  • Reporting horizontal

Fragmentation :

  • Les coûts, la production et la qualité sont considérés isolément

  • Il n’y a pas d’arbitrage entre ces données

Intégration :

  • Qualité, délais, temps et coûts sont évalués simultanément

  • Compensation systématique entre les indicateurs de performance

Apprentissage individuel :

  • Les bonus sont individuels

Apprentissage organisationnel :

  • Les bonus sont collectifs

La pyramide de la performance

Cette pyramide présente l’importance de la performance des projets dans le cadre d’une recherche de performance stratégique de l’organisation.

Dans ce contexte de performance stratégique, la performance de projet se définie à partir des points suivants :

  • Les objectifs du projet s’intègrent à une vision stratégique qui lui est supérieure

  • Les objectifs du projet prennent en compte les orientations et objectifs financiers de l’organisation, mais également les objectifs des clients

  • Les opérations qui suivent la mise en œuvre et le passage à l’opérationnel du projet permettent de vérifier que les objectifs stratégiques sont atteints en matière :

    • De satisfaction client

    • De flexibilité (délais de mise en œuvre)

    • De productivité (des ressources)

  • Les indicateurs de suivi et de contrôle de la performance sont déclinés selon quatre principes définis par les boucles de la performance

Le contrôle de la performance : les boucles de la performance

Ces boucles tentent d’identifier les lieux et moments du contrôle de la performance selon les différents niveaux de l’organisation et en intégrant une dimension projet dans le système organisationnel.

Boucle 1 : Performance opérationnelle

  • Principe du PDCA (Plan Do Control Act) ,

  • Suivi régulier et continu

  • Données non financières

Boucle 2 : Performance organisationnelle

  • Performance de la transversalité dans la démarche projet. Comment les différents services et départements fonctionnent entre eux,

  • Suivi mensuel ou trimestriel

  • Données économiques et financières

Boucle 3 : Performance Tactique

  • Permet de vérifier que la stratégie se traduit en projet et en opérations

  • Suivi annuel

  • Données financières, économiques et de résultats

Boucle 4 : Performance stratégique

  • Permet de vérifier la vision de l’organisation

  • Suivi Pluriannuelle

  • Données de résultats économiques et financiers

Conclusion

Il existe plusieurs types de performances dans une organisation, la performance de projet s’intègre entre la vision d’une performance stratégique et une vision de performance opérationnelle.

La mesure de la performance n’est pas que quantitative et financière.

La performance doit être abordée sous plusieurs aspects.

La description de la performance ne doit cependant pas évincer la performance financière.

Performance et équipe projet

Complément

Le développement de la performance d’une équipe projet repose sur trois points :

  • les compétences

  • les responsabilités

  • les ambitions

Cela induit :

  • Motivation et fidélisation

  • Cooptation et coopération

  • Responsabilisation et apprentissage collectif

  • Reconnaissance et confiance

Dans ce contexte, il faut rechercher la complémentarité et l’optimisation, les compétences, ambitions et responsabilités dans le cadre de l’équipe projet.

Performance et partenaires

Complément

La supply-chain

  • La prise en compte de la chaîne de valeur permet d’identifier les partenaires et d’intégrer une vision managériale globale de la chaine de valeur du projet.

  • Cela consiste en une flexibilité et une adaptabilité accrue du projet et une optimisation des échanges (approvisionnement, stocks, logistique,…)

La performance liée aux partenaires repose principalement sur les contrats.

Les contrats :

  • Clarté fond et forme

  • Exhaustivité

  • Cohérence

Typologie des contrats :

  • Par thèmes :

    • Méthodes

    • Outils

    • Techniques utilisées

    • Conforme ou non conforme

  • Par phase :

    • Cahier des charges,

    • Réalisation

    • Recette

    • Jugement

Performance et Système qualité : le triangle d’or des coûts, délais et qualité

Complément

Les délais

  • Qu’est ce qui justifie une action d’amélioration des délais au regard du système qualité ?

Les coûts

  • Comment maîtriser les coûts en restant conforme aux attentes du client

La qualité

  • Du zéro défaut à la satisfaction du client

  • Réduire l’écart entre la qualité voulue et la qualité perçue

Les principes des courbes en S et de l’Earn Value Management System

Fondamental

Cette méthode permet de croiser trois indicateurs pour mettre en exergue la liaison entre l’avancement de chaque activité individuelle et l’avancement du projet.

Définition

Les trois indicateurs sont :

  • AC : Actual Cost (ACWP) ou CR : Coût Réel (CRTE)

  • EV : Earned Value (BCWP) ou VA: Valeur Acquise (CBTE)

  • PV : Planned Value (BCWS) ou VP : Valeur Prévue (CBTP)

AC : Actual Cost (ACWP) ou CR : Coût Réel (CRTE)

  • Coût Réel de Travaux Effectués : Il représente le cumul de ce qui a été dépensé sur le projet. C’est la somme des coûts réels de chaque activité du projet.

EV : Earned Value (BCWP) ou VA: Valeur Acquise (CBTE)

  • Coût Budgété du Travail Effectué : elle représente le coût qui avait été budgété pour les travaux qui ont été effectués pendant la période.

PV : Planned Value (BCWS) ou VP : Valeur Prévue (CBTP)

  • Coût Budgété du Travail Prévu : la VP d’un projet représente la somme des VP de chaque activité.

La construction des courbes

Méthode

S Curve : la CBTP / BCWS ou VP

La courbe en S (VP) est construite en intégrant les dépenses liées aux ressources nécessaires pour réaliser le projet.

Elle se construit en réalisant la somme des plans de charge des ressources valorisées en unités monétaires.

S Curve : la CRTE / ACWP ou CR

La courbe en S (CR) est construite dès le début de la phase de réalisation et à partir du moment où les premiers relevés sont réalisés.

Elle se complète à chaque point d’avancement.

S Curve : la CBTE / ACWP ou VA

La courbe en S (VA) est établie en sommant les VA de chaque activité en cours.

Elle est construite dès le début de la phase de réalisation, à partir du moment où les premiers relevés d’informations sont réalisés.

Elle permet la comparaison entre la VP et le CR.

L’analyse à partir des courbes

MéthodeL’écart en production

S Curve : CR, VP et VA

Il mesure la valorisation de l’ensemble des travaux qui auraient dû être effectués et qui ne l’ont pas été (ou qui ont été effectués alors qu’ils n’auraient pas dû) à la date du point d’avancement.

MéthodeL’écart en coût

S Curve : CA, VP et VA

Il représente l’écart entre le coût des travaux réalisés et leur valorisation sur la base des budgets de référence.

Il présente les dérives budgétaires (positives ou négatives) rencontrées dans la gestion du projet.

MéthodeL’écart en délai

S Curve : CR, VP et VA

Cet écart représente la valorisation des travaux réalisés depuis le dernier point d’avancement (VA) au regard de cette quantité de travaux à la date à laquelle ils auraient dû être effectués.

Les indicateurs clés issus de la gestion de la VA

Méthode

1. Cost Variance (CV) : CV=VA-CR

Une valeur négative indique une surconsommation budgétaire et une valeur positive indique une sous-consommation budgétaire.

2. Schedule Variance (SV) : SV=VA-VP

Une valeur négative indique un retard et une valeur positive indique une avance.

3. Cost Performance Index (CPI) : CPI=VA/CR

Ce ratio désigne l’efficience en terme de coûts.

Une valeur inférieure à 1 indique une efficience plus faible que prévue.

4. Schedule Performed Index (SPI): SPI=VA/VP

Ce ratio désigne l’efficience en terme de délais.

Une valeur inférieure à 1 indique une efficience plus faible que prévue.

5. Estimate To Complete (ETC) : ETC=(BAC-VA)/CPI

Avec BAC (Budget At Completion) = coût total planifié.

La valeur obtenue est une estimation des coûts des travaux nécessaires pour finir le projet.

C’est une approche tendancielle qui intègre le facteur d’efficience (indicateur 3).

6. Estimate At Completion (EAC) : EAC=CR+ETC

C’est une estimation du coût total du projet qui intègre le facteur d’efficience.

Il permet de mesure la dérive des budgets initiaux.

e suivi transversal classique : Risques, enjeux et progrès

Complément

EVM et Gantt doivent être complétés par d’autres indicateurs de performance transversaux classiques qui permettent d’expliquer rapidement les dérives connues par le projet, et au delà des simples axes de coûts, délais et qualité.

Suivi des risques et performance

La seule certitude concernant un projet est qu’il ne se déroulera pas comme prévu. Il y a des risques.

Le risque est un danger potentiel, pas nécessairement prévisible et qui peut affecter les chances de succès d’un projet.

Les risques sont d’origines multiples et difficilement identifiables quant à leurs causes, leurs dates de survenance, leurs conséquences, et leur probabilité de réalisation.

La démarche utilisée est généralement la méthode AMDEC (Analyse des Modes de Défaillance, d’Echec et de Criticité).

ExempleExemple de table d’analyse des risques

Principaux risques :

  1. Instabilité du périmètre du projet

  2. Rejet d’utilisateurs

  3. Dépassement planning/budget

Suivi des enjeux et performance

Complément

«  Le désaccord entre les équipes de développement et les clients commanditaires, à propos de la finalité ou des performances des fonctionnalités installées est une des principales causes d’échec et d’arrêt prématuré des projets  » A. Fernandez 2012

La table de suivi des enjeux peut alors servir d’outils d’identification et de porté à connaissance des modifications des enjeux au par les partenaires et parties-prenantes du projet.

L’analyse des parties prenantes devient alors une base d’analyse en continu (diagramme à bulles, sociogramme,…)

ExempleExemple de table de suivi des enjeux

Voir document PDF.

ExempleExemple de tableau d’analyse des parties prenantes (PMBOK 5ème version)

Suivi du progrès et performance

Complément

  • Le système de suivi, au delà des indicateurs classiques, doit également prendre en compte tous les axes de progrès propres au projet.

  • Les axes de progrès constituent tous les axes d’amélioration qui participent au succès du projet.

  • Ces axes de progrès peuvent faire l’objet de tableaux de bord spécifiques prenant en compte les indicateurs clés de performance (KPI : Key Performance Indicators).

Définition des Indicateurs clés de Performance

Qu’est ce qu’un KPI ?

Définition

Les indicateurs clés de performance répondent au besoin de présenter des données techniques dans un langage compréhensible par tous les interlocuteurs et parties-prenantes du projet.

Un KPI est une information ou un ensemble d’informations permettant et facilitant l’appréciation, par un décideur, d’une situation donnée. C’est une mesure d’un aspect critique de la performance globale du projet.

Les indicateurs clés de performance :

  • Indiquent des taux, des quotients, des pourcentages et des moyennes et non pas des chiffres bruts

  • Utilisent des jauges, des thermomètres ou des « feux rouges » au lieu des histogrammes et des « camemberts »

  • Mettent les données dans leur contexte en fournissant des explications au lieu de les présenter de manière tabulaire.

  • Conduisent à la prise de décisions critiques aux stratégies de l’entreprise

Les bons indicateurs clés de performance induisent l’action.

Les types de KPI

Fondamental

On distingue généralement plusieurs types de KPI :

  • Les indicateurs d’alerte, définissant un seuil critique à ne pas franchir. Ils soulignent le niveau de normalité d’un système, d’un processus ou d’un projet.

  • Les indicateurs d’équilibre : ils permettent de vérifier l’adéquation entre l’objet d’étude (système, processus ou projet) et l’objectif attendu. Ils informent sur l’état du système et mettent en évidences les dérives potentielles.

  • Les indicateurs d’anticipation : ils permettent de mettre en exergue les éléments de prospective liés à un système, un processus ou un projet. Ce sont des indicateurs de tendance.

Le choix des KPI

Complément

Les facteurs de choix

Les facteurs d’échec

Un KPI doit être associé à un objectif clairement identifié et partagé par les directions concernées.

Utiliser le KPI comme moyen de sanction vis à vis des responsabilités concernées.

Un indicateur de performance induit une décision.

Les indicateurs de performance orientent les décisions.

Ne pas confondre l’effet et la cause.

L’utilisation des diagrammes d’Ishikawa peuvent éviter cette erreur.

Un indicateur de performance peut induire l’inaction dans le sens ou l’inaction est une décision.

Ne rien faire peut être une décision.

Changer les indicateurs en cours de réalisation…

Adapter les nouveaux indicateurs à ce qu’on veut montrer et non à ce qui se réalise.

Un KPI est une représentation simple d’une complexité.

Toutefois la complexité doit être explicite dans le mode de construction du KPI.

Les indicateurs sans élément de transversalité, non diffusables ou non compréhensifs.

Les indicateurs partiels, sans liens.

Le choix de KPI incombe aux utilisateurs de ces indicateurs.

Les décideurs doivent participer et/ou valider le choix de KPI.

Écouter les tentations du groupe dans la prise de décision.

La logique des indicateurs

Les indicateurs

Fondamental

Un indicateur de performance est un instrument lié à un critère d’évaluation de la performance. Il est la mesure :

  • D’un objectif à atteindre

  • D’une ressource mobilisée

  • D’une réalisation

  • D’un effet obtenu

Méthode

Mettre en rapport les questionnements et les outils pour réaliser l’évaluation de la performance.

ExempleCritère et indicateur

Question : dans quelle mesure la température est elle considérée comme satisfaisante ?

  • Objectif : 19°

  • Critère : Niveau de température

  • Indicateur : 22° Celsius

Définition

Un indicateur est :

  • Un descripteur

  • Une mesure pour quantifier ou qualifier un état, un effet ou une marge de progrès

  • Une information sur l’atteinte d’un objectif

  • Un outil de suivi et d’identification des changements

Fondamental

L’indicateur donne une représentation simplifiée d’une réalité complexe.

Il y a :

  • Les indicateurs de suivi et d’actualisation de l’état initial : ils se présentent sous la forme d’un tableau de bord, le référentiel. Ils sont liés à l’efficacité.

  • Les indicateurs de réalisation ou de performance : ils servent à mesurer l’effort réalisé et ses conséquences. Ils sont liés à l’efficience.

Comment les construire ?

Méthode

Ce qu’il ne faut pas faire :

  • Des d’indicateurs impersonnels (liés à une recherche d’exhaustivité et de standardisation) :

    • Une batterie d’indicateurs

    • Des indicateurs types

  • Des indicateurs cloisonnés :

    • Sans transversalité entre services

    • Sans lien avec le champ stratégique

  • Des indicateurs pertinents… mais ne pouvant pas être renseignés

Les bons indicateurs : les indicateurs SMART

  • Un indicateur Spécifique par rapport à l’objet (échelle, proximité, corrélation, …)

  • Un indicateur Mesurable (qualitatif ou quantitatif et non contestable)

  • Un indicateur Accepté et partagé (compréhensible et facilement interprétable)

  • Un indicateur Réaliste, c’est-à-dire qui prenne en compte le principe de réalité

  • Un indicateur Temporel et continu (reproductible dans le temps)

En fait, un indicateur facile à construire et à exploiter.

MéthodeMéthode de recentrage des indicateurs

Étape 1 : Processus d’identification

  • Recentrer les indicateurs selon l’objet et les axes à mesurer (ressources, …)

  • Vérifier les qualités des indicateurs présents

  • Supprimer les indicateurs non pertinents

  • Recenser les manques

  • Compléter les bases d’indicateurs

Étape 2 : Processus de description

Identifier les modes et processus de renseignement :

  • L’échelle (quoi)

  • La fréquence (quand)

  • Le détenteur d’information (où)

Le mode de construction de l’information :

  • Le support (tableau, carte, graphe,…)

  • Les structures de comparaison (visualiser l’évolution)

La collecte des informations :

  • Le processus

  • Le coût

  • La recevabilité

La responsabilisation :

  • Qui ?

  • Quand ?

  • Quoi ?

MéthodeLa mise en forme des indicateurs

Construire des fiches d’indicateurs :

  • Le nom

  • La fonction (préciser l’objet, à quoi il sert)

  • La méthode de construction

  • Les modes d’interprétation (comment il se lit)

  • Les indicateurs liés

Construire les supports :

  • Le tableau de bord / référentiel

  • L’outil informatique de collecte

  • L’outil informatique de gestion et d’exploitation

MéthodeValoriser l’indicateur

Les lieux d’utilisation :

  • Direction/ décideur

  • Services

  • Usagers

Les principes d’utilisation :

  • Communication

  • Aide à la décision

  • Réorientation de l’action

Les types d’indicateurs

Complément

Les niveaux d’indicateurs

Les indicateurs de cohérence :

  • Principes généraux / objectifs stratégiques

  • Objectifs stratégiques / objectifs opérationnels

  • Objectifs opérationnels / moyens humains / moyens financiers / moyens techniques

Les indicateurs d’efficacité :

  • Objectifs / délais de réalisation

  • Objectifs / coûts de réalisation

  • Objectifs / résultats de réalisation

Les indicateurs d’efficience :

  • Moyens humains / délais de réalisation / coûts de réalisation

  • Moyens financiers / délais de réalisation / résultat de réalisation

  • Moyens institutionnels / délais de réalisation

La question qui se pose est la différence entre ce qui est suffisant ou juste nécessaire.

Les indicateurs de pertinence :

  • Objectifs / logiques des autres acteurs

  • Objectifs / état de la ressource / usages – besoins (CT/MT/LT)

  • Moyens financiers / état de la ressource / usages – besoins (CT/MT/LT)

  • Moyens institutionnels / logiques des autres acteurs

  • Moyens techniques / usages – besoins

    Le rôle des KPI dans le processus de décision

    Fondamental

    Alain Fernandez 2012

    La mesure de la performance est un outil d’assistance et d’anticipation.

    L’information pour la prise de décision doit être :

    • Formulée rapidement

    • Disponible rapidement

    • Exploitable rapidement

    La support de la décision est le KPI, son support de présentation est le tableau de bord, dont le but est de mettre à la disposition de la direction du projet et du chef de projet un nombre limité d’indicateurs variés, regroupés sous la forme d’un tableau de bord, afin de les aider dans leurs prises de décisions vis-à-vis du projet.

    Qu’est-ce qu’un tableau de bord ?

    Définition

    Définition

    « C’est un système d’information permettant de connaître en permanence et le plus rapidement possible les données indispensables pour contrôler la marge de l’entreprise à court terme et faciliter celle ci dans l’exercice des responsabilités. » Michel Gervais

    Les tableaux de bord sont des supports informatifs présentant des informations de synthèse, qui doivent permettre d’évaluer la progression du projet et l’atteinte des objectifs à l’aide d’indicateurs.

    Le tableau de bord facilite le pilotage du projet ou des lots. Il favorise l’analyse des tendances permettant ainsi d’anticiper l’évolution du projet.

    Cet outil sert au chef de projet qui est à l’origine de la documentation du projet et qui doit s’en servir comme un instrument de contrôle et de prévisions, mais également au comité de pilotage qui doit recevoir les tableaux de bord.

    Conseil

    Cinq principes doivent être respectés :

    1. Mettre en place son propre système de gestion et son propre circuit de relations en définissant d’abord de quoi on a besoin.

    2. Formaliser et figer les documents.

    3. Décider de la périodicité des mises à jour et s’y tenir.

    4. Les tableaux de bord doivent vivre depuis le début du projet jusqu’à sa fin.

    5. Le pilotage est avant tout humain. Il repose sur une bonne circulation de l’information au plus près du terrain.

    Complément

    Il y a trois types d’informations sur un projet.

    Informations de base :

    • “Où on désire aller“

    • Ordres spécifiant ce qu’il faut faire, mais théoriques

    Informations d’avancement :

    • “Où on en est“

    • Constats d’avancement, mais information de nature passive

    Informations prévisionnelles :

    • “Où on va si on continue“

    • Elles rapprochent de la réalité et du terrain, elles servent directement au pilotage du projet.

    C’est un outil de suivi, dont les caractéristiques sont :

    • Une approche souple, capable d’évoluer et de s’adapter

    • Une information obtenue dans des délais rapides et proches de l’action

    • Reflétant une performance

    La finalité de cet outil est donc de piloter le projet et d’en évaluer la performance.

    Tableau de bord, système d’information et reporting

    Définition

    Le tableau de bord est un :

    • Outil de contrôle pendant l’action

    • Outil de communication entre responsables

    • Outil de prise de décision

    • Outil de motivation pour les collaborateurs

    • Instrument de veille

    Ils s’inscrivent en complémentarité des outils de reporting et des systèmes d’information.

    Définition

    Le reporting désigne l’ensemble des informations relatives aux réalisations d’une période préparé pour un niveau de responsabilité supérieur.

    Reporting

    Tableau de bord

    Après l’action (pour la hiérarchie)

    Pendant l’action

    Il existe des similitudes entre le reporting et le tableau de bord mais les deux sont distincts. On peut identifier les similitudes suivantes (selon Jack Gray et Yvon Pesqueux) :

    • Les deux sont des outils d’aide à la décision, regroupant un ensemble d’indicateurs, mesurant l’objectif. Ils recherchent les causes et les tendances des faits.

    • Le reporting et le tableau de bord permettent de mesurer la performance. Le reporting groupe évaluera plus spécifiquement la performance globale.

    • Le reporting comprend des indicateurs de résultat destinés à la hiérarchie, le tableau de bord fait état d’indicateurs multicritères pour tout responsable.

    Exemple

    Définition

    Le système d’information est une base de données qui regroupe toutes les informations de gestion de l’entreprise et qui est capable de restituer les informations en temps réel aux utilisateurs.

    Base de données d’informations

    Management Information System

    Tableau de bord

    Informations relatives à la gestion

    Information importantes et synthétiques du système d’information

    Éléments de construction

    Méthode

    La structure d’un tableau de bord dépend de :

    • L’environnement du projet (le scope)

    • L’intégration du projet dans l’entreprise (son organisation)

    • Des responsables du projet

    La démarche de construction est résumée dans le schéma suivant et selon quatre étapes :

    Comment définir les objectifs ?

    • Les objectifs sont à définir avec le responsable

    • Ils porteront sur les résultats attendus du projet, sur les activités et les ressources critiques pour atteindre ces objectifs

    L’objectif doit être :

    • Clairement rédigé et précis

    • Quantitatif ou qualitatif

    • Concrétisé par une seule action

    • Réaliste, réalisable et relativement souple

    Comment retenir les points-clefs du projet ?

    • Identifier les éléments relevant du champ d’activité du projet conduisant à la réalisation des objectifs

    • Définir et choisir des critères caractéristiques pour produire un ensemble synthétique.

    Comment recenser les indicateurs ?

    Comment choisir les indicateurs ?

    Comment tester un indicateur ?

    • Analyse de sa signification

    • Étude des actions qu’il induit

    • Étude de son équité

    • Étude de sa fiabilité

    Exemple

    Mission

    Point-clé

    Paramètres

    Indicateurs

    Niveau

    Gérer la ressource humaine

    Adapter les effectifs aux programmes de production

    Variation des effectifs

    (Effectif du mois M) – (Effectif du mois M-1)

    < 20%

    Obtenir un certain rendement

    Cadence à respecter

    Quantités produites

    Les heures de travail effectif

    < 2%

    Coût service

    Coût de fonctionnement

    Coût de fonctionnement mensuel

    Effectif du mois

    < 5%

    Représentation d’indicateurs

    Définir les objectifs de l’unité utilisatrice du tableau de bord.

    Retenir les éléments importants permettant d’atteindre l’objectif, influençant le résultat.

    Écarts : différence entre réalisation et prévision.

    Ratios : rapport entre deux grandeurs significatives de la structure d’organisation de l’entreprise.

    Graphiques : ils servent à visualiser rapidement et directement les évolutions, et appréhender directement les changements de rythme ou tendance.

    Il existe plusieurs types de graphiques :

    • Simple

    • En banderole

    • Circulaire

    • En bâtonnets

    • Tuyaux d’orgue

    • Courbe cumulative

    • Gantt

    • Coordonnées polaires

    Clignotants : ce sont des seuils limites, des normes (correspondant le plus souvent à l’objectif) :

    • Pour attirer l’attention des responsables par le fait qu’ils s’allument

    • Pour témoigner d’une anomalie, d’une dégradation ou d’un écart par rapport à l’objectif

    • Pour concentrer l’action sur l’urgent et l’essentiel

La méthode imparable pour augmenter votre chiffre d’affaires en exploitant les données de votre site.

Dans toute entreprise, évaluer le succès de vos campagnes marketing est essentiel pour démontrer leur efficacité à vos commerciaux ou votre hiérarchie. Pour vous y aider, il est important de définir des indicateurs (KPI) et de les analyser en continu pour analyser les performances de vos actions.

Voici donc 10 KPI marketing sur lesquels vous devriez vous pencher :

 

1- Le trafic de votre site web

Pour toute entreprise disposant d’un site web, connaître son trafic est un indicateur essentiel. Il indique combien de personnes viennent visiter votre site chaque jour, semaine, et mois, et en traquant les sources de trafic, vous pouvez évaluer les performances de chaque canal amenant des visiteurs. On distingue plusieurs types de trafic :

  • Le trafic direct, soit les visiteurs qui viennent après avoir tapé directement votre url dans un moteur de recherche
  • Le trafic référent qui provient de liens sur d’autres sites que le vôtre
  • Le trafic organique qui amène les visiteurs ayant trouvé votre entreprise suite à une recherche internet
  • Le trafic payant provenant de sources publicitaires payantes (Adwords, bannières publicitaires, etc.)

kpi : mesure de perfromance2- Le référencement naturel

Il s’agit d’une des sources de trafic pouvant être améliorées dans le temps à moindre coût. En créant régulièrement des contenus avec les bons mots-clés renvoyant à vos activités, ou des contenus adaptés au profil de vos cibles, vous augmenterez mois après mois le trafic organique sur votre site web. Alors que les visiteurs provenant des campagnes de référencement payant disparaissent lorsque vous cessez de payer pour les avoir, le trafic provenant du référencement naturel se développe en continu, dans la durée.

3- Les taux de conversion

Quand des personnes visitent une page web dotée d’un formulaire de contact, deux chois s’offrent à eux : partager leurs coordonnées en échange du contenu que vous leur proposez, ou quitter la page et partir ailleurs. Un formulaire rempli et validé est une conversion.

Suivre les taux de conversion de vos formulaires vous permet d’identifier quelles pages, articles, contenus, offres sont les plus populaires auprès de vos visiteurs. Cela vous aidera également à définir la direction à prendre pour créer vos prochains contenus.

4- Les leads

Les visiteurs qui remplissent des formulaires en échange de contenus sont appelés « leads ». En suivant ces leads, il est alors possible d’entamer un processus de lead nurturing. Cela consiste à les alimenter régulièrement et dans la durée en contenus informatifs sur leur secteur d’activité, des réponses à leurs problématiques, les réponses apportées par vos offres, et peu à peu les préparer à engager une relation commerciale avec votre entreprise.

5- Les leads marketing qualifiés

Il s’agit des leads correspondant au profil type de votre cible et ayant montré un intérêt spécifique pour votre offre de solutions. Par exemple, des personnes ayant lu une étude de cas client puis ayant téléchargé une fiche produit sont des leads marketing qualifiés. Ils ont montré un intérêt manifeste pour votre entreprise et demandent à être suivis de prêt pour les engager commercialement.

6- Les leads commerciaux qualifiés (ou leads chauds)

Il s’agit de leads répondant aux critères des leads marketing qualifiés mais qui ont également montré qu’ils étaient prêts à un acte d’achat. Il s’agit par exemple de prospects ayant atteint le fond de l’entonnoir de conversion (funnel) en demandant un essai gratuit de votre solution ou une démonstration. Ces leads doivent être identifiés rapidement et transmis à l’équipe commerciale pour conclure l’affaire.

7- Le coût d’acquisition client (CAC)

Le CAC se réfère à l’investissement réalisé pour générer un nouveau client. Ce dernier est un indicateur important pour comparer les coûts d’acquisition résultant de différentes stratégies marketing et évaluer les plus efficaces. Vous pouvez par exemple comparer le coût d’acquisition client entre des stratégies inboundet outbound.

8- Le « Churn »

Le « Churn » se réfère au ratio de clients ou de chiffre d’affaires existants perdus par votre entreprise au fil du temps. En effet, tous les clients ne restent pas fidèles… C’est un indicateur important, en particulier pour les entreprises dont le modèle économique est basé sur des abonnements, telles les sociétés proposant des offres en SaaS (Software As A Service). L’idéal est d’avoir un taux de « Churn » le plus faible possible.

9- La Customer Lifetime Value (CLV)

La CLV est une notion essentielle de la connaissance client. Elle désigne la valeur, les profits, que génère un client tout au long de sa relation avec une entreprise. Comparer la CLV et le CAC vous permet facilement de commencer à analyser le rapport coût/efficacité de votre stratégie marketing. Si votre CLV n’est pas 2 à 3 fois supérieure à votre CAC, c’est que vous avez un sérieux problème…

10- Le ROI marketing

Le ROI marketing, également appelé ROMI (Return On Marketing Investment) vous permet de comparer votre investissement marketing total avec le chiffre d’affaires qu’il génère. C’est le plus important des indicateurs à suivre en marketing B2B. Il vous permet d’évaluer votre stratégie marketing en termes de coûts et bénéfices comptables.

Mesurer le ROI marketing vous permet de comparer de nouvelles stratégies avec d’autres plus anciennes, d’évaluer et d’améliorer l’évolution de vos performances. L’objectif est de savoir, pour un euro dépensé en marketing, combien cela rapporte à l’entreprise.