Skip to content

Blogs de Développeurs: Aggrégateur de Blogs d'Informatique sur .NET, Java, PHP, Ruby, Agile, Gestion de Projet

Forum Logiciel

Forum Logiciel : diffusion de connaissance et d’informations sur toutes les activitĂ©s liĂ©es au dĂ©veloppement d’applications informatiques en entreprise.

Le blog d'OCTO Technology, cabinet d'architectes en systĂšmes d'information
Syndiquer le contenu
Le blog d'OCTO Technology, cabinet d'architectes en systĂšmes d'information
Mis à jour : il y a 4 heures 27 min

[Tribune] Money2020 Europe, ou le réveil des banques européennes

lun, 07/10/2017 - 09:33

La confĂ©rence Money2020 Europe s’est tenue Ă  Copenhague fin juin. Cet Ă©vĂ©nement, arrivĂ© l’annĂ©e derniĂšre des Etats-Unis, se prĂ©sente comme le plus grand rendez-vous europĂ©en de l’innovation dans les services financiers. La keynote d’ouverture a donnĂ© la parole aux CEOs de trois grands acteurs bancaires europĂ©ens qui ont dĂ©taillĂ© leur vision des transformations en cours dans ce secteur. Compte rendu de ces discours qui pourraient inspirer les dirigeants français.

Retrouvez la suite de notre tribune sur Maddyness.com >

Articles suggested :

  1. Suivez la série OCTO Technology « La banque de demain »: quelles évolutions pour le modÚle bancaire ?
  2. FinTech – Hugues Le Bret : « Nous sommes une entreprise technologique qui offre Ă  tous les moyens de se faire payer et de payer en temps rĂ©el »
  3. Faut-il ĂȘtre schizophrĂšne pour Innover dans un grand groupe et en particulier dans les banques ?

Catégories: Blog Société

[Tribune] Money2020 Europe, ou le réveil des banques européennes

lun, 07/10/2017 - 09:33

La confĂ©rence Money2020 Europe s’est tenue Ă  Copenhague fin juin. Cet Ă©vĂ©nement, arrivĂ© l’annĂ©e derniĂšre des Etats-Unis, se prĂ©sente comme le plus grand rendez-vous europĂ©en de l’innovation dans les services financiers. La keynote d’ouverture a donnĂ© la parole aux CEOs de trois grands acteurs bancaires europĂ©ens qui ont dĂ©taillĂ© leur vision des transformations en cours dans ce secteur. Compte rendu de ces discours qui pourraient inspirer les dirigeants français.

Retrouvez la suite de notre tribune sur Maddyness.com >

Articles suggested :

  1. Suivez la série OCTO Technology « La banque de demain »: quelles évolutions pour le modÚle bancaire ?
  2. FinTech – Hugues Le Bret : « Nous sommes une entreprise technologique qui offre Ă  tous les moyens de se faire payer et de payer en temps rĂ©el »
  3. Faut-il ĂȘtre schizophrĂšne pour Innover dans un grand groupe et en particulier dans les banques ?

Catégories: Blog Société

Versionning d’API, Zero Downtime Deployment et migration SQL : thĂ©orie et cas pratique

jeu, 07/06/2017 - 08:29

Pour démythifier le Zero Downtime Deployment

Dans les patterns associĂ©s aux gĂ©ants du web, le Zero Downtime Deployment (ZDD) partage une caractĂ©ristique avec l’auto-scaling : on en parle d’autant plus qu’ils sont peu mis en Ɠuvre.

Le ZDD est victime d’un cercle vicieux : il a l’air trĂšs complexe car il est peu pratiquĂ©, et comme il est peu pratiquĂ©, on pense qu’il est trĂšs complexe.

Pour sortir de cette impasse, cet article prĂ©sente un cas pratique, code Ă  l’appui.

L’objectif n’est pas que tout le monde fasse du ZDD, car on verra qu’il ajoute du travail et de la complexitĂ©, mais que vous vous en ayez une vision claire. Cela vous permettra de pouvoir dĂ©cider d’en faire ou pas en connaissance de cause.

Notre cas d’exemple

Notre exemple s’approche de celui dĂ©crit dans le premier article.

Soit une application exposée via une API REST.

Au dĂ©part cette application gĂšre des personnes, chaque personne ayant zĂ©ro ou une adresse. Cette version est exposĂ©e sur le prĂ©fixe /v1 Ă  l’aide d’un unique type de ressource /person.

La version suivante de l’application permettra d’associer plusieurs adresses Ă  une personne, et sera exposĂ©e sur le prĂ©fixe /v2 en utilisant deux ressources, /person et /address.

Les deux versions

Cette application met en avant sa haute disponibilité, il est donc primordial que toutes les opérations soient effectuées sans interruption de service.

L’API est publique, nous ne maĂźtrisons donc pas l’utilisation qui en est faite. Il est donc impossible de faire une bascule de /v1 Ă  /v2 en une seule fois. Les deux versions devront donc fonctionner ensemble le temps de permettre la migration de tous les utilisateurs. Cette pĂ©riode pouvant ĂȘtre trĂšs longue suivant les cas.

Les clients consomment les API via des intermédiaires, il est donc possible que pendant cette période ils utilisent à la fois les versions /v1 et /v2.

Dans la suite de l’article, /v1 et /v2 correspondent aux versions des services, et v1 et v2 correspondent aux deux maniĂšres dont les donnĂ©es seront stockĂ©es en base.

La stratégie Comment gérer la migration ?

Il est possible de se passer complĂštement de script de migration au sens traditionnel : vous exposez les services en /v2, et, lorsqu’ils sont appelĂ©s pour une donnĂ©e encore au format /v1, vous migrez la donnĂ©e Ă  la volĂ©e. Cela permet de migrer les donnĂ©es petit Ă  petit au fur et Ă  mesure que les utilisateurs des services appelleront les APIs /v2. C’est l’approche qui est souvent prise avec les bases de donnĂ©es NoSQL.

Malheureusement, en procédant ainsi, il est possible que la migration ne se termine jamais, ou alors seulement dans trÚs longtemps (si vous purgez les données trop anciennes). Pendant ce temps, vous devez maintenir le code supplémentaire permettant de prendre en charge ce cas.

L’autre approche est d’utiliser un script. Cela permet de faire en sorte que la migration se fasse rapidement. C’est le mĂȘme type de script que vous utilisez pour vos migrations habituelles, sauf qu’il doit prendre en compte le fait qu’il s’exĂ©cute en mĂȘme temps que le code. Ainsi toutes les opĂ©rations qui crĂ©ent des verrous pendant plus de quelques millisecondes ne doivent pas ĂȘtre utilisĂ©es, et il faut s’assurer de ne pas crĂ©er d’interblocage.

La migration doit se faire de maniĂšre transactionnelle, pour Ă©viter d’introduire des incohĂ©rences dans les donnĂ©es. En cas de problĂšme, le script doit Ă©galement pouvoir ĂȘtre interrompu et relancĂ© sans que cela ne perturbe l’exĂ©cution du programme.

Dans l’article c’est cette approche que nous allons utiliser.

Quand migrer ?

Sans ZDD, le process de migration est classiquement le suivant :

  1. Fermer le service
  2. ArrĂȘter l’application
  3. Faire un backup des données, pour pouvoir les restaurer en cas de problÚme
  4. Migrer les données
  5. DĂ©ployer la nouvelle version de l’application
  6. DĂ©marrer la nouvelle version de l’application
  7. VĂ©rifier que tout fonctionne bien
  8. Ouvrir le service

En ZDD, plus question de fermer le service : la migration de données a lieu « à chaud ».

Il y a deux maniùres possibles de s’y prendre, suivant que la migration a lieu avant ou aprùs l’ouverture des services /v2 :

Les deux maniĂšres de migrer

NumĂ©ro de l’étape Version du code Migration aprĂšs l’ouverture de /v2 Migration avant l’ouverture de /v2

1

1

Application servant /v1 avec un modÚle de de donnée v1

2

1

Modifier le schéma de BDD pour permettre de stocker les données nécessaires à /v2

3

2

DĂ©ployer une nouvelle version de l’application exposant /v1 et /v2 sur les modĂšles de donnĂ©e v1 ou v2

DĂ©ployer une nouvelle version de l’application exposant /v1 sur les modĂšles de donnĂ©e v1 ou v2

4

2

Migrer les données au modÚle v2 sans interruption de service, en tenant compte du code /v1 et /v2

Migrer les données au modÚle v2 sans interruption de service, en tenant compte du code qui sert /v1

5

3

DĂ©ployer une nouvelle version de l’application exposant /v1 et /v2 sur le modĂšle de donnĂ©e v2

6

3

Nettoyer le schéma de BDD des artefacts v1

7

4

DĂ©ployer une nouvelle version de l’application gĂ©rant /v2 sur le modĂšle de donnĂ©e v2

La premiĂšre approche permet d’ouvrir les services /v2 plus rapidement car il n’y a pas besoin d’attendre la migration des donnĂ©es.

La seconde approche est plus simple :

  • la version exposant de l’application fonctionnant avec les modĂšles de donnĂ©es v1 et v2 n’expose que les services /v1, vous faites ainsi l’économie du cas oĂč un appel de service /v2 accĂšde Ă  des donnĂ©es v1 ;
  • pendant la migration de donnĂ©es, les services /v2 ne sont pas encore exposĂ©s, cela veut dire moins de patterns d’accĂšs aux donnĂ©es Ă  prendre en compte pour dĂ©signer une migration Ă©vitant les incohĂ©rences de donnĂ©es et les interblocages.

Sauf si votre process de migration est extrĂȘmement long, la seconde approche est Ă  privilĂ©gier, et c’est celle qui sera utilisĂ©e dans la suite de l’article.

/v1 et /v2 sont dans un bateau 


Les migrations d’APIs ouvertes posent deux problĂšmes mĂ©tier et un problĂšme technique.

Comment migrer les données ?

Le premier problĂšme, valable aussi pour les API fermĂ©es, est de savoir comment migrer les donnĂ©es de /v1 Ă  /v2. Je ne parle pas d’un point de vue technique mais bien d’un point de vue mĂ©tier : la sĂ©mantique change entre les deux versions, il faut donc dĂ©terminer comment transformer les donnĂ©es de /v1 en /v2 d’une maniĂšre qui soit logique et qui ne surprenne pas les utilisateur·rice·s de l’API.

Dans notre cas la solution est immĂ©diate : /v1 a au plus une seule adresse, et /v2 peut en avoir plusieurs, l’adresse de /v1 devient donc une des adresses de /v2.

Comment gérer la rétro-compatibilité ?

L’autre problĂšme est de savoir comment interprĂ©ter en /v1 des donnĂ©es /v2. En effet si l’API est ouverte, vos utilisateur·rice·s peuvent appeler vos services /v1 alors que les donnĂ©es sont dĂ©jĂ  au modĂšle /v2.

Il est souvent plus compliquĂ© que le premier car au fur et Ă  mesure des Ă©volutions, les API ont tendance Ă  devenir plus riches. AccĂ©der Ă  des donnĂ©es plus riches de la /v2 au travers du prisme plus Ă©troit de l’API /v1 peut ĂȘtre un vrai casse-tĂȘte.

Si c’est le seul moyen que cette transition se passe bien, il est parfois nĂ©cessaire d’adapter le design de l’API /v2.

C’est un Ă©quilibre Ă  trouver entre la facilitĂ© de transition, des restrictions possibles Ă  ajouter pour les appelants de l’API, et le temps Ă  investir.

Comment répondre vite et bien ?

Le problĂšme technique est de parvenir Ă  rendre les diffĂ©rents services, y compris la compatibilitĂ©, tout en s’assurant de toujours avoir des donnĂ©es cohĂ©rentes et sans (trop) pĂ©naliser les performances. Si, entre les deux versions, les donnĂ©es ne sont plus structurĂ©es de la mĂȘme maniĂšre, la gestion de la compatibilitĂ© peut demander de croiser les donnĂ©es de plusieurs tables.

Ainsi dans notre exemple, en v1 les adresses sont stockĂ©es dans la table person alors qu’en v2 elles sont dans une table address sĂ©parĂ©e. Pendant la pĂ©riode de compatibilitĂ©, il faut que les appels Ă  v1 qui mettent Ă  jour le nom de la personne et son adresse modifient les deux tables de maniĂšre transactionnelle pour Ă©viter qu’une lecture v1 qui se produirait au mĂȘme moment ne renvoie des donnĂ©es incohĂ©rentes. De plus, il faut parvenir Ă  le faire sans avoir Ă  poser trop de verrous en base de donnĂ©es, car cela raletit les accĂšs.

La meilleure stratĂ©gie est de privilĂ©gier une approche que vous maĂźtrisez bien et qui donne des rĂ©sultats acceptables plutĂŽt qu’une solution plus efficace ou plus rapide mais plus complexe.

Dans tous les cas, des tests sont absolument essentiels.

Pour servir les deux versions de l’API, vous pouvez utiliser une application unique ou choisir de sĂ©parer votre code en deux applications, une par version de services. Cette question n’étant pas structurante pour la question du ZDD, nous choisissons de ne pas la traiter ici. Dans notre exemple, nous avons choisi de n’avoir qu’une seule application.


 et ZDD les rejoint à bord

Sans ZDD la situation est claire : on arrĂȘte l’application, les donnĂ©es sont migrĂ©es, et on redĂ©marre l’application dans la nouvelle version. Il y a donc un avant et un aprĂšs.

Avec ZDD la migration s’effectue Ă  chaud pendant que les services sont disponibles, s’ajoute une situation intermĂ©diaire.

Pendant cette pĂ©riode, les donnĂ©es peuvent donc ĂȘtre encore stockĂ©es au format /v1 ou migrĂ©es au format /v2.

Il faut alors parvenir Ă  dĂ©terminer dans quel Ă©tat sont les donnĂ©es : pour savoir quel code doit ĂȘtre appelĂ© il faut savoir si la donnĂ©e a Ă©tĂ© migrĂ©e ou pas. De plus, le morceau de code en charge de cela va ĂȘtre exĂ©cutĂ© trĂšs souvent, il doit donc ĂȘtre trĂšs efficace.

En cas de difficultĂ©, la solution qui devrait fonctionner dans tous les cas est d’ajouter dans les tables impliquĂ©es un numĂ©ro indiquant la « version de schĂ©ma » de la donnĂ©e correspondante, et qui sera incrĂ©mentĂ© lors de la migration de la donnĂ©e. Dans ce cas l’opĂ©ration de vĂ©rification est trĂšs simple et rapide. L’opĂ©ration d’ajout de colonne est alors Ă  faire en avance de phase, ce qui augmente le travail nĂ©cessaire Ă  la migration.

Si vous choisissez de faire la migration de donnĂ©es aprĂšs l’ouverture de /v2, s’ajoute le cas oĂč on appelle une api /v2 alors que la donnĂ©e est encore stockĂ©e au format v1. Il faut alors migrer la donnĂ©e Ă  chaud, de maniĂšre transactionnelle en limitant les ralentissements induits.

Pour résumer, il y a quatre situations :

Appel /v1 Appel /v2

Données stockées au format v1

RĂ©pondre comme auparavant

(Seulement si migration aprÚs ouverture de /v2) Migrer les données à chaud

Données stockées au format v2

Compatibilité v1

Répondre avec la nouvelle sémantique

Bien ouvrir /v2, et bien décomissionner /v1

Lorsque vous ouvrez /v2 pour la premiĂšre fois, faites-attention Ă  la maniĂšre dont la bascule vers la nouvelle version est faite.

Avant de rendre les nouveaux endpoints accessibles, assurez-vous que tous les serveurs utilisent la derniĂšre version de l’application. Dans le cas contraire, si vous appelez un /v1 alors que la donnĂ©e correspondante a Ă©tĂ© migrĂ©e en v2 le code ne saura pas la lire correctement et risque de planter ou de renvoyer une information fausse.

Un autre problÚme se pose suivant la maniÚre dont vous avez implémenté les modifications de donnée lorsque vous appelez une API /v1.

Le premier cas consiste Ă  sauvegarder la donnĂ©e au format v2, mais cela veut dire qu’à nouveau, les versions prĂ©cĂ©dentes de l’application ne pourront pas la lire. La solution la plus simple est alors d’utiliser le feature flipping pour faire basculer le code.

Dans le cas contraire, votre code doit dĂ©tecter sous quel format la donnĂ©e est stockĂ©e, et la resauvegarder sous ce mĂȘme format : une donnĂ©e v1 reste en v1, et une donnĂ©e v2 reste en v2.
On Ă©vite le feature flipping, mais en Ă©change le code est plus complexe.

Pour décomissionner /v1 il suffit de rendre les endpoints inaccessibles, la suppression du code peut se faire plus tard.

À propos des verrous et des modifications de schĂ©mas

Comme on vient de le voir, le ZDD s’appuie beaucoup sur l’utilisation de la base de donnĂ©es, et notamment ses fonctionnalitĂ©s d’accĂšs concurrent. Si vos comportements mĂ©tiers sont simples, que vous utilisez un ORM, et que vous avez des tests de performances automatisĂ©s, il s’agit d’un domaine auquel vous n’avez pas souvent Ă  vous intĂ©resser. Si vous vous y prenez mal, il est facile de bloquer la base, renvoyer des erreurs (en cas d’interblocage), ou des rĂ©sultats incohĂ©rents.

Notre conseil est de bien vous documenter en amont voire de faire des POC pour Ă©viter d’avoir Ă  refaire un design parce que votre base de donnĂ©es ne fonctionne pas comme vous l’imaginiez. Ne faites pas confiance Ă  des souvenirs ou Ă  des rumeurs : lisez en dĂ©tail la documentation correspondant Ă  la version de l’outil que vous utilisez, et surtout testez !

Si vous n’avez jamais creusĂ© ces sujets ou que vous ĂȘtes rouillé·e, la premiĂšre migration vous demandera sĂ»rement pas mal de travail, et vous donnera quelques sueurs froides lorsque vous l’exĂ©cuterez. Mais dites-vous que toutes les opĂ©rations suivantes manipuleront les mĂȘmes concepts, et se passeront donc beaucoup mieux.

Il n’y a pas que le REST dans la vie

REST possÚde deux caractéristiques qui en font un candidat idéal pour le ZDD :

  • exposer plusieurs versions de services est une pratique standard ;
  • les appels sont supposĂ©s ĂȘtre sans Ă©tat.

Si vos services sont exposĂ©s d’une autre maniĂšre, il faudra donc vous intĂ©resser Ă  ces sujets. Les sessions, comme tous les types de cache, peuvent demander une attention particuliĂšre si les donnĂ©es qu’elles contiennent font l’objet d’un changement de structure entre versions.

Retour Ă  notre exemple

Nous prenons l’hypothĂšse oĂč le modĂšle de donnĂ©es suit directement les ressources Ă  exposer. L’adresse est initialement un champ de la table person, et est migrĂ©e dans une table address distincte.

L’évolution du schĂ©ma

Nous n’utilisons pas de colonne spĂ©cifique pour stocker la « version de schĂ©ma » des objet. À la place nous allons vĂ©rifier en base la maniĂšre dont les donnĂ©es sont stockĂ©es : si la table person contient une adresse, c’est qu’elle est en version v1, sinon il faut vĂ©rifier l’existence d’une adresse dans la table dĂ©diĂ©e. Cela Ă©vite d’alourdir le schĂ©ma SQL, mais augmente le nombre de requĂȘtes exĂ©cutĂ©es.

Les Ă©tapes Ă  suivre pour la migration :

  1. Version initiale : l’adresse est dans la colonne address de la table person, le code ne sait fonctionner que de cette maniùre.
  2. Ajout de la nouvelle table address dans la base de données, à cette étape le code ne connaßt pas encore cette table.
  3. DĂ©ploiement du code qui fournit l’api /v1 et qui est compatible avec les deux maniĂšres de stocker l’adresse.
  4. Exécution du script de migration.
  5. DĂ©ploiement du code qui fournit les api /v1 et /v2 et qui est compatible avec la nouvelle maniĂšre de stocker l’adresse, la colonne address de la table person n’est plus utilisĂ©e par le code.
  6. Suppression de la colonne address de la table person.

Le ZDD a pour consĂ©quence d’ajouter des versions de code et des migrations de schĂ©mas intermĂ©diaires. Dans un environnement oĂč les dĂ©ploiements ne sont pas automatisĂ©s, cela signifie une augmentation de la charge de travail et donc du risque d’erreur. Mieux vaut donc s’outiller et disposer d’un pipeline de livraison fiable avant de se lancer.

Analyse détaillée La compatibilité des services

Dans notre exemple le problĂšme de compatibilitĂ© est le suivant : une fois une personne migrĂ©e, elle peut avoir plusieurs adresses. Que faire quand on rĂ©cupĂšre cette mĂȘme personne en passant par l’API /v1 ?

Ici il n’y a pas de rĂ©ponse Ă©vidente : il n’y a pas de notion d’adresse prĂ©fĂ©rĂ©e, ou de derniĂšre adresse utilisĂ©e qui fournirait une maniĂšre de discriminer les diffĂ©rentes possibilitĂ©s. Comme la rĂ©ponse influe sur le comportement de l’API, c’est une dĂ©cision Ă  prendre par les personnes du mĂ©tier.

La solution choisie ici est de renvoyer une adresse parmi celle dans la liste. Elle n’est pas parfaite, mais elle peut ĂȘtre acceptable suivant l’usage qui en est fait : il revient aux personnes du mĂ©tier d’en dĂ©cider.

La transactionnalité

Pour résoudre la question de transactionnalité, nous avons choisi la solution la plus simple : poser un verrou sur les entrées correspondantes de la table person.

Si toutes les opĂ©rations suivent le mĂȘme principe, ce verrou joue le rĂŽle d’une mutex en s’assurant que les appels s’exĂ©cutent bien l’un aprĂšs l’autre : lorsqu’une opĂ©ration pose un risque, elle commence par demander l’accĂšs Ă  ce verrou, et pour cela elle doit attendre son tour.

Exemple avec un appel Ă  PUT /v1/people/127 alors que la personne correspondante est stockĂ©e au format v2 mais n’a pas encore d’adresse.

Exemple sans verrou :

Fil d’exĂ©cution 1 Fil d’exĂ©cution 2

PUT /v1/people/127/addresses

PUT /v1/people/127/addresses

BEGIN

BEGIN

SELECT * from person where id = 127 pour rĂ©cupĂ©rer la personne, vĂ©rifie qu’il n’y a pas d’adresse et que les autres champs ne sont pas Ă  modifier

SELECT * from person where id = 127 pour rĂ©cupĂ©rer la personne, vĂ©rifie qu’il n’y a pas d’adresse et que les autres champs ne sont pas Ă  modifier

SELECT * from address where id_person = 127 pour rĂ©cupĂ©rer une adresse Ă  mettre Ă  jour, n’en trouve pas et dĂ©duit donc qu’il faut en insĂ©rer une

SELECT * from address where id_person = 127 pour rĂ©cupĂ©rer une adresse Ă  mettre Ă  jour, n’en trouve pas et dĂ©duit donc qu’il faut en insĂ©rer une

INSERT INTO address 
 pour insĂ©rer l’adresse

INSERT INTO address 
 pour insĂ©rer l’adresse

commit

commit

RĂ©sultat : la personne se retrouve avec deux adresses !

Exemple avec verrou :

Fil d’exĂ©cution 1 Fil d’exĂ©cution 2

PUT /v1/people/127/addresses

PUT /v1/people/127/addresses

BEGIN

BEGIN

SELECT address from person where id = 127 FOR UPDATE pour rĂ©cupĂ©rer la personne, vĂ©rifie qu’il n’y a pas d’adresse et que les autres champs ne sont pas Ă  modifier et verrouille la ligne

SELECT * from address where id_person = 127 pour rĂ©cupĂ©rer une adresse Ă  mettre Ă  jour, n’en trouve pas et dĂ©duit donc qu’il faut en insĂ©rer une

INSERT INTO address 
 pour insĂ©rer l’adresse

commit qui relache le verrou sur person

SELECT address from person where id = 127 FOR UPDATE pour rĂ©cupĂ©rer la personne, vĂ©rifie qu’il n’y a pas d’adresse et que les autres champs ne sont pas Ă  modifier et verrouille la ligne, attendait que le verrou sur person soit disponible

SELECT id, address FROM address WHERE id_person = 127 rĂ©cupĂšre l’adresse

SELECT * from address where id_person = 127 pour rĂ©cupĂ©rer une adresse Ă  mettre Ă  jour, trouve l’adresse insĂ©rĂ©e par l’autre fil d’exĂ©cution

UPDATE address set address = 
 where id = 4758 met à jour l’adresse

commit qui relĂąche le verrou sur person

RĂ©sultat : une seule adresse.

Le script de migration SQL

Le script de migration déplace les données par blocs de person à address.

Dans notre exemple, une fois le code basculĂ© Ă  la nouvelle version, toutes les donnĂ©es sont Ă©crites au format v2, qu’il s’agisse des crĂ©ations ou des modifications.

La migration est donc irrĂ©versible, nous savons qu’il suffit de migrer toutes les donnĂ©es une fois pour que le travail soit fait.

  • Il commence par rĂ©cupĂ©rer l’ id de person le plus Ă©levĂ©. Comme le script est lancĂ© aprĂšs le dĂ©ploiement de la nouvelle version, toutes les personnes crĂ©Ă©es aprĂšs ce moment le sont avec une adresse stockĂ©e dans address. Cela signifie que le script peut s’arrĂȘter Ă  cette valeur.
  • Le script itĂšre par groupes de person de 0 Ă  l’ id qu’il vient de rĂ©cupĂ©rer. Le pas de l’itĂ©ration est Ă  dĂ©terminer expĂ©rimentalement : un pas plus grand permet de faire moins de requĂȘtes donc de diminuer le temps total de la migration, au dĂ©triment du temps unitaire de chaque itĂ©ration, et donc du temps oĂč les verrous existent en base.
    • Il dĂ©marre une transaction.
    • Il sĂ©lectionne les id des personnes qui ont une adresse, et les verrouille.
    • Il insĂšre dans address les donnĂ©es correspondantes Ă  l’aide d’un INSERT 
 SELECT 
`.
    • Il vide le champs address de ces entrĂ©es dans la table person.
    • Il valide la transaction, relĂąchant ainsi les donnĂ©es.

En cas d’arrĂȘt du script, les donnĂ©es dĂ©jĂ  migrĂ©es ne sont pas perdues, et relancer le script ne pose pas de problĂšmes, les donnĂ©es migrĂ©es n’étant pas retraitĂ©es.

Les Ă©tapes Ă  suivre
  1. Version initiale fournissant l’API /v1 et oĂč l’adresse est stockĂ©e dans la colonne address de la table person.
  2. Ajout en base de la table address, non encore utilisĂ©e par le code. La crĂ©ation d’une table n’a en principe aucun impact sur la base mais il faut le vĂ©rifier.
  3. Fournit l’API /v1, stocke l’adresse dans la table address et sait la lire aux deux endroits. Lors d’une lecture en /v1 sur une donnĂ©e v1 la donnĂ©e n’est pas migrĂ©e en v2 pour garder le code plus simple.
  4. Migration des adresses vers la table address.
  5. Fournit les API /v1 et /v2, et ne sait la lire qu’au format v2, suppression de la colonne address de la table person du code, la colonne est alors toujours en base.
  6. Suppression en base de la colonne address de la table person. Dans certaines bases de donnĂ©es, supprimer une colonne dĂ©clenche la rĂ©Ă©criture de toute la table et ne peut donc se faire en ZDD. On se contente donc d’une suppression logique, par exemple en ajoutant un underscore devant son nom, et en la « recyclant » lorsqu’on a besoin d’une nouvelle colonne.
L’implĂ©mentation

L’implĂ©mentation se trouve sur GitHub. Le code est en open source sous licence MIT, vous pouvez donc vous en servir.

Chaque Ă©tape de la migration est dans un module Ă  part, cela permet de facilement examiner ce qui se passe sans avoir Ă  manipuler git.

Le code est en Java et utilise la bibliothĂšque Dropwizard. La base de donnĂ©e est PostgreSQL, l’accĂšs se fait via Hibernate, et les migrations SQL utilisent Liquibase.

Quelques éléments saillants :

Pour conclure

Faire du ZDD n’est pas magique : cela demande du travail et de la rigueur. Si vous pouvez faire sans, tant mieux pour vous, mais si vous en avez besoin, vous devriez maintenant avoir une idĂ©e un peu plus prĂ©cise de ce que ça reprĂ©sente. Rappelez-vous que l’exemple dĂ©veloppĂ© ici est un cas simple : servez-vous en pour avoir une idĂ©e de la dĂ©marche Ă  suivre, et pas comme un guide pour mesurer l’effort Ă  fournir.

La premiĂšre migration sera sĂ»rement un peu un dĂ©fi, mais les suivantes seront de plus en plus faciles. Dans tous les cas, n’oubliez pas de tester, tester, et encore tester !

Catégories: Blog Société

Versionning d’API, Zero Downtime Deployment et migration SQL : thĂ©orie et cas pratique

jeu, 07/06/2017 - 08:29

Pour démythifier le Zero Downtime Deployment

Dans les patterns associĂ©s aux gĂ©ants du web, le Zero Downtime Deployment (ZDD) partage une caractĂ©ristique avec l’auto-scaling : on en parle d’autant plus qu’ils sont peu mis en Ɠuvre.

Le ZDD est victime d’un cercle vicieux : il a l’air trĂšs complexe car il est peu pratiquĂ©, et comme il est peu pratiquĂ©, on pense qu’il est trĂšs complexe.

Pour sortir de cette impasse, cet article prĂ©sente un cas pratique, code Ă  l’appui.

L’objectif n’est pas que tout le monde fasse du ZDD, car on verra qu’il ajoute du travail et de la complexitĂ©, mais que vous vous en ayez une vision claire. Cela vous permettra de pouvoir dĂ©cider d’en faire ou pas en connaissance de cause.

Notre cas d’exemple

Notre exemple s’approche de celui dĂ©crit dans le premier article.

Soit une application exposée via une API REST.

Au dĂ©part cette application gĂšre des personnes, chaque personne ayant zĂ©ro ou une adresse. Cette version est exposĂ©e sur le prĂ©fixe /v1 Ă  l’aide d’un unique type de ressource /person.

La version suivante de l’application permettra d’associer plusieurs adresses Ă  une personne, et sera exposĂ©e sur le prĂ©fixe /v2 en utilisant deux ressources, /person et /address.

Les deux versions

Cette application met en avant sa haute disponibilité, il est donc primordial que toutes les opérations soient effectuées sans interruption de service.

L’API est publique, nous ne maĂźtrisons donc pas l’utilisation qui en est faite. Il est donc impossible de faire une bascule de /v1 Ă  /v2 en une seule fois. Les deux versions devront donc fonctionner ensemble le temps de permettre la migration de tous les utilisateurs. Cette pĂ©riode pouvant ĂȘtre trĂšs longue suivant les cas.

Les clients consomment les API via des intermédiaires, il est donc possible que pendant cette période ils utilisent à la fois les versions /v1 et /v2.

Dans la suite de l’article, /v1 et /v2 correspondent aux versions des services, et v1 et v2 correspondent aux deux maniĂšres dont les donnĂ©es seront stockĂ©es en base.

La stratégie Comment gérer la migration ?

Il est possible de se passer complĂštement de script de migration au sens traditionnel : vous exposez les services en /v2, et, lorsqu’ils sont appelĂ©s pour une donnĂ©e encore au format /v1, vous migrez la donnĂ©e Ă  la volĂ©e. Cela permet de migrer les donnĂ©es petit Ă  petit au fur et Ă  mesure que les utilisateurs des services appelleront les APIs /v2. C’est l’approche qui est souvent prise avec les bases de donnĂ©es NoSQL.

Malheureusement, en procédant ainsi, il est possible que la migration ne se termine jamais, ou alors seulement dans trÚs longtemps (si vous purgez les données trop anciennes). Pendant ce temps, vous devez maintenir le code supplémentaire permettant de prendre en charge ce cas.

L’autre approche est d’utiliser un script. Cela permet de faire en sorte que la migration se fasse rapidement. C’est le mĂȘme type de script que vous utilisez pour vos migrations habituelles, sauf qu’il doit prendre en compte le fait qu’il s’exĂ©cute en mĂȘme temps que le code. Ainsi toutes les opĂ©rations qui crĂ©ent des verrous pendant plus de quelques millisecondes ne doivent pas ĂȘtre utilisĂ©es, et il faut s’assurer de ne pas crĂ©er d’interblocage.

La migration doit se faire de maniĂšre transactionnelle, pour Ă©viter d’introduire des incohĂ©rences dans les donnĂ©es. En cas de problĂšme, le script doit Ă©galement pouvoir ĂȘtre interrompu et relancĂ© sans que cela ne perturbe l’exĂ©cution du programme.

Dans l’article c’est cette approche que nous allons utiliser.

Quand migrer ?

Sans ZDD, le process de migration est classiquement le suivant :

  1. Fermer le service
  2. ArrĂȘter l’application
  3. Faire un backup des données, pour pouvoir les restaurer en cas de problÚme
  4. Migrer les données
  5. DĂ©ployer la nouvelle version de l’application
  6. DĂ©marrer la nouvelle version de l’application
  7. VĂ©rifier que tout fonctionne bien
  8. Ouvrir le service

En ZDD, plus question de fermer le service : la migration de données a lieu « à chaud ».

Il y a deux maniùres possibles de s’y prendre, suivant que la migration a lieu avant ou aprùs l’ouverture des services /v2 :

Les deux maniĂšres de migrer

NumĂ©ro de l’étape Version du code Migration aprĂšs l’ouverture de /v2 Migration avant l’ouverture de /v2

1

1

Application servant /v1 avec un modÚle de de donnée v1

2

1

Modifier le schéma de BDD pour permettre de stocker les données nécessaires à /v2

3

2

DĂ©ployer une nouvelle version de l’application exposant /v1 et /v2 sur les modĂšles de donnĂ©e v1 ou v2

DĂ©ployer une nouvelle version de l’application exposant /v1 sur les modĂšles de donnĂ©e v1 ou v2

4

2

Migrer les données au modÚle v2 sans interruption de service, en tenant compte du code /v1 et /v2

Migrer les données au modÚle v2 sans interruption de service, en tenant compte du code qui sert /v1

5

3

DĂ©ployer une nouvelle version de l’application exposant /v1 et /v2 sur le modĂšle de donnĂ©e v2

6

3

Nettoyer le schéma de BDD des artefacts v1

7

4

DĂ©ployer une nouvelle version de l’application gĂ©rant /v2 sur le modĂšle de donnĂ©e v2

La premiĂšre approche permet d’ouvrir les services /v2 plus rapidement car il n’y a pas besoin d’attendre la migration des donnĂ©es.

La seconde approche est plus simple :

  • la version exposant de l’application fonctionnant avec les modĂšles de donnĂ©es v1 et v2 n’expose que les services /v1, vous faites ainsi l’économie du cas oĂč un appel de service /v2 accĂšde Ă  des donnĂ©es v1 ;
  • pendant la migration de donnĂ©es, les services /v2 ne sont pas encore exposĂ©s, cela veut dire moins de patterns d’accĂšs aux donnĂ©es Ă  prendre en compte pour dĂ©signer une migration Ă©vitant les incohĂ©rences de donnĂ©es et les interblocages.

Sauf si votre process de migration est extrĂȘmement long, la seconde approche est Ă  privilĂ©gier, et c’est celle qui sera utilisĂ©e dans la suite de l’article.

/v1 et /v2 sont dans un bateau 


Les migrations d’APIs ouvertes posent deux problĂšmes mĂ©tier et un problĂšme technique.

Comment migrer les données ?

Le premier problĂšme, valable aussi pour les API fermĂ©es, est de savoir comment migrer les donnĂ©es de /v1 Ă  /v2. Je ne parle pas d’un point de vue technique mais bien d’un point de vue mĂ©tier : la sĂ©mantique change entre les deux versions, il faut donc dĂ©terminer comment transformer les donnĂ©es de /v1 en /v2 d’une maniĂšre qui soit logique et qui ne surprenne pas les utilisateur·rice·s de l’API.

Dans notre cas la solution est immĂ©diate : /v1 a au plus une seule adresse, et /v2 peut en avoir plusieurs, l’adresse de /v1 devient donc une des adresses de /v2.

Comment gérer la rétro-compatibilité ?

L’autre problĂšme est de savoir comment interprĂ©ter en /v1 des donnĂ©es /v2. En effet si l’API est ouverte, vos utilisateur·rice·s peuvent appeler vos services /v1 alors que les donnĂ©es sont dĂ©jĂ  au modĂšle /v2.

Il est souvent plus compliquĂ© que le premier car au fur et Ă  mesure des Ă©volutions, les API ont tendance Ă  devenir plus riches. AccĂ©der Ă  des donnĂ©es plus riches de la /v2 au travers du prisme plus Ă©troit de l’API /v1 peut ĂȘtre un vrai casse-tĂȘte.

Si c’est le seul moyen que cette transition se passe bien, il est parfois nĂ©cessaire d’adapter le design de l’API /v2.

C’est un Ă©quilibre Ă  trouver entre la facilitĂ© de transition, des restrictions possibles Ă  ajouter pour les appelants de l’API, et le temps Ă  investir.

Comment répondre vite et bien ?

Le problĂšme technique est de parvenir Ă  rendre les diffĂ©rents services, y compris la compatibilitĂ©, tout en s’assurant de toujours avoir des donnĂ©es cohĂ©rentes et sans (trop) pĂ©naliser les performances. Si, entre les deux versions, les donnĂ©es ne sont plus structurĂ©es de la mĂȘme maniĂšre, la gestion de la compatibilitĂ© peut demander de croiser les donnĂ©es de plusieurs tables.

Ainsi dans notre exemple, en v1 les adresses sont stockĂ©es dans la table person alors qu’en v2 elles sont dans une table address sĂ©parĂ©e. Pendant la pĂ©riode de compatibilitĂ©, il faut que les appels Ă  v1 qui mettent Ă  jour le nom de la personne et son adresse modifient les deux tables de maniĂšre transactionnelle pour Ă©viter qu’une lecture v1 qui se produirait au mĂȘme moment ne renvoie des donnĂ©es incohĂ©rentes. De plus, il faut parvenir Ă  le faire sans avoir Ă  poser trop de verrous en base de donnĂ©es, car cela raletit les accĂšs.

La meilleure stratĂ©gie est de privilĂ©gier une approche que vous maĂźtrisez bien et qui donne des rĂ©sultats acceptables plutĂŽt qu’une solution plus efficace ou plus rapide mais plus complexe.

Dans tous les cas, des tests sont absolument essentiels.

Pour servir les deux versions de l’API, vous pouvez utiliser une application unique ou choisir de sĂ©parer votre code en deux applications, une par version de services. Cette question n’étant pas structurante pour la question du ZDD, nous choisissons de ne pas la traiter ici. Dans notre exemple, nous avons choisi de n’avoir qu’une seule application.


 et ZDD les rejoint à bord

Sans ZDD la situation est claire : on arrĂȘte l’application, les donnĂ©es sont migrĂ©es, et on redĂ©marre l’application dans la nouvelle version. Il y a donc un avant et un aprĂšs.

Avec ZDD la migration s’effectue Ă  chaud pendant que les services sont disponibles, s’ajoute une situation intermĂ©diaire.

Pendant cette pĂ©riode, les donnĂ©es peuvent donc ĂȘtre encore stockĂ©es au format /v1 ou migrĂ©es au format /v2.

Il faut alors parvenir Ă  dĂ©terminer dans quel Ă©tat sont les donnĂ©es : pour savoir quel code doit ĂȘtre appelĂ© il faut savoir si la donnĂ©e a Ă©tĂ© migrĂ©e ou pas. De plus, le morceau de code en charge de cela va ĂȘtre exĂ©cutĂ© trĂšs souvent, il doit donc ĂȘtre trĂšs efficace.

En cas de difficultĂ©, la solution qui devrait fonctionner dans tous les cas est d’ajouter dans les tables impliquĂ©es un numĂ©ro indiquant la « version de schĂ©ma » de la donnĂ©e correspondante, et qui sera incrĂ©mentĂ© lors de la migration de la donnĂ©e. Dans ce cas l’opĂ©ration de vĂ©rification est trĂšs simple et rapide. L’opĂ©ration d’ajout de colonne est alors Ă  faire en avance de phase, ce qui augmente le travail nĂ©cessaire Ă  la migration.

Si vous choisissez de faire la migration de donnĂ©es aprĂšs l’ouverture de /v2, s’ajoute le cas oĂč on appelle une api /v2 alors que la donnĂ©e est encore stockĂ©e au format v1. Il faut alors migrer la donnĂ©e Ă  chaud, de maniĂšre transactionnelle en limitant les ralentissements induits.

Pour résumer, il y a quatre situations :

Appel /v1 Appel /v2

Données stockées au format v1

RĂ©pondre comme auparavant

(Seulement si migration aprÚs ouverture de /v2) Migrer les données à chaud

Données stockées au format v2

Compatibilité v1

Répondre avec la nouvelle sémantique

Bien ouvrir /v2, et bien décomissionner /v1

Lorsque vous ouvrez /v2 pour la premiĂšre fois, faites-attention Ă  la maniĂšre dont la bascule vers la nouvelle version est faite.

Avant de rendre les nouveaux endpoints accessibles, assurez-vous que tous les serveurs utilisent la derniĂšre version de l’application. Dans le cas contraire, si vous appelez un /v1 alors que la donnĂ©e correspondante a Ă©tĂ© migrĂ©e en v2 le code ne saura pas la lire correctement et risque de planter ou de renvoyer une information fausse.

Un autre problÚme se pose suivant la maniÚre dont vous avez implémenté les modifications de donnée lorsque vous appelez une API /v1.

Le premier cas consiste Ă  sauvegarder la donnĂ©e au format v2, mais cela veut dire qu’à nouveau, les versions prĂ©cĂ©dentes de l’application ne pourront pas la lire. La solution la plus simple est alors d’utiliser le feature flipping pour faire basculer le code.

Dans le cas contraire, votre code doit dĂ©tecter sous quel format la donnĂ©e est stockĂ©e, et la resauvegarder sous ce mĂȘme format : une donnĂ©e v1 reste en v1, et une donnĂ©e v2 reste en v2.
On Ă©vite le feature flipping, mais en Ă©change le code est plus complexe.

Pour décomissionner /v1 il suffit de rendre les endpoints inaccessibles, la suppression du code peut se faire plus tard.

À propos des verrous et des modifications de schĂ©mas

Comme on vient de le voir, le ZDD s’appuie beaucoup sur l’utilisation de la base de donnĂ©es, et notamment ses fonctionnalitĂ©s d’accĂšs concurrent. Si vos comportements mĂ©tiers sont simples, que vous utilisez un ORM, et que vous avez des tests de performances automatisĂ©s, il s’agit d’un domaine auquel vous n’avez pas souvent Ă  vous intĂ©resser. Si vous vous y prenez mal, il est facile de bloquer la base, renvoyer des erreurs (en cas d’interblocage), ou des rĂ©sultats incohĂ©rents.

Notre conseil est de bien vous documenter en amont voire de faire des POC pour Ă©viter d’avoir Ă  refaire un design parce que votre base de donnĂ©es ne fonctionne pas comme vous l’imaginiez. Ne faites pas confiance Ă  des souvenirs ou Ă  des rumeurs : lisez en dĂ©tail la documentation correspondant Ă  la version de l’outil que vous utilisez, et surtout testez !

Si vous n’avez jamais creusĂ© ces sujets ou que vous ĂȘtes rouillé·e, la premiĂšre migration vous demandera sĂ»rement pas mal de travail, et vous donnera quelques sueurs froides lorsque vous l’exĂ©cuterez. Mais dites-vous que toutes les opĂ©rations suivantes manipuleront les mĂȘmes concepts, et se passeront donc beaucoup mieux.

Il n’y a pas que le REST dans la vie

REST possÚde deux caractéristiques qui en font un candidat idéal pour le ZDD :

  • exposer plusieurs versions de services est une pratique standard ;
  • les appels sont supposĂ©s ĂȘtre sans Ă©tat.

Si vos services sont exposĂ©s d’une autre maniĂšre, il faudra donc vous intĂ©resser Ă  ces sujets. Les sessions, comme tous les types de cache, peuvent demander une attention particuliĂšre si les donnĂ©es qu’elles contiennent font l’objet d’un changement de structure entre versions.

Retour Ă  notre exemple

Nous prenons l’hypothĂšse oĂč le modĂšle de donnĂ©es suit directement les ressources Ă  exposer. L’adresse est initialement un champ de la table person, et est migrĂ©e dans une table address distincte.

L’évolution du schĂ©ma

Nous n’utilisons pas de colonne spĂ©cifique pour stocker la « version de schĂ©ma » des objet. À la place nous allons vĂ©rifier en base la maniĂšre dont les donnĂ©es sont stockĂ©es : si la table person contient une adresse, c’est qu’elle est en version v1, sinon il faut vĂ©rifier l’existence d’une adresse dans la table dĂ©diĂ©e. Cela Ă©vite d’alourdir le schĂ©ma SQL, mais augmente le nombre de requĂȘtes exĂ©cutĂ©es.

Les Ă©tapes Ă  suivre pour la migration :

  1. Version initiale : l’adresse est dans la colonne address de la table person, le code ne sait fonctionner que de cette maniùre.
  2. Ajout de la nouvelle table address dans la base de données, à cette étape le code ne connaßt pas encore cette table.
  3. DĂ©ploiement du code qui fournit l’api /v1 et qui est compatible avec les deux maniĂšres de stocker l’adresse.
  4. Exécution du script de migration.
  5. DĂ©ploiement du code qui fournit les api /v1 et /v2 et qui est compatible avec la nouvelle maniĂšre de stocker l’adresse, la colonne address de la table person n’est plus utilisĂ©e par le code.
  6. Suppression de la colonne address de la table person.

Le ZDD a pour consĂ©quence d’ajouter des versions de code et des migrations de schĂ©mas intermĂ©diaires. Dans un environnement oĂč les dĂ©ploiements ne sont pas automatisĂ©s, cela signifie une augmentation de la charge de travail et donc du risque d’erreur. Mieux vaut donc s’outiller et disposer d’un pipeline de livraison fiable avant de se lancer.

Analyse détaillée La compatibilité des services

Dans notre exemple le problĂšme de compatibilitĂ© est le suivant : une fois une personne migrĂ©e, elle peut avoir plusieurs adresses. Que faire quand on rĂ©cupĂšre cette mĂȘme personne en passant par l’API /v1 ?

Ici il n’y a pas de rĂ©ponse Ă©vidente : il n’y a pas de notion d’adresse prĂ©fĂ©rĂ©e, ou de derniĂšre adresse utilisĂ©e qui fournirait une maniĂšre de discriminer les diffĂ©rentes possibilitĂ©s. Comme la rĂ©ponse influe sur le comportement de l’API, c’est une dĂ©cision Ă  prendre par les personnes du mĂ©tier.

La solution choisie ici est de renvoyer une adresse parmi celle dans la liste. Elle n’est pas parfaite, mais elle peut ĂȘtre acceptable suivant l’usage qui en est fait : il revient aux personnes du mĂ©tier d’en dĂ©cider.

La transactionnalité

Pour résoudre la question de transactionnalité, nous avons choisi la solution la plus simple : poser un verrou sur les entrées correspondantes de la table person.

Si toutes les opĂ©rations suivent le mĂȘme principe, ce verrou joue le rĂŽle d’une mutex en s’assurant que les appels s’exĂ©cutent bien l’un aprĂšs l’autre : lorsqu’une opĂ©ration pose un risque, elle commence par demander l’accĂšs Ă  ce verrou, et pour cela elle doit attendre son tour.

Exemple avec un appel Ă  PUT /v1/people/127 alors que la personne correspondante est stockĂ©e au format v2 mais n’a pas encore d’adresse.

Exemple sans verrou :

Fil d’exĂ©cution 1 Fil d’exĂ©cution 2

PUT /v1/people/127/addresses

PUT /v1/people/127/addresses

BEGIN

BEGIN

SELECT * from person where id = 127 pour rĂ©cupĂ©rer la personne, vĂ©rifie qu’il n’y a pas d’adresse et que les autres champs ne sont pas Ă  modifier

SELECT * from person where id = 127 pour rĂ©cupĂ©rer la personne, vĂ©rifie qu’il n’y a pas d’adresse et que les autres champs ne sont pas Ă  modifier

SELECT * from address where id_person = 127 pour rĂ©cupĂ©rer une adresse Ă  mettre Ă  jour, n’en trouve pas et dĂ©duit donc qu’il faut en insĂ©rer une

SELECT * from address where id_person = 127 pour rĂ©cupĂ©rer une adresse Ă  mettre Ă  jour, n’en trouve pas et dĂ©duit donc qu’il faut en insĂ©rer une

INSERT INTO address 
 pour insĂ©rer l’adresse

INSERT INTO address 
 pour insĂ©rer l’adresse

commit

commit

RĂ©sultat : la personne se retrouve avec deux adresses !

Exemple avec verrou :

Fil d’exĂ©cution 1 Fil d’exĂ©cution 2

PUT /v1/people/127/addresses

PUT /v1/people/127/addresses

BEGIN

BEGIN

SELECT address from person where id = 127 FOR UPDATE pour rĂ©cupĂ©rer la personne, vĂ©rifie qu’il n’y a pas d’adresse et que les autres champs ne sont pas Ă  modifier et verrouille la ligne

SELECT * from address where id_person = 127 pour rĂ©cupĂ©rer une adresse Ă  mettre Ă  jour, n’en trouve pas et dĂ©duit donc qu’il faut en insĂ©rer une

INSERT INTO address 
 pour insĂ©rer l’adresse

commit qui relache le verrou sur person

SELECT address from person where id = 127 FOR UPDATE pour rĂ©cupĂ©rer la personne, vĂ©rifie qu’il n’y a pas d’adresse et que les autres champs ne sont pas Ă  modifier et verrouille la ligne, attendait que le verrou sur person soit disponible

SELECT id, address FROM address WHERE id_person = 127 rĂ©cupĂšre l’adresse

SELECT * from address where id_person = 127 pour rĂ©cupĂ©rer une adresse Ă  mettre Ă  jour, trouve l’adresse insĂ©rĂ©e par l’autre fil d’exĂ©cution

UPDATE address set address = 
 where id = 4758 met à jour l’adresse

commit qui relĂąche le verrou sur person

RĂ©sultat : une seule adresse.

Le script de migration SQL

Le script de migration déplace les données par blocs de person à address.

Dans notre exemple, une fois le code basculĂ© Ă  la nouvelle version, toutes les donnĂ©es sont Ă©crites au format v2, qu’il s’agisse des crĂ©ations ou des modifications.

La migration est donc irrĂ©versible, nous savons qu’il suffit de migrer toutes les donnĂ©es une fois pour que le travail soit fait.

  • Il commence par rĂ©cupĂ©rer l’ id de person le plus Ă©levĂ©. Comme le script est lancĂ© aprĂšs le dĂ©ploiement de la nouvelle version, toutes les personnes crĂ©Ă©es aprĂšs ce moment le sont avec une adresse stockĂ©e dans address. Cela signifie que le script peut s’arrĂȘter Ă  cette valeur.
  • Le script itĂšre par groupes de person de 0 Ă  l’ id qu’il vient de rĂ©cupĂ©rer. Le pas de l’itĂ©ration est Ă  dĂ©terminer expĂ©rimentalement : un pas plus grand permet de faire moins de requĂȘtes donc de diminuer le temps total de la migration, au dĂ©triment du temps unitaire de chaque itĂ©ration, et donc du temps oĂč les verrous existent en base.
    • Il dĂ©marre une transaction.
    • Il sĂ©lectionne les id des personnes qui ont une adresse, et les verrouille.
    • Il insĂšre dans address les donnĂ©es correspondantes Ă  l’aide d’un INSERT 
 SELECT 
`.
    • Il vide le champs address de ces entrĂ©es dans la table person.
    • Il valide la transaction, relĂąchant ainsi les donnĂ©es.

En cas d’arrĂȘt du script, les donnĂ©es dĂ©jĂ  migrĂ©es ne sont pas perdues, et relancer le script ne pose pas de problĂšmes, les donnĂ©es migrĂ©es n’étant pas retraitĂ©es.

Les Ă©tapes Ă  suivre
  1. Version initiale fournissant l’API /v1 et oĂč l’adresse est stockĂ©e dans la colonne address de la table person.
  2. Ajout en base de la table address, non encore utilisĂ©e par le code. La crĂ©ation d’une table n’a en principe aucun impact sur la base mais il faut le vĂ©rifier.
  3. Fournit l’API /v1, stocke l’adresse dans la table address et sait la lire aux deux endroits. Lors d’une lecture en /v1 sur une donnĂ©e v1 la donnĂ©e n’est pas migrĂ©e en v2 pour garder le code plus simple.
  4. Migration des adresses vers la table address.
  5. Fournit les API /v1 et /v2, et ne sait la lire qu’au format v2, suppression de la colonne address de la table person du code, la colonne est alors toujours en base.
  6. Suppression en base de la colonne address de la table person. Dans certaines bases de donnĂ©es, supprimer une colonne dĂ©clenche la rĂ©Ă©criture de toute la table et ne peut donc se faire en ZDD. On se contente donc d’une suppression logique, par exemple en ajoutant un underscore devant son nom, et en la « recyclant » lorsqu’on a besoin d’une nouvelle colonne.
L’implĂ©mentation

L’implĂ©mentation se trouve sur GitHub. Le code est en open source sous licence MIT, vous pouvez donc vous en servir.

Chaque Ă©tape de la migration est dans un module Ă  part, cela permet de facilement examiner ce qui se passe sans avoir Ă  manipuler git.

Le code est en Java et utilise la bibliothĂšque Dropwizard. La base de donnĂ©e est PostgreSQL, l’accĂšs se fait via Hibernate, et les migrations SQL utilisent Liquibase.

Quelques éléments saillants :

Pour conclure

Faire du ZDD n’est pas magique : cela demande du travail et de la rigueur. Si vous pouvez faire sans, tant mieux pour vous, mais si vous en avez besoin, vous devriez maintenant avoir une idĂ©e un peu plus prĂ©cise de ce que ça reprĂ©sente. Rappelez-vous que l’exemple dĂ©veloppĂ© ici est un cas simple : servez-vous en pour avoir une idĂ©e de la dĂ©marche Ă  suivre, et pas comme un guide pour mesurer l’effort Ă  fournir.

La premiĂšre migration sera sĂ»rement un peu un dĂ©fi, mais les suivantes seront de plus en plus faciles. Dans tous les cas, n’oubliez pas de tester, tester, et encore tester !

Catégories: Blog Société

AprÚs-midi Big Data à GenÚve le 12 septembre : de la théorie à la pratique

jeu, 06/29/2017 - 14:56

Une saison d’Afterworks OCTO Technology consacrĂ©e au Big Data nous a permis d’aborder des aspects techniques de ces plateformes, et surtout d’explorer la richesse des paradigmes Ă  disposition. De plus en plus d’entreprises sortent de l’architecture classique des SI, pour plonger dans un monde nouveau, plus grand, plus rapide, plus diversifiĂ©.

RĂ©guliĂšrement nous faisons face Ă  des questions pratiques :

  • Comment mettre en place une infrastructure Hadoop pour dĂ©verser des donnĂ©es qui dĂ©bordent de mon Oracle?
  • Comment croiser les donnĂ©es des diffĂ©rentes bases de mon SI avec des donnĂ©es externes pour mieux analyser mon business et exploiter leur valeur?
  • Comment gĂ©rer des flux de donnĂ©es massifs en temps rĂ©el, afin de les analyser, les stocker et les visualiser?
  • Quand j’entends  » Hadoop » : ne ferais-je pas mieux de partir avec un Ă©cosystĂšme plus simple, comme un RDBM, Elasticsearch ou Cassandra?

Ces questions soulĂšvent des dĂ©fis rĂ©currents auxquels diffĂ©rentes briques de l’écosystĂšme Big Data peuvent rĂ©pondre.

Nous organisons donc une aprĂšs-midi Big Data Ă  GenĂšve afin de permettre aux participants d’avoir un (petit) panorama des solutions existantes. Le programme est composĂ© de sessions de 20 minutes qui alternera prĂ©sentations d’Ă©diteurs et retours d’expĂ©rience de nos clients. Des moments d’Ă©changes et de discussions informelles sont prĂ©vus tout au long de l’aprĂšs-midi.

Les places sont limitées, prenez le temps de vous inscrire. Cet évÚnement est ouvert à tous, cependant, en cas de forte affluence, nous privilégierons nos clients et prospects. Merci de votre compréhension.

 

Cliquez ici pour vous inscrire à cet événement

Articles suggested :

  1. Formation Data Science : Paris – GenĂšve
  2. Softshake 2016: Cocktail d’expĂ©riences informatiques en Suisse Romande

Catégories: Blog Société

AprÚs-midi Big Data à GenÚve le 12 septembre : de la théorie à la pratique

jeu, 06/29/2017 - 14:56

Une saison d’Afterworks OCTO Technology consacrĂ©e au Big Data nous a permis d’aborder des aspects techniques de ces plateformes, et surtout d’explorer la richesse des paradigmes Ă  disposition. De plus en plus d’entreprises sortent de l’architecture classique des SI, pour plonger dans un monde nouveau, plus grand, plus rapide, plus diversifiĂ©.

RĂ©guliĂšrement nous faisons face Ă  des questions pratiques :

  • Comment mettre en place une infrastructure Hadoop pour dĂ©verser des donnĂ©es qui dĂ©bordent de mon Oracle?
  • Comment croiser les donnĂ©es des diffĂ©rentes bases de mon SI avec des donnĂ©es externes pour mieux analyser mon business et exploiter leur valeur?
  • Comment gĂ©rer des flux de donnĂ©es massifs en temps rĂ©el, afin de les analyser, les stocker et les visualiser?
  • Quand j’entends  » Hadoop » : ne ferais-je pas mieux de partir avec un Ă©cosystĂšme plus simple, comme un RDBM, Elasticsearch ou Cassandra?

Ces questions soulĂšvent des dĂ©fis rĂ©currents auxquels diffĂ©rentes briques de l’écosystĂšme Big Data peuvent rĂ©pondre.

Nous organisons donc une aprĂšs-midi Big Data Ă  GenĂšve afin de permettre aux participants d’avoir un (petit) panorama des solutions existantes. Le programme est composĂ© de sessions de 20 minutes qui alternera prĂ©sentations d’Ă©diteurs et retours d’expĂ©rience de nos clients. Des moments d’Ă©changes et de discussions informelles sont prĂ©vus tout au long de l’aprĂšs-midi.

Les places sont limitées, prenez le temps de vous inscrire. Cet évÚnement est ouvert à tous, cependant, en cas de forte affluence, nous privilégierons nos clients et prospects. Merci de votre compréhension.

 

Cliquez ici pour vous inscrire à cet événement

Articles suggested :

  1. Formation Data Science : Paris – GenĂšve
  2. Softshake 2016: Cocktail d’expĂ©riences informatiques en Suisse Romande

Catégories: Blog Société

CRAFT et obsession de la mesure : auto-Ă©valuez vous !

mar, 06/27/2017 - 08:00

Chez OCTO, nous sommes organisĂ©s en tribu. La tribu CRAFT a pour but d’accompagner Ă  l’adoption des pratiques du software craftsmanship pour nos clients mais aussi pour nous-mĂȘmes.

Or, il y a un peu plus d’un an, des “anciens” octos ont constatĂ© des projets de delivery en souffrance. Nous avons Ă©tĂ© plusieurs Ă  constater que les pratiques crafts n’étaient pas toutes adoptĂ©es sur ces projets, notamment le TDD et les revues de code. De lĂ  sont parties plusieurs discussions, hypothĂšses et autres conjonctures. Mais la vraie question Ă©tait : nos recrues sont-elles formĂ©es Ă  ces pratiques ?

Le meilleur moyen qu’on ait trouvĂ© pour avoir la rĂ©ponse, c’est de leur demander : on ne pilote que ce qu’on mesure.

Sondage et initiatives

Nous avons donc lancĂ© un sondage le plus factuel possible Ă  destination des octos. Nous avons obtenu une centaine de rĂ©ponses qui Ă©taient en plus reprĂ©sentatives de la rĂ©partition de sĂ©nioritĂ© et d’expĂ©rience chez OCTO. Nous avons publiĂ© ces rĂ©sultats en interne dans un souci de transparence et pour susciter des initiatives.

Les premiĂšres initiatives Ă©taient l’accompagnement de craft·wo·men au sein d’équipe OCTO sur des projets de delivery, la tenue de BOF, REX et autre BBL pour sensibiliser aux pratiques de TDD et de code review.

Le timing correspondait aussi au lancement de notre livre blanc sur les pratiques craft : Culture Code. Initialement prévu pour sensibiliser nos clients, Culture Code a eu comme bénéfice de sensibiliser également en interne.

Autre timing parfait, la mise en place d’OCTO Skool, dont l’objectif sera dĂ©taillĂ© dans un prochain article, est de former nos recrues juniors aux pratiques agile et craft en proposant un cursus de formation intense lors de leurs premiers mois parmi nous.

Un an aprĂšs

Un an aprĂšs, nous avons proposĂ© exactement le mĂȘme sondage. Nous avons Ă©galement obtenu une centaine de rĂ©ponses qui Ă©taient tout aussi reprĂ©sentatives de la rĂ©partition de sĂ©nioritĂ© et d’expĂ©rience chez OCTO. Nous vous partageons les rĂ©sultats plus bas.

Nous avons la faiblesse de croire que la mise en place de nos initiatives ont eu comme consĂ©quence l’amĂ©lioration des rĂ©sultats. Autre constat : les projets sur lesquels ont Ă©tĂ© mis en place les pratiques de TDD et code review ne souffrent pas de problĂšmes de qualitĂ©.

Moralité

Si, comme nous, vous ĂȘtes convaincu·e·s que les pratiques craft vont vous permettre de faire du dĂ©veloppement durable, inspirez-vous du questionnaire en bas de l’article pour dĂ©tecter vos prochains chantiers (formations / accompagnements / coaching).

Pour constater les bĂ©nĂ©fices de vos initiatives, rejouez rĂ©guliĂšrement vos sondages pour trouver d’éventuelles corrĂ©lations et enclencher les prochains chantiers de votre amĂ©lioration continue.

Les résultats de 2017

C’est mieux sur la revue de code :

– comparĂ© Ă  l’annĂ©e derniĂšre, les revues sont plus variĂ©es, plus frĂ©quentes et plus collectives.

– seul 4,1% ne fait aucune revue de code (12,6% l’annĂ©e derniĂšre)

Fréquence des types de revues de code

Taux de ceux qui ne pratique aucune revue de code

 

C’est mieux sur les tests unitaires :

– La grande majoritĂ© teste unitairement (stable par rapport Ă  2016)

– Il y a nettement plus de personnes qui testent avant : 78,2% (60,7% en 2016)

– Il y a plus de personnes qui refactor aprĂšs que les tests soient au vert => TDD rules !

La pyramide des tests est mieux connue des octos : 91,8% (76,8% en 2016)…  

– … et est nettement plus respectĂ©e sur leurs projets : 61,8% (34,2% en 2016)

Testes-tu ton code unitairement ?
Testes-tu unitairement avant ou aprÚs l'implémentation ?

Pratiques-tu un refactoring une fois les tests passés au vert ?

Connais tu la pyramide des tests ? Est-elle respectée sur tes projets actuels ?

C’est mieux sur la partie clean code :

– 77,3% ont des standards de code sur leur projet (62,1% en 2016)

– les pratiques sont assez connues => un Ă©claircissement sur certaines pratiques est nĂ©cessaire

Ton équipe a-t-elle défini des standards de code ?Pratiques Clean Code

 

Le questionnaire complet

Quel est ton poste ?

Quel est ton ancienneté ?

Testes-tu ton code unitairement ?

  • Oui
  • Non

Testes-tu unitairement avant ou aprĂšs l’implĂ©mentation ?

  • Oui
  • Non

Trouves-tu ça … ?

  • Facile
  • Difficile

Pratiques-tu un refactoring une fois les tests passés au vert ?

  • Oui
  • Non

Trouves-tu ça … ?

  • Facile
  • Difficile

Connais-tu la pyramide des tests ?

  • Oui
  • Non

Est-elle respectée sur tes projets actuels ?

  • Oui
  • Non

Sur tes projets actuels , pratiques-tu la revue de code ?

  • Pair Programming
  • Peer Review Synchrone (cĂŽte Ă  cĂŽte en face de l’Ă©cran)
  • Peer Review Asynchrone (en faisant des commentaires dans un outil github, gitlab, sonar, gerrit, …)
  • Collective (Ă  3 ou plus devant un Ă©cran)]

Trouves-tu ça … ?

  • Facile
  • Difficile

Ton équipe a-t-elle défini des standards de code ?

  • Oui
  • Non

Pratiques-tu ces principes ? (si tu ne connais pas, réponds non)

  • Don’t Repeat Yourself (DRY) [Oui / Non]
  • Keep It Simple, Stupid (KISS) [Oui / Non]
  • You aren’t gonna need it (YAGNI) [Oui / Non]
  • Boy Scout Rule [Oui / Non]
  • Single Responsibility Principle (SRP) [Oui / Non]
  • Dependency inversion principle (DIP) [Oui / Non]
Catégories: Blog Société

CRAFT et obsession de la mesure : auto-Ă©valuez vous !

mar, 06/27/2017 - 08:00

Chez OCTO, nous sommes organisĂ©s en tribu. La tribu CRAFT a pour but d’accompagner Ă  l’adoption des pratiques du software craftsmanship pour nos clients mais aussi pour nous-mĂȘmes.

Or, il y a un peu plus d’un an, des “anciens” octos ont constatĂ© des projets de delivery en souffrance. Nous avons Ă©tĂ© plusieurs Ă  constater que les pratiques crafts n’étaient pas toutes adoptĂ©es sur ces projets, notamment le TDD et les revues de code. De lĂ  sont parties plusieurs discussions, hypothĂšses et autres conjonctures. Mais la vraie question Ă©tait : nos recrues sont-elles formĂ©es Ă  ces pratiques ?

Le meilleur moyen qu’on ait trouvĂ© pour avoir la rĂ©ponse, c’est de leur demander : on ne pilote que ce qu’on mesure.

Sondage et initiatives

Nous avons donc lancĂ© un sondage le plus factuel possible Ă  destination des octos. Nous avons obtenu une centaine de rĂ©ponses qui Ă©taient en plus reprĂ©sentatives de la rĂ©partition de sĂ©nioritĂ© et d’expĂ©rience chez OCTO. Nous avons publiĂ© ces rĂ©sultats en interne dans un souci de transparence et pour susciter des initiatives.

Les premiĂšres initiatives Ă©taient l’accompagnement de craft·wo·men au sein d’équipe OCTO sur des projets de delivery, la tenue de BOF, REX et autre BBL pour sensibiliser aux pratiques de TDD et de code review.

Le timing correspondait aussi au lancement de notre livre blanc sur les pratiques craft : Culture Code. Initialement prévu pour sensibiliser nos clients, Culture Code a eu comme bénéfice de sensibiliser également en interne.

Autre timing parfait, la mise en place d’OCTO Skool, dont l’objectif sera dĂ©taillĂ© dans un prochain article, est de former nos recrues juniors aux pratiques agile et craft en proposant un cursus de formation intense lors de leurs premiers mois parmi nous.

Un an aprĂšs

Un an aprĂšs, nous avons proposĂ© exactement le mĂȘme sondage. Nous avons Ă©galement obtenu une centaine de rĂ©ponses qui Ă©taient tout aussi reprĂ©sentatives de la rĂ©partition de sĂ©nioritĂ© et d’expĂ©rience chez OCTO. Nous vous partageons les rĂ©sultats plus bas.

Nous avons la faiblesse de croire que la mise en place de nos initiatives ont eu comme consĂ©quence l’amĂ©lioration des rĂ©sultats. Autre constat : les projets sur lesquels ont Ă©tĂ© mis en place les pratiques de TDD et code review ne souffrent pas de problĂšmes de qualitĂ©.

Moralité

Si, comme nous, vous ĂȘtes convaincu·e·s que les pratiques craft vont vous permettre de faire du dĂ©veloppement durable, inspirez-vous du questionnaire en bas de l’article pour dĂ©tecter vos prochains chantiers (formations / accompagnements / coaching).

Pour constater les bĂ©nĂ©fices de vos initiatives, rejouez rĂ©guliĂšrement vos sondages pour trouver d’éventuelles corrĂ©lations et enclencher les prochains chantiers de votre amĂ©lioration continue.

Les résultats de 2017

C’est mieux sur la revue de code :

– comparĂ© Ă  l’annĂ©e derniĂšre, les revues sont plus variĂ©es, plus frĂ©quentes et plus collectives.

– seul 4,1% ne fait aucune revue de code (12,6% l’annĂ©e derniĂšre)

Fréquence des types de revues de code

Taux de ceux qui ne pratique aucune revue de code

 

C’est mieux sur les tests unitaires :

– La grande majoritĂ© teste unitairement (stable par rapport Ă  2016)

– Il y a nettement plus de personnes qui testent avant : 78,2% (60,7% en 2016)

– Il y a plus de personnes qui refactor aprĂšs que les tests soient au vert => TDD rules !

La pyramide des tests est mieux connue des octos : 91,8% (76,8% en 2016)…  

– … et est nettement plus respectĂ©e sur leurs projets : 61,8% (34,2% en 2016)

Testes-tu ton code unitairement ?
Testes-tu unitairement avant ou aprÚs l'implémentation ?

Pratiques-tu un refactoring une fois les tests passés au vert ?

Connais tu la pyramide des tests ? Est-elle respectée sur tes projets actuels ?

C’est mieux sur la partie clean code :

– 77,3% ont des standards de code sur leur projet (62,1% en 2016)

– les pratiques sont assez connues => un Ă©claircissement sur certaines pratiques est nĂ©cessaire

Ton équipe a-t-elle défini des standards de code ?Pratiques Clean Code

 

Le questionnaire complet

Quel est ton poste ?

Quel est ton ancienneté ?

Testes-tu ton code unitairement ?

  • Oui
  • Non

Testes-tu unitairement avant ou aprĂšs l’implĂ©mentation ?

  • Oui
  • Non

Trouves-tu ça … ?

  • Facile
  • Difficile

Pratiques-tu un refactoring une fois les tests passés au vert ?

  • Oui
  • Non

Trouves-tu ça … ?

  • Facile
  • Difficile

Connais-tu la pyramide des tests ?

  • Oui
  • Non

Est-elle respectée sur tes projets actuels ?

  • Oui
  • Non

Sur tes projets actuels , pratiques-tu la revue de code ?

  • Pair Programming
  • Peer Review Synchrone (cĂŽte Ă  cĂŽte en face de l’Ă©cran)
  • Peer Review Asynchrone (en faisant des commentaires dans un outil github, gitlab, sonar, gerrit, …)
  • Collective (Ă  3 ou plus devant un Ă©cran)]

Trouves-tu ça … ?

  • Facile
  • Difficile

Ton équipe a-t-elle défini des standards de code ?

  • Oui
  • Non

Pratiques-tu ces principes ? (si tu ne connais pas, réponds non)

  • Don’t Repeat Yourself (DRY) [Oui / Non]
  • Keep It Simple, Stupid (KISS) [Oui / Non]
  • You aren’t gonna need it (YAGNI) [Oui / Non]
  • Boy Scout Rule [Oui / Non]
  • Single Responsibility Principle (SRP) [Oui / Non]
  • Dependency inversion principle (DIP) [Oui / Non]
Catégories: Blog Société

Meetup PerfUG : Optimisations et Performances d’un POC en prod @ plusieurs millions de requĂȘtes

lun, 06/26/2017 - 13:18

Ogury est la plateforme de data mobile qui permet d’accĂ©der aux donnĂ©es comportementales des profils de plus de 400 millions de mobinautes rĂ©partis dans plus de 120 pays. Monter une stack haute frĂ©quence n’est pas facile, David et Carles vous parleront de leur retour d’expĂ©rience.

Durant cette prĂ©sentation, Carles et David vous propose de revivre avec eux l’évolution de l’architecture d’Ogury. D’un POC monolite Ă  une architecture micro-service orientĂ© perf, constituĂ©e des 700 instances chez AWS.

David Caramelo, DĂ©veloppeur Craftsman passionnĂ© depuis 12 ans, actuellement Tech Lead full stack chez Ogury. David s’est forgĂ© son expĂ©rience essentiellement dans des startups parisiennes comme Viadeo ou Ogury et dans des cabinets conseil IT comme Xebia.

Carles SistarĂ©, Architecte-DĂ©veloppeur dans les clouds, actuellement Tech Lead de la team Delivery et co-fondateur d’Ogury. Carles a Ă©voluĂ© dans le monde de la AdTech en passant par Ad4Screen et en tant qu’amateur de l’open-source en tant que commiteur Node-Kafka et crĂ©ateur du module grpc-promise.

Inscriptions et informations sur Meetup. Cette session sera suivie d’un pot dans les locaux d’OCTO.

logo

Le PerfUG est un meetup parisien qui a pour objectif d’offrir un lieu d’échanges informels oĂč toutes les personnes intĂ©ressĂ©es par l’optimisation et la performance sont les bienvenues quel que soit leur niveau. Nous sommes convaincus que la performance est une feature implicite et non nĂ©gociable d’une application et pourtant bien souvent oubliĂ©e. Le PerfUG permet d’Ă©changer idĂ©es et pratiques sur ces sujets pour obtenir plus simplement des systĂšmes performants. Le PerfUG souhaite faciliter la diffusion des derniers outils et des meilleures techniques pour maĂźtriser au plus tĂŽt la performance d’un systĂšme informatique.

imgres

Pour en apprendre davantage sur la Performance, retrouvez notre formation OCTO Academy : Performance des applications et du SI Ă  l’Ăšre du digital

Articles suggested :

  1. PerfUG : DynaTrace pour monitorer tous vos problĂšmes de performance
  2. Second anniversaire du PerfUG : Nginx et JVM Off-Heap (Architecture NUMA)
  3. PerfUG : High Performance Java

Catégories: Blog Société

Meetup PerfUG : Optimisations et Performances d’un POC en prod @ plusieurs millions de requĂȘtes

lun, 06/26/2017 - 13:18

Ogury est la plateforme de data mobile qui permet d’accĂ©der aux donnĂ©es comportementales des profils de plus de 400 millions de mobinautes rĂ©partis dans plus de 120 pays. Monter une stack haute frĂ©quence n’est pas facile, David et Carles vous parleront de leur retour d’expĂ©rience.

Durant cette prĂ©sentation, Carles et David vous propose de revivre avec eux l’évolution de l’architecture d’Ogury. D’un POC monolite Ă  une architecture micro-service orientĂ© perf, constituĂ©e des 700 instances chez AWS.

David Caramelo, DĂ©veloppeur Craftsman passionnĂ© depuis 12 ans, actuellement Tech Lead full stack chez Ogury. David s’est forgĂ© son expĂ©rience essentiellement dans des startups parisiennes comme Viadeo ou Ogury et dans des cabinets conseil IT comme Xebia.

Carles SistarĂ©, Architecte-DĂ©veloppeur dans les clouds, actuellement Tech Lead de la team Delivery et co-fondateur d’Ogury. Carles a Ă©voluĂ© dans le monde de la AdTech en passant par Ad4Screen et en tant qu’amateur de l’open-source en tant que commiteur Node-Kafka et crĂ©ateur du module grpc-promise.

Inscriptions et informations sur Meetup. Cette session sera suivie d’un pot dans les locaux d’OCTO.

logo

Le PerfUG est un meetup parisien qui a pour objectif d’offrir un lieu d’échanges informels oĂč toutes les personnes intĂ©ressĂ©es par l’optimisation et la performance sont les bienvenues quel que soit leur niveau. Nous sommes convaincus que la performance est une feature implicite et non nĂ©gociable d’une application et pourtant bien souvent oubliĂ©e. Le PerfUG permet d’Ă©changer idĂ©es et pratiques sur ces sujets pour obtenir plus simplement des systĂšmes performants. Le PerfUG souhaite faciliter la diffusion des derniers outils et des meilleures techniques pour maĂźtriser au plus tĂŽt la performance d’un systĂšme informatique.

imgres

Pour en apprendre davantage sur la Performance, retrouvez notre formation OCTO Academy : Performance des applications et du SI Ă  l’Ăšre du digital

Articles suggested :

  1. PerfUG : DynaTrace pour monitorer tous vos problĂšmes de performance
  2. Second anniversaire du PerfUG : Nginx et JVM Off-Heap (Architecture NUMA)
  3. PerfUG : High Performance Java

Catégories: Blog Société

#PortraitDeCDO – SĂ©bastien Imbert – Microsoft

lun, 06/19/2017 - 06:30
#PortraitDeCDO – SĂ©bastien Imbert – Microsoft

DĂ©couvrez pour le SeiziĂšme #PortraitDeCDO, avec le portrait de SĂ©bastien Imbert Chief Digital Marketing Officer de Microsoft. Vous allez pouvoir dĂ©couvrir les enjeux du numĂ©rique pour son entreprise, ses contraintes au quotidien ou encore son rĂŽle au sein de sa sociĂ©tĂ© pour faire bouger les lignes du digital. Des insights prĂ©cieux que vous pourrez comparer au fur et Ă  mesure que les portraits s’Ă©graineront dans les semaines Ă  venir.

microsoft

En une phrase, comment définiriez-vous la notion de transformation digitale ?
Vaste « notion » qui a gĂ©nĂ©rĂ© plus d’une phrase dans de trĂšs nombreux ouvrages, mais en en quelques mots je dirais que c’est une capacitĂ© et une condition ; une capacitĂ© d’intĂ©grer dans sa stratĂ©gie les infinies possibilitĂ©s du « Digital » au bĂ©nĂ©fice de la crĂ©ation de valeur pour les clients, les employĂ©es, les partenaires de l’entreprise et une condition de survie de l’entreprise elle-mĂȘme Ă  moyen ou long-terme.

Comment décririez-vous votre rÎle de CDO ?
Souvent pour dĂ©crire mon rĂŽle j’utilise l’image d’une mappemonde. Quand on regarde l’ensemble des territoires sur une mappemonde on voit un univers oĂč les limites, les frontiĂšres Ă©voluent extrĂȘmement lentement. Si on transpose cette mappemonde dans univers digital oĂč les continents, les pays sont constituĂ©s d’utilisateurs de services numĂ©riques (i.e. Facebook, LinkedIn, Office365, 
) on arrive dans un univers oĂč les limites, les frontiĂšres sont en Ă©volutions et variations permanentes. Un univers ou aucune boussole de rĂ©fĂ©rence n’a vĂ©ritablement Ă©tĂ© inventĂ©e. En rĂ©sumĂ©, dans cet univers oĂč aucune boussole de rĂ©fĂ©rence n’a Ă©tĂ© crĂ©Ă©e, le rĂŽle du CDO, mon rĂŽle de CDO, est de contribuer :

1) à identifier les destinations futures et 2) à organiser la « logistique » de ce « voyage »

3) Ă  atteindre les prioritĂ©s marketing et business en Ă©vitant de tomber dans l’activation/la crĂ©ation de tactiques permanentes ce qui peut trĂšs facilement arriver « au milieu » de l’ocĂ©an digital.

Quelles difficultés rencontrez-vous au quotidien ?
Le mĂ©tier de CDO porte en lui deux Ă©lĂ©ments intrinsĂšquement abstraits. C’est Ă  la fois un point d’équilibre et Ă  la fois un paradoxe.

Un point d’équilibre entre l’infiniment grand et l’infiniment petit. Tel un « tai-chi master » le CDO fait un grand Ă©cart au quotidien entre des donnĂ©es, des points de contacts clients, des services, des fonctionnalitĂ©s, des technologies, des outils (cf. « Marketing Technology Landscape Supergraphic (2017): Martech 5000 »  de Chiefmartec.com) , des attentes,
 en super-croissances permanentes et des clients qui ont une bande-passante temps de plus en plus en Ă©troite (NB : certaines Ă©tudes indiquent que l’attention de l’humain est devenue infĂ©rieure Ă  celle du poisson rouge !) et des budgets bien souvent sous contraintes.

Qu’est-ce que j’entends en parlant de paradoxe ? CDO, c’est :

  • un mĂ©tier qui est Ă  la fois de plus en plus nĂ©cessaire et qui est Ă  la fois supposĂ© comme souvent soulignĂ© disparaitre prochainement (Ă  chacun son point de vue Ă  ce niveau).
  • un mĂ©tier qui est Ă  la fois dans le physique est dans le digital ; un mĂ©tier qui est par essence « phygital ».
  • un mĂ©tier oĂč il est absolument nĂ©cessaire d’avoir une hauteur de vue Ă  360° dans l’entreprise tout en Ă©tant capable de faire du « deep zoom » sur des micro-points, des micro-actions qui sont pourtant essentielles.
  • un mĂ©tier qui nĂ©cessite des expertises sans devenir un expert sur toutes les technos, sur les tous les outils ou process dont il va s’assurer le bon fonctionnement, la bonne coordination au quotidien.
  • un mĂ©tier qui opĂšre sur un univers omniprĂ©sent dans le quotidien de toutes et tous, le digital, mais pour lequel on n’a jamais eu autant besoin de formations internes et externes.

Pensez-vous qu’il faille ĂȘtre technophile pour exercer le mĂ©tier de CDO ?
Il n’est pas nĂ©cessaire d’ĂȘtre un technologue ou un « distinguish engineer » pour ĂȘtre un bon CDO ; en revanche ĂȘtre « technophile » est une condition absolument nĂ©cessaire tant le spectre des mĂ©tiers experts et technos avec lesquels on opĂšre au quotidien est large. Sans cela il me semble difficile pour un CDO de gĂ©nĂ©rer un Ă©lĂ©ment essentiel pour la croissance des entreprises : de « l’impact ».

Et au-delĂ  d’ĂȘtre « technophile », ĂȘtre « curieux » et « ouvert » sont selon-moi des qualitĂ©s essentielles pour avoir un « digital mindset » porteur.

Pensez-vous que CDO est un mĂ©tier d’avenir ?
Contrairement Ă  ce que l’on peut gĂ©nĂ©ralement lire, j’en suis convaincu. A un point prĂšs, c’est que l’intitulĂ© du titre Ă©voluera probablement. A l’ùre oĂč tout est numĂ©rique et oĂč le numĂ©rique est dans tout, c’est vraisemblablement le terme « Digital » qui disparaitra. On Ă©volue, on Ă©voluera vers des titres du type « Omnicanal Lead Director » « Chief Transformation Officer », « Chief Revenue/Demand Gen Officer », ou plus traditionnellement « CMO » voire « CEO » ;)

Et quoi qu’il arrive, comme on dit « ce n’est pas le titre qui fait l’homme, c’est l’homme qui fait le titre ».

Quelle est pour vous la prochaine innovation qui risque de chambouler votre secteur d’activitĂ© ?
Sans aucun doute, une « innovation » qui chamboule mon secteur d’activitĂ©, voire tous les secteurs d’activitĂ© Ă  l’échelle planĂ©taire, est l’intelligence artificielle. Pour notre CEO, Satya Nadella, l’intelligence artificielle « is the ‘ultimate breakthrough » – Progressivement, en lien avec le cloud, le « computing » gĂ©nĂ©ralisĂ©, l’intelligence artificielle sera partout, disponible depuis tout objet ou service connectĂ©. De la capacitĂ© Ă  interprĂ©ter des donnĂ©es structurĂ©es/non structurĂ©es en trĂšs grand nombre, Ă  la capacitĂ© d’interprĂ©ter des images (vision), des textes, des langues ou Ă  Ă©tablir des modĂšles de dĂ©tection de la fraude ou de marketing prĂ©dictif, nous ne sommes qu’au dĂ©but de multiples transformations et innovations associĂ©es Ă  l’intelligence artificielle.

Plus que jamais il est trĂšs difficile de prĂ©dire quelle sera telle ou telle technologie innovante Ă  trĂšs fort potentiel transformationnelle mais pour ma part et comme de nombreux autres j’estime que dans les 20 ans Ă  venir la combinatoire [Intelligence Artificielle/BlockChain/Quantum Computing] sera un « game changer ultime. »

Quels sont les enjeux de digitalisation de votre entreprise à l’heure actuelle ?
Aujourd’hui Microsoft est une « Cloud Company » qui se transforme tout en contribuant Ă  la transformation de ses clients et partenaires.

D’un point de vue enjeux marchĂ©, il y a trois domaines oĂč Microsoft se positionne de façon claire et marquĂ©e tant d’un point de vue crĂ©ations de nouveaux services que de nouveaux usages innovants :

  • Comme dĂ©jĂ  Ă©voquĂ© il y’a l’intelligence artificielle qui fait partie aujourd’hui de tous nos produits et que l’on rend accessible sur n’importe quels types de « pĂ©riphĂ©riques » ou systĂšmes. Je pense notamment Ă  Cortana qui est Ă  la fois un agent numĂ©rique et une plateforme. Illustrations concrĂštes : les nouveaux speakers de Harman Kardon, Invoke ou « Cortana Intelligence Suite »
  • La confiance numĂ©rique ou comment faire en sorte que chacun puisse innover en toute sĂ©curitĂ© et en respectant sans compromis l’intĂ©gritĂ© des donnĂ©es collectĂ©es et traitĂ©es. Un enjeu de premier plan dans les « heures » prĂ©cĂ©dents l’arrivĂ©e de GDPR.
  • Le « future of work » avec la crĂ©ation de nouveaux produits tels que le « Surface Hub » ou Microsoft « Office Delve » qui fait partie d’Office 365.

Les enjeux de digitalisation font partie par dĂ©faut du nouvel ADN de Microsoft. Ils sont multiples et larges mais je dirai son enjeu principal est de continuellement s’appliquer Ă  elle-mĂȘme ce que Microsoft propose Ă  ses clients et partenaires en matiĂšre de transformation :

  • DĂ©velopper le meilleur niveau d’expĂ©rience et d’engagement clients,
  • Contribuer Ă  l’efficacitĂ© et Ă  l’agilitĂ© des employĂ©s,
  • Optimiser, « fluidifier » les processus de l’entreprise pour dĂ©cloisonner voire effacer la notion de « silo »,
  • Transformer les processus de crĂ©ations de produits, en intĂ©grant notamment les retours des utilisateurs.

Citez-moi une marque/entreprise qui, pour vous, a clairement réussi à adresser les enjeux du digital ?
A mon sens, Ă  ce niveau, intĂ©ressant de se pencher sur des entreprises « brick & mortar » plus que centenaires. Il est beaucoup plus difficile de remettre en cause des modĂšles Ă©tablis depuis de longues annĂ©es dans ce type d’entreprise que d’en crĂ©er des tous nouveaux « from scratch » pour des nouveaux entrants (i.e. start-up).

Contexte donnĂ©, pour moi, une entreprise qui a rĂ©ussi Ă  trĂšs bien adresser les enjeux du digital est Schneider Electric. Aujourd’hui Schneider n’est pas qu’un groupe industriel c’est Ă  la fois un groupe industriel et Ă  la fois une « Digital Company ». Elle incarne pleinement ce qui a Ă©tĂ© soulignĂ© par Marc Andreesen il y a quelques annĂ©es « today, every company is a software company ».

Schneider a notamment rĂ©ussi Ă  mettre en musique les possibilitĂ©s du digital/du cloud pour proposer des services Ă©volutifs d’équipement connectĂ©s et d’analyse de donnĂ©es. Et ce pour de nombreuses industries majeures telles que la santĂ©, l’énergie ou la construction.

Egalement, au cours des derniĂšres annĂ©es Schneider a procĂ©dĂ© Ă  de nombreuses acquisitions et a rĂ©ussi dans un esprit « software company » Ă  orchestrer au mieux les diffĂ©rentes expertises anciennes et nouvelles de l’entreprise au profit de la mise en place de nouveaux produits ou services.

C’est pour ces raisons que Schneider est selon-moi un trĂšs bon exemple de transformation digitale rĂ©ussie.

Sans contrainte, vous avez la possibilité de commencer 3 projets de transformation dans votre entreprise : quels seraient-ils ?
On est dĂ©jĂ  d’une certaine maniĂšre une entreprise « GloCal », Globale et Locale.

  1. Sans contraintes je continuerai Ă  faire Ă©voluer voire Ă  transformer notre « MartTech » architecture que j’estime dĂ©jĂ  ĂȘtre extrĂȘmement robuste et innovante (voir cet article Frenchweb pour en avoir un aperçu). Comment ? En permettant Ă  chaque filiale d’y avoir un nombre dĂ©terminĂ© d’acteurs locaux de leur Ă©cosystĂšme (partenaires/start-up) et de regarder rĂ©guliĂšrement, filiale par filiale les nouveaux services disruptifs Ă  plus fort niveau d’impact client et business. C’est par exemple quelque chose que nous avons fait en France avec l’activation au niveau mondial du service français « d’employee brand advocacy » www.sociabble.com
  2. Un parcours « phygital » certifiant de « Transformation Digitale » pour les PME et TPE
  3. “Content is king, media is queen and context takes it all”, je crĂ©erai, au-delĂ  de la France une « Modern Content Management Team » transverse pour offrir de façon individualisĂ©e le meilleur niveau d’expĂ©rience Ă©ditoriale de marque quelque-soit le pĂ©riphĂ©rique utilisĂ© par chaque client Ă  un instant t.

Quel est l’impact de la transformation sur la culture et l’organisation de votre entreprise ?
DĂ©finitivement un des impacts de la transformation sur Microsoft est de l’ordre du collaboratif. Aujourd’hui, l’impact d’un collaborateur de Microsoft est essentiellement associĂ© Ă  la maniĂšre dont il a contribuĂ© aux succĂšs des autres et Ă  la maniĂšre dont il a intĂ©grĂ© les idĂ©es des autres au profit du succĂšs de ses projets. Et au-delĂ  du succĂšs, on cĂ©lĂšbre, on considĂšre aussi plus que jamais l’échec comme une source d’apprentissage extrĂȘmement prĂ©cieuse.

Egalement, on peut noter que la transformation Ă  dĂ©finitivement fait Ă©voluer Microsoft dans sa relation avec l’écosystĂšme du numĂ©rique. Des concurrents d’hier sont des partenaires d’aujourd’hui ou plus que jamais des « coopĂ©titeurs » (Apple, Google, RedHat/Linux, SAP, Oracle, Salesforce etc.)

Demain, qu’est-ce qui vous fera dire que votre entreprise a rĂ©ussi sa transformation ?
Je ferais une rĂ©ponse trĂšs corporate mais dans laquelle je crois fondamentalement. Je dirais que Microsoft aura rĂ©ussi sa* transformation quand unanimement et spontanĂ©ment l’ambition dressĂ©e par Satya Nadella « to empower every person and every organization on the planet to achieve more » sera incontestablement reconnue Ă  l’échelle planĂ©taire.

Quel livre vous a récemment le plus influencé ?
« The Internet is My Religion » http://www.internetismyreligion.com/ de Jim Gilliam crĂ©ateur/fondateur de nationbuilder.com. Pourquoi en une phrase ? Car c’est un ouvrage qui incarne trĂšs bien l’aphorisme « ce qui ne tue pas rend plus fort. »

Twitter : https://twitter.com/sebimbert
LinkedIn : http://www.linkedin.com/in/sebim
Site Internet : https://www.microsoft.com/fr-fr/

#PortraitDeCDO – SĂ©bastien Imbert – Microsoft from OCTO Technology

Retrouvez les derniers #PortraitDeCDO

#PortraitDeCDO – François-RĂ©gis Martin – BNP Paribas Leasing Solutions from OCTO Technology

#PortraitDeCDO – Marion Vincent-Ceyrat – Comexposium from OCTO Technology

#PortraitDeCDO – MACSF – Edouard Perrin from OCTO Technology

PortraitDeCDO – Toupargel – JĂ©rĂŽme Dalidet from OCTO Technology

EnregistrerEnregistrerEnregistrerEnregistrer

Catégories: Blog Société

#PortraitDeCDO – SĂ©bastien Imbert – Microsoft

lun, 06/19/2017 - 06:30
#PortraitDeCDO – SĂ©bastien Imbert – Microsoft

DĂ©couvrez pour le SeiziĂšme #PortraitDeCDO, avec le portrait de SĂ©bastien Imbert Chief Digital Marketing Officer de Microsoft. Vous allez pouvoir dĂ©couvrir les enjeux du numĂ©rique pour son entreprise, ses contraintes au quotidien ou encore son rĂŽle au sein de sa sociĂ©tĂ© pour faire bouger les lignes du digital. Des insights prĂ©cieux que vous pourrez comparer au fur et Ă  mesure que les portraits s’Ă©graineront dans les semaines Ă  venir.

microsoft

En une phrase, comment définiriez-vous la notion de transformation digitale ?
Vaste « notion » qui a gĂ©nĂ©rĂ© plus d’une phrase dans de trĂšs nombreux ouvrages, mais en en quelques mots je dirais que c’est une capacitĂ© et une condition ; une capacitĂ© d’intĂ©grer dans sa stratĂ©gie les infinies possibilitĂ©s du « Digital » au bĂ©nĂ©fice de la crĂ©ation de valeur pour les clients, les employĂ©es, les partenaires de l’entreprise et une condition de survie de l’entreprise elle-mĂȘme Ă  moyen ou long-terme.

Comment décririez-vous votre rÎle de CDO ?
Souvent pour dĂ©crire mon rĂŽle j’utilise l’image d’une mappemonde. Quand on regarde l’ensemble des territoires sur une mappemonde on voit un univers oĂč les limites, les frontiĂšres Ă©voluent extrĂȘmement lentement. Si on transpose cette mappemonde dans univers digital oĂč les continents, les pays sont constituĂ©s d’utilisateurs de services numĂ©riques (i.e. Facebook, LinkedIn, Office365, 
) on arrive dans un univers oĂč les limites, les frontiĂšres sont en Ă©volutions et variations permanentes. Un univers ou aucune boussole de rĂ©fĂ©rence n’a vĂ©ritablement Ă©tĂ© inventĂ©e. En rĂ©sumĂ©, dans cet univers oĂč aucune boussole de rĂ©fĂ©rence n’a Ă©tĂ© crĂ©Ă©e, le rĂŽle du CDO, mon rĂŽle de CDO, est de contribuer :

1) à identifier les destinations futures et 2) à organiser la « logistique » de ce « voyage »

3) Ă  atteindre les prioritĂ©s marketing et business en Ă©vitant de tomber dans l’activation/la crĂ©ation de tactiques permanentes ce qui peut trĂšs facilement arriver « au milieu » de l’ocĂ©an digital.

Quelles difficultés rencontrez-vous au quotidien ?
Le mĂ©tier de CDO porte en lui deux Ă©lĂ©ments intrinsĂšquement abstraits. C’est Ă  la fois un point d’équilibre et Ă  la fois un paradoxe.

Un point d’équilibre entre l’infiniment grand et l’infiniment petit. Tel un « tai-chi master » le CDO fait un grand Ă©cart au quotidien entre des donnĂ©es, des points de contacts clients, des services, des fonctionnalitĂ©s, des technologies, des outils (cf. « Marketing Technology Landscape Supergraphic (2017): Martech 5000 »  de Chiefmartec.com) , des attentes,
 en super-croissances permanentes et des clients qui ont une bande-passante temps de plus en plus en Ă©troite (NB : certaines Ă©tudes indiquent que l’attention de l’humain est devenue infĂ©rieure Ă  celle du poisson rouge !) et des budgets bien souvent sous contraintes.

Qu’est-ce que j’entends en parlant de paradoxe ? CDO, c’est :

  • un mĂ©tier qui est Ă  la fois de plus en plus nĂ©cessaire et qui est Ă  la fois supposĂ© comme souvent soulignĂ© disparaitre prochainement (Ă  chacun son point de vue Ă  ce niveau).
  • un mĂ©tier qui est Ă  la fois dans le physique est dans le digital ; un mĂ©tier qui est par essence « phygital ».
  • un mĂ©tier oĂč il est absolument nĂ©cessaire d’avoir une hauteur de vue Ă  360° dans l’entreprise tout en Ă©tant capable de faire du « deep zoom » sur des micro-points, des micro-actions qui sont pourtant essentielles.
  • un mĂ©tier qui nĂ©cessite des expertises sans devenir un expert sur toutes les technos, sur les tous les outils ou process dont il va s’assurer le bon fonctionnement, la bonne coordination au quotidien.
  • un mĂ©tier qui opĂšre sur un univers omniprĂ©sent dans le quotidien de toutes et tous, le digital, mais pour lequel on n’a jamais eu autant besoin de formations internes et externes.

Pensez-vous qu’il faille ĂȘtre technophile pour exercer le mĂ©tier de CDO ?
Il n’est pas nĂ©cessaire d’ĂȘtre un technologue ou un « distinguish engineer » pour ĂȘtre un bon CDO ; en revanche ĂȘtre « technophile » est une condition absolument nĂ©cessaire tant le spectre des mĂ©tiers experts et technos avec lesquels on opĂšre au quotidien est large. Sans cela il me semble difficile pour un CDO de gĂ©nĂ©rer un Ă©lĂ©ment essentiel pour la croissance des entreprises : de « l’impact ».

Et au-delĂ  d’ĂȘtre « technophile », ĂȘtre « curieux » et « ouvert » sont selon-moi des qualitĂ©s essentielles pour avoir un « digital mindset » porteur.

Pensez-vous que CDO est un mĂ©tier d’avenir ?
Contrairement Ă  ce que l’on peut gĂ©nĂ©ralement lire, j’en suis convaincu. A un point prĂšs, c’est que l’intitulĂ© du titre Ă©voluera probablement. A l’ùre oĂč tout est numĂ©rique et oĂč le numĂ©rique est dans tout, c’est vraisemblablement le terme « Digital » qui disparaitra. On Ă©volue, on Ă©voluera vers des titres du type « Omnicanal Lead Director » « Chief Transformation Officer », « Chief Revenue/Demand Gen Officer », ou plus traditionnellement « CMO » voire « CEO » ;)

Et quoi qu’il arrive, comme on dit « ce n’est pas le titre qui fait l’homme, c’est l’homme qui fait le titre ».

Quelle est pour vous la prochaine innovation qui risque de chambouler votre secteur d’activitĂ© ?
Sans aucun doute, une « innovation » qui chamboule mon secteur d’activitĂ©, voire tous les secteurs d’activitĂ© Ă  l’échelle planĂ©taire, est l’intelligence artificielle. Pour notre CEO, Satya Nadella, l’intelligence artificielle « is the ‘ultimate breakthrough » – Progressivement, en lien avec le cloud, le « computing » gĂ©nĂ©ralisĂ©, l’intelligence artificielle sera partout, disponible depuis tout objet ou service connectĂ©. De la capacitĂ© Ă  interprĂ©ter des donnĂ©es structurĂ©es/non structurĂ©es en trĂšs grand nombre, Ă  la capacitĂ© d’interprĂ©ter des images (vision), des textes, des langues ou Ă  Ă©tablir des modĂšles de dĂ©tection de la fraude ou de marketing prĂ©dictif, nous ne sommes qu’au dĂ©but de multiples transformations et innovations associĂ©es Ă  l’intelligence artificielle.

Plus que jamais il est trĂšs difficile de prĂ©dire quelle sera telle ou telle technologie innovante Ă  trĂšs fort potentiel transformationnelle mais pour ma part et comme de nombreux autres j’estime que dans les 20 ans Ă  venir la combinatoire [Intelligence Artificielle/BlockChain/Quantum Computing] sera un « game changer ultime. »

Quels sont les enjeux de digitalisation de votre entreprise à l’heure actuelle ?
Aujourd’hui Microsoft est une « Cloud Company » qui se transforme tout en contribuant Ă  la transformation de ses clients et partenaires.

D’un point de vue enjeux marchĂ©, il y a trois domaines oĂč Microsoft se positionne de façon claire et marquĂ©e tant d’un point de vue crĂ©ations de nouveaux services que de nouveaux usages innovants :

  • Comme dĂ©jĂ  Ă©voquĂ© il y’a l’intelligence artificielle qui fait partie aujourd’hui de tous nos produits et que l’on rend accessible sur n’importe quels types de « pĂ©riphĂ©riques » ou systĂšmes. Je pense notamment Ă  Cortana qui est Ă  la fois un agent numĂ©rique et une plateforme. Illustrations concrĂštes : les nouveaux speakers de Harman Kardon, Invoke ou « Cortana Intelligence Suite »
  • La confiance numĂ©rique ou comment faire en sorte que chacun puisse innover en toute sĂ©curitĂ© et en respectant sans compromis l’intĂ©gritĂ© des donnĂ©es collectĂ©es et traitĂ©es. Un enjeu de premier plan dans les « heures » prĂ©cĂ©dents l’arrivĂ©e de GDPR.
  • Le « future of work » avec la crĂ©ation de nouveaux produits tels que le « Surface Hub » ou Microsoft « Office Delve » qui fait partie d’Office 365.

Les enjeux de digitalisation font partie par dĂ©faut du nouvel ADN de Microsoft. Ils sont multiples et larges mais je dirai son enjeu principal est de continuellement s’appliquer Ă  elle-mĂȘme ce que Microsoft propose Ă  ses clients et partenaires en matiĂšre de transformation :

  • DĂ©velopper le meilleur niveau d’expĂ©rience et d’engagement clients,
  • Contribuer Ă  l’efficacitĂ© et Ă  l’agilitĂ© des employĂ©s,
  • Optimiser, « fluidifier » les processus de l’entreprise pour dĂ©cloisonner voire effacer la notion de « silo »,
  • Transformer les processus de crĂ©ations de produits, en intĂ©grant notamment les retours des utilisateurs.

Citez-moi une marque/entreprise qui, pour vous, a clairement réussi à adresser les enjeux du digital ?
A mon sens, Ă  ce niveau, intĂ©ressant de se pencher sur des entreprises « brick & mortar » plus que centenaires. Il est beaucoup plus difficile de remettre en cause des modĂšles Ă©tablis depuis de longues annĂ©es dans ce type d’entreprise que d’en crĂ©er des tous nouveaux « from scratch » pour des nouveaux entrants (i.e. start-up).

Contexte donnĂ©, pour moi, une entreprise qui a rĂ©ussi Ă  trĂšs bien adresser les enjeux du digital est Schneider Electric. Aujourd’hui Schneider n’est pas qu’un groupe industriel c’est Ă  la fois un groupe industriel et Ă  la fois une « Digital Company ». Elle incarne pleinement ce qui a Ă©tĂ© soulignĂ© par Marc Andreesen il y a quelques annĂ©es « today, every company is a software company ».

Schneider a notamment rĂ©ussi Ă  mettre en musique les possibilitĂ©s du digital/du cloud pour proposer des services Ă©volutifs d’équipement connectĂ©s et d’analyse de donnĂ©es. Et ce pour de nombreuses industries majeures telles que la santĂ©, l’énergie ou la construction.

Egalement, au cours des derniĂšres annĂ©es Schneider a procĂ©dĂ© Ă  de nombreuses acquisitions et a rĂ©ussi dans un esprit « software company » Ă  orchestrer au mieux les diffĂ©rentes expertises anciennes et nouvelles de l’entreprise au profit de la mise en place de nouveaux produits ou services.

C’est pour ces raisons que Schneider est selon-moi un trĂšs bon exemple de transformation digitale rĂ©ussie.

Sans contrainte, vous avez la possibilité de commencer 3 projets de transformation dans votre entreprise : quels seraient-ils ?
On est dĂ©jĂ  d’une certaine maniĂšre une entreprise « GloCal », Globale et Locale.

  1. Sans contraintes je continuerai Ă  faire Ă©voluer voire Ă  transformer notre « MartTech » architecture que j’estime dĂ©jĂ  ĂȘtre extrĂȘmement robuste et innovante (voir cet article Frenchweb pour en avoir un aperçu). Comment ? En permettant Ă  chaque filiale d’y avoir un nombre dĂ©terminĂ© d’acteurs locaux de leur Ă©cosystĂšme (partenaires/start-up) et de regarder rĂ©guliĂšrement, filiale par filiale les nouveaux services disruptifs Ă  plus fort niveau d’impact client et business. C’est par exemple quelque chose que nous avons fait en France avec l’activation au niveau mondial du service français « d’employee brand advocacy » www.sociabble.com
  2. Un parcours « phygital » certifiant de « Transformation Digitale » pour les PME et TPE
  3. “Content is king, media is queen and context takes it all”, je crĂ©erai, au-delĂ  de la France une « Modern Content Management Team » transverse pour offrir de façon individualisĂ©e le meilleur niveau d’expĂ©rience Ă©ditoriale de marque quelque-soit le pĂ©riphĂ©rique utilisĂ© par chaque client Ă  un instant t.

Quel est l’impact de la transformation sur la culture et l’organisation de votre entreprise ?
DĂ©finitivement un des impacts de la transformation sur Microsoft est de l’ordre du collaboratif. Aujourd’hui, l’impact d’un collaborateur de Microsoft est essentiellement associĂ© Ă  la maniĂšre dont il a contribuĂ© aux succĂšs des autres et Ă  la maniĂšre dont il a intĂ©grĂ© les idĂ©es des autres au profit du succĂšs de ses projets. Et au-delĂ  du succĂšs, on cĂ©lĂšbre, on considĂšre aussi plus que jamais l’échec comme une source d’apprentissage extrĂȘmement prĂ©cieuse.

Egalement, on peut noter que la transformation Ă  dĂ©finitivement fait Ă©voluer Microsoft dans sa relation avec l’écosystĂšme du numĂ©rique. Des concurrents d’hier sont des partenaires d’aujourd’hui ou plus que jamais des « coopĂ©titeurs » (Apple, Google, RedHat/Linux, SAP, Oracle, Salesforce etc.)

Demain, qu’est-ce qui vous fera dire que votre entreprise a rĂ©ussi sa transformation ?
Je ferais une rĂ©ponse trĂšs corporate mais dans laquelle je crois fondamentalement. Je dirais que Microsoft aura rĂ©ussi sa* transformation quand unanimement et spontanĂ©ment l’ambition dressĂ©e par Satya Nadella « to empower every person and every organization on the planet to achieve more » sera incontestablement reconnue Ă  l’échelle planĂ©taire.

Quel livre vous a récemment le plus influencé ?
« The Internet is My Religion » http://www.internetismyreligion.com/ de Jim Gilliam crĂ©ateur/fondateur de nationbuilder.com. Pourquoi en une phrase ? Car c’est un ouvrage qui incarne trĂšs bien l’aphorisme « ce qui ne tue pas rend plus fort. »

Twitter : https://twitter.com/sebimbert
LinkedIn : http://www.linkedin.com/in/sebim
Site Internet : https://www.microsoft.com/fr-fr/

#PortraitDeCDO – SĂ©bastien Imbert – Microsoft from OCTO Technology

Retrouvez les derniers #PortraitDeCDO

#PortraitDeCDO – François-RĂ©gis Martin – BNP Paribas Leasing Solutions from OCTO Technology

#PortraitDeCDO – Marion Vincent-Ceyrat – Comexposium from OCTO Technology

#PortraitDeCDO – MACSF – Edouard Perrin from OCTO Technology

PortraitDeCDO – Toupargel – JĂ©rĂŽme Dalidet from OCTO Technology

EnregistrerEnregistrerEnregistrerEnregistrer

Catégories: Blog Société

Monitorer votre infra avec Telegraf, InfluxDB et Grafana

jeu, 06/15/2017 - 13:00

Dans un article précédent, nous avons vu comment monitorer avec Prometheus et Grafana une infrastructure dynamique basée sur Kubernetes.

Nous allons voir aujourd’hui comment monitorer une infrastructure plus classique avec Telegraf pour la collecte de mĂ©triques, InfluxDB pour le stockage et Grafana pour l’affichage et l’alerting. Nous nommerons cette solution TIG, dans la suite de cet article. Nous avons choisi ces outils, mais ils peuvent ĂȘtre remplacĂ©s par d’autres. Nous allons comparer Ă©galement cette solution Ă  d’autres outils du marchĂ© (Zabbix et Prometheus)

Architecture

Telegraf Architecture

Telegraf

Telegraf est un agent de récupération de métriques, 1 seul agent est nécessaire par VM. Cet agent sait récupérer des métriques exposées au format Prometheus et propose 2 modes de récupération des métriques, via :

  • push : la mĂ©trique est poussĂ©e dans Telegraf par le composant qui l’expose
  • pull : Telegraf rĂ©cupĂšre la mĂ©trique en interrogeant le composant qui l’expose (le mode le plus utilisĂ©)

Les mĂ©triques sont insĂ©rĂ©es au fil de l’eau dans InfluxDB.

InfluxDB

InfluxDB est une Time Series Database (TSDB) écrite en Go dont les principaux avantages sont les performances, la durée de rétention importante et la scalabilité (nous verrons plus loin sous quelles conditions).

Grafana

Grafana est un outil supervision simple et Ă©lĂ©gant, permettant de s’intĂ©grer Ă  une TSDB, ici InfluxDB. Grafana expose dans des dashboards les mĂ©triques brutes ou agrĂ©gĂ©es provenant d’InfluxDB et permet de dĂ©finir de maniĂšre honteusement simple des seuils d’alertes et les actions associĂ©es.

 

Cas d’utilisation

Dans cet article, nous allons monitorer une architecture simple :

  • une application web en Go exposĂ©e derriĂšre un Nginx
  • une base de donnĂ©e Mysql sollicitĂ©e par un cron

Telegraph permet de rĂ©cupĂ©rer par le biais de plugins les mĂ©triques des composants, ainsi que les mĂ©triques systĂšmes. Dans le cas nominal, Telegraf rĂ©cupĂšre ses mĂ©triques en mode pull. Cependant, dans le cas d’un cron ou d’un batch qui s’exĂ©cute pĂ©riodiquement, la rĂ©cupĂ©ration des mĂ©triques se fait en mode push (c’est au cron ou au batch d’envoyer les mĂ©triques Ă  Telegraf). Pour ce cas d’usage, nous allons utiliser le plugin http_listener qui permet Ă  Telegraf d’écouter en http sur un port afin de rĂ©cupĂ©rer les mĂ©triques envoyĂ©es par le cron/batch.

Telegraf cas d'utilisation

 

Installation

Pour cet article, l’installation se fera sous Ubuntu 16.04 LTS.

InfluxDB

Ajoutons le repo APT officiel d’InfluxDB :

curl -sL https://repos.influxdata.com/influxdb.key | sudo apt-key add -
source /etc/lsb-release
echo "deb https://repos.influxdata.com/${DISTRIB_ID,,} ${DISTRIB_CODENAME} stable" | sudo tee /etc/apt/sources.list.d/influxdb.list

Installons le package :

sudo apt-get update
sudo apt-get install influxdb

DĂ©marrons le service :

sudo systemctl start influxd
Telegraf

Ajoutons le repo APT officiel de Telegraf :

curl -sL https://repos.influxdata.com/influxdb.key | sudo apt-key add -
source /etc/lsb-release
echo "deb https://repos.influxdata.com/${DISTRIB_ID,,} ${DISTRIB_CODENAME} stable" | sudo tee /etc/apt/sources.list.d/influxdb.list

Installons le package :

sudo apt-get update
sudo apt-get install telegraf

DĂ©marrons le service :

sudo systemctl start telegraf
Grafana

Ajoutons le repo APT officiel de Grafana :

curl https://packagecloud.io/gpg.key | sudo apt-key add -
echo "deb https://packagecloud.io/grafana/stable/debian/ jessie main" | sudo tee /etc/apt/sources.list.d/grafana.list

Installons le package :

sudo apt-get update
sudo apt-get install grafana

DĂ©marrons le service :

systemctl daemon-reload
systemctl start grafana-server
Configuration

InfluxDB

Nous allons créer une base de données pour pouvoir pousser les données remontées par Telegraf :

influx -execute "CREATE DATABASE influx_db"

CrĂ©ons l’utilisateur influx_user :

influx -execute “CREATE USER influx_user WITH PASSWORD 'influx_password'”
influx -execute “GRANT ALL ON influx_db TO influx_user

Il est possible de créer une retention policy pour déterminer la durée de conservation des données :

influx -execute ‘CREATE RETENTION POLICY "one_year" ON "influx_db" DURATION 365d’
Telegraf

Telegraf fonctionne sous forme de plugin Ă  activer pour rĂ©cupĂ©rer les mĂ©triques. L’écosystĂšme de plugins est riche : il y a des plugins pour monitorer nginx, cassandra, haproxy, postgresql
 Nous allons nous intĂ©resser Ă  quelques plugins en particulier pour notre exemple. Dans l’ensemble, les plugins sont simples Ă  configurer.

Nous allons voir ici des extraits de configuration.

Mode pull MĂ©triques systĂšmes

Les plugins permettant de remonter les métriques systÚmes :

  • cpu
  • disk
  • diskio
  • kernel
  • mem
  • processes
  • swap
  • system
$ head /etc/telegraf/telegraf.d/system.conf
 
[[inputs.cpu]]
## Whether to report per-cpu stats or not
percpu = true
## Whether to report total system cpu stats or not
totalcpu = true
## If true, collect raw CPU time metrics.
collect_cpu_time = false


MĂ©triques MySQL
$ head /etc/telegraf/telegraf.d/mysql.conf

[[inputs.mysql]]
servers = ["db_user:db_password@tcp(127.0.0.1:3306)/?tls=false"]


MĂ©triques au format prometheus

Pour notre exemple, nous avons une application en Go qui expose des mĂ©triques au format prometheus sur l’url http://localhost:8080/metrics.
Nous allons utiliser le plugin prometheus pour récupérer ces données :

$ cat /etc/telegraf/telegraf.d/app.conf

[[inputs.prometheus]]
urls = ["http://localhost:8080/metrics"]
Mode push Plugin HTTP_LISTENER

Le plugin http_listener fonctionne en mode push. Il ouvre un port http et attend qu’on lui pousse des mĂ©triques.

$ cat /etc/telegraf/telegraf.d/http_listener.conf

## Influx HTTP write listener
[[inputs.http_listener]]
## Address and port to host HTTP listener on
service_address = ":8186"

## timeouts
read_timeout = "10s"
write_timeout = "10s"

Il faut ensuite envoyer les métriques au format InfluxDB line-protocol :

$ curl -i -XPOST 'http://localhost:8186/write' --data-binary 'account_deleted,host=server01,region=us-west value=32 1434055562000000000'
Configuration du backend

Pour configurer le backend, nous allons utiliser le plugin output InfluxDB.

$ cat /etc/telegraf/telegraf.conf


[[outputs.influxdb]]
urls = ["http://localhost:8086"]
database = "influx_db"
username = "influx_user"
password = "influx_password"



Pour finir, redémarrons le service pour prendre en compte la configuration :

sudo systemctl restart telegraf

La configuration des plugins est documenté exhaustivement dans le fichier de configuration de base : /etc/telegraf/telegraf.conf

Grafana

La premiĂšre Ă©tape dans Grafana est d’ajouter la source de donnĂ©e (InfluxDB dans notre cas). Allons dans “Datasource” puis “Add Datasource” et ajoutons la base Influxdb.

Database : influx_db
Username : influx_user
Password : influx_password

Grafana - Add data source

Ensuite pour créer les dashboards, vous pouvez récupérer des dashboards de la communauté Grafana ou créer vos propres dashboards. Pour notre exemple, nous avons importé le dashboard suivant prévu pour Telegraf.

Grafana - Dashboard

Il est possible d’ajouter des alertes dans les dashboards, mais nous n’allons pas dĂ©tailler ce point dans cet article. Vous pouvez trouver des informations dans la documentation.

Note : Si vous utilisez Grafana en HA, pour le moment l’alerting n’est pas implĂ©mentĂ© en mode cluster. Du coup, il faut s’assurer de l’activer sur un seul des noeuds pour ne pas recevoir les alertes en double. NĂ©anmoins, si le noeud tombe, il n’y a plus d’alerting.

Comparaison TIG vs Zabbix

Avantages de TIG :

  • La configuration est plus simple (mĂ©triques et graphes)
    • Pour rĂ©cupĂ©rer une nouvelle mĂ©trique, il suffit de configurer en quelques lignes un plugin dans Telegraf, puis crĂ©er un dashboard dans Grafana.
  • La configuration est plus souple
    • Dans Zabbix on a besoin de dĂ©crire prĂ©cisĂ©ment chacune des mĂ©triques remontĂ©es, alors que dans TIG, InfluxDB n’a pas besoin de connaĂźtre la mĂ©trique Ă  l’avance pour pouvoir la stocker.
  • Simple sur une infra dynamique
    • Exemple: Autoscaling sur les principaux cloud provider, les VMs nouvellement crĂ©Ă©s (avec Telegraf configurĂ©) poussent auto-magiquement (sans configuration supplĂ©mentaire) dans InfluxDB.
  • Historique plus complet
    • La profondeur d’historique de Zabbix et d’InfluxDB est Ă©quivalente, nĂ©anmoins  Zabbix dispose d’une stratĂ©gie d’échantillonnage (configurable) entraĂźnant une dĂ©gradation de la qualitĂ© de la donnĂ©e sur le long terme.
  • Les dashboards dans Grafana sont plus conviviaux et plus simples

 

Avantages de Zabbix :

  • Gestion des droits
    • La gestion des droits est plus fine sur Zabbix
  • UtilisĂ© en prod depuis des annĂ©es
    • Release 1.0 sorti le 23 mars 2004
    • Stable, complet et reconnu
  • Ressources de la communautĂ© (templates, alertes, agent 
)
    • Les agents Zabbix sont disponibles pour de nombreux systĂšmes d’exploitation
    • De nombreux templates pour configurer les mĂ©triques/alertes/graphes sont disponibles sur internet

 

TIG vs Prometheus TIG vs Prometheus

Avantages de  TIG :

  • Historique plus complet (plusieurs annĂ©es vs plusieurs heures/semaines)
    • Le but premier de Prometheus est le monitoring temps rĂ©el, la rĂ©tention par dĂ©faut est de 1 mois. Il est cependant possible d’augmenter cette rĂ©tention.
  • Besoin d’un seul agent par VM
    • Telegraf permet de rĂ©cupĂ©rer plusieurs mĂ©triques avec un seul agent et pousse les donnĂ©es dans InfluxDB.
  • C’est l’agent Telegraf qui envoie les donnĂ©es Ă  InfluxDB
    • Pas besoin d’ouvrir de multiples ports comme c’est le cas avec Prometheus.

 

Avantages de Prometheus :

  • Prometheus peut utiliser des services discovery pour savoir quels sont les services Ă  monitorer
    • Exemple: Dans des environnements type Kubernetes, Docker, Prometheus est particuliĂšrement adaptĂ© pour rĂ©cupĂ©rer les mĂ©triques de conteneurs Ă  durĂ©e de vie variable.

 

Conclusion

Dans la stack TIG nous avons apprĂ©ciĂ© la simplicitĂ© d’installation et de configuration, la souplesse de collecte des mĂ©triques et la profondeur d’historique.

La version opensource d’InfluxDB ne scale pas mais il est possible de scaler en passant sur les versions payantes InfluxEnterprise ou InfluxCloud. Nous n’avons, Ă  l’heure actuelle, pas de retour d’expĂ©rience concernant ces deux derniers produits.

Pour la scalabilitĂ©, il est Ă©galement possible d’utiliser OpenTSDB qui est une “Time Serie Database” open source, mais elle est bien plus compliquĂ©e Ă  installer, et nous n’avons pas de retour sur son utilisation.

Il est possible de mettre Grafana en HA. NĂ©anmoins, le mode cluster de l’alerting n’est pas encore implĂ©mentĂ©. Cela signifie que soit on ne dĂ©finit les alertes que sur un nƓud, soit on les dĂ©finit sur tous les nƓuds mais les notifications seront dupliquĂ©es.

La modularitĂ© de cette stack nous permet si besoin d’utiliser :

  • d’autres collecteurs tels que Snap  (dans le cas, par exemple, oĂč Telegraf ne proposerait pas de plugin adaptĂ©).
  • d’autres outils d’alerting tels que Kapacitor que nous Ă©tudierons prochainement.

Le cas d’utilisation que nous avons prĂ©sentĂ© est disponible sur ce repo : https://gitlab.octo.com/tpatte/monitoring_influxdb

 

 

Articles suggested :

  1. Exemple d’utilisation de Prometheus et Grafana pour le monitoring d’un cluster Kubernetes
  2. Nous Ă©tions Ă  la KubeCon Europe (2/2)

Catégories: Blog Société

Monitorer votre infra avec Telegraf, InfluxDB et Grafana

jeu, 06/15/2017 - 13:00

Dans un article précédent, nous avons vu comment monitorer avec Prometheus et Grafana une infrastructure dynamique basée sur Kubernetes.

Nous allons voir aujourd’hui comment monitorer une infrastructure plus classique avec Telegraf pour la collecte de mĂ©triques, InfluxDB pour le stockage et Grafana pour l’affichage et l’alerting. Nous nommerons cette solution TIG, dans la suite de cet article. Nous avons choisi ces outils, mais ils peuvent ĂȘtre remplacĂ©s par d’autres. Nous allons comparer Ă©galement cette solution Ă  d’autres outils du marchĂ© (Zabbix et Prometheus)

Architecture

Telegraf Architecture

Telegraf

Telegraf est un agent de récupération de métriques, 1 seul agent est nécessaire par VM. Cet agent sait récupérer des métriques exposées au format Prometheus et propose 2 modes de récupération des métriques, via :

  • push : la mĂ©trique est poussĂ©e dans Telegraf par le composant qui l’expose
  • pull : Telegraf rĂ©cupĂšre la mĂ©trique en interrogeant le composant qui l’expose (le mode le plus utilisĂ©)

Les mĂ©triques sont insĂ©rĂ©es au fil de l’eau dans InfluxDB.

InfluxDB

InfluxDB est une Time Series Database (TSDB) écrite en Go dont les principaux avantages sont les performances, la durée de rétention importante et la scalabilité (nous verrons plus loin sous quelles conditions).

Grafana

Grafana est un outil supervision simple et Ă©lĂ©gant, permettant de s’intĂ©grer Ă  une TSDB, ici InfluxDB. Grafana expose dans des dashboards les mĂ©triques brutes ou agrĂ©gĂ©es provenant d’InfluxDB et permet de dĂ©finir de maniĂšre honteusement simple des seuils d’alertes et les actions associĂ©es.

 

Cas d’utilisation

Dans cet article, nous allons monitorer une architecture simple :

  • une application web en Go exposĂ©e derriĂšre un Nginx
  • une base de donnĂ©e Mysql sollicitĂ©e par un cron

Telegraph permet de rĂ©cupĂ©rer par le biais de plugins les mĂ©triques des composants, ainsi que les mĂ©triques systĂšmes. Dans le cas nominal, Telegraf rĂ©cupĂšre ses mĂ©triques en mode pull. Cependant, dans le cas d’un cron ou d’un batch qui s’exĂ©cute pĂ©riodiquement, la rĂ©cupĂ©ration des mĂ©triques se fait en mode push (c’est au cron ou au batch d’envoyer les mĂ©triques Ă  Telegraf). Pour ce cas d’usage, nous allons utiliser le plugin http_listener qui permet Ă  Telegraf d’écouter en http sur un port afin de rĂ©cupĂ©rer les mĂ©triques envoyĂ©es par le cron/batch.

Telegraf cas d'utilisation

 

Installation

Pour cet article, l’installation se fera sous Ubuntu 16.04 LTS.

InfluxDB

Ajoutons le repo APT officiel d’InfluxDB :

curl -sL https://repos.influxdata.com/influxdb.key | sudo apt-key add -
source /etc/lsb-release
echo "deb https://repos.influxdata.com/${DISTRIB_ID,,} ${DISTRIB_CODENAME} stable" | sudo tee /etc/apt/sources.list.d/influxdb.list

Installons le package :

sudo apt-get update
sudo apt-get install influxdb

DĂ©marrons le service :

sudo systemctl start influxd
Telegraf

Ajoutons le repo APT officiel de Telegraf :

curl -sL https://repos.influxdata.com/influxdb.key | sudo apt-key add -
source /etc/lsb-release
echo "deb https://repos.influxdata.com/${DISTRIB_ID,,} ${DISTRIB_CODENAME} stable" | sudo tee /etc/apt/sources.list.d/influxdb.list

Installons le package :

sudo apt-get update
sudo apt-get install telegraf

DĂ©marrons le service :

sudo systemctl start telegraf
Grafana

Ajoutons le repo APT officiel de Grafana :

curl https://packagecloud.io/gpg.key | sudo apt-key add -
echo "deb https://packagecloud.io/grafana/stable/debian/ jessie main" | sudo tee /etc/apt/sources.list.d/grafana.list

Installons le package :

sudo apt-get update
sudo apt-get install grafana

DĂ©marrons le service :

systemctl daemon-reload
systemctl start grafana-server
Configuration

InfluxDB

Nous allons créer une base de données pour pouvoir pousser les données remontées par Telegraf :

influx -execute "CREATE DATABASE influx_db"

CrĂ©ons l’utilisateur influx_user :

influx -execute “CREATE USER influx_user WITH PASSWORD 'influx_password'”
influx -execute “GRANT ALL ON influx_db TO influx_user

Il est possible de créer une retention policy pour déterminer la durée de conservation des données :

influx -execute ‘CREATE RETENTION POLICY "one_year" ON "influx_db" DURATION 365d’
Telegraf

Telegraf fonctionne sous forme de plugin Ă  activer pour rĂ©cupĂ©rer les mĂ©triques. L’écosystĂšme de plugins est riche : il y a des plugins pour monitorer nginx, cassandra, haproxy, postgresql
 Nous allons nous intĂ©resser Ă  quelques plugins en particulier pour notre exemple. Dans l’ensemble, les plugins sont simples Ă  configurer.

Nous allons voir ici des extraits de configuration.

Mode pull MĂ©triques systĂšmes

Les plugins permettant de remonter les métriques systÚmes :

  • cpu
  • disk
  • diskio
  • kernel
  • mem
  • processes
  • swap
  • system
$ head /etc/telegraf/telegraf.d/system.conf
 
[[inputs.cpu]]
## Whether to report per-cpu stats or not
percpu = true
## Whether to report total system cpu stats or not
totalcpu = true
## If true, collect raw CPU time metrics.
collect_cpu_time = false


MĂ©triques MySQL
$ head /etc/telegraf/telegraf.d/mysql.conf

[[inputs.mysql]]
servers = ["db_user:db_password@tcp(127.0.0.1:3306)/?tls=false"]


MĂ©triques au format prometheus

Pour notre exemple, nous avons une application en Go qui expose des mĂ©triques au format prometheus sur l’url http://localhost:8080/metrics.
Nous allons utiliser le plugin prometheus pour récupérer ces données :

$ cat /etc/telegraf/telegraf.d/app.conf

[[inputs.prometheus]]
urls = ["http://localhost:8080/metrics"]
Mode push Plugin HTTP_LISTENER

Le plugin http_listener fonctionne en mode push. Il ouvre un port http et attend qu’on lui pousse des mĂ©triques.

$ cat /etc/telegraf/telegraf.d/http_listener.conf

## Influx HTTP write listener
[[inputs.http_listener]]
## Address and port to host HTTP listener on
service_address = ":8186"

## timeouts
read_timeout = "10s"
write_timeout = "10s"

Il faut ensuite envoyer les métriques au format InfluxDB line-protocol :

$ curl -i -XPOST 'http://localhost:8186/write' --data-binary 'account_deleted,host=server01,region=us-west value=32 1434055562000000000'
Configuration du backend

Pour configurer le backend, nous allons utiliser le plugin output InfluxDB.

$ cat /etc/telegraf/telegraf.conf


[[outputs.influxdb]]
urls = ["http://localhost:8086"]
database = "influx_db"
username = "influx_user"
password = "influx_password"



Pour finir, redémarrons le service pour prendre en compte la configuration :

sudo systemctl restart telegraf

La configuration des plugins est documenté exhaustivement dans le fichier de configuration de base : /etc/telegraf/telegraf.conf

Grafana

La premiĂšre Ă©tape dans Grafana est d’ajouter la source de donnĂ©e (InfluxDB dans notre cas). Allons dans “Datasource” puis “Add Datasource” et ajoutons la base Influxdb.

Database : influx_db
Username : influx_user
Password : influx_password

Grafana - Add data source

Ensuite pour créer les dashboards, vous pouvez récupérer des dashboards de la communauté Grafana ou créer vos propres dashboards. Pour notre exemple, nous avons importé le dashboard suivant prévu pour Telegraf.

Grafana - Dashboard

Il est possible d’ajouter des alertes dans les dashboards, mais nous n’allons pas dĂ©tailler ce point dans cet article. Vous pouvez trouver des informations dans la documentation.

Note : Si vous utilisez Grafana en HA, pour le moment l’alerting n’est pas implĂ©mentĂ© en mode cluster. Du coup, il faut s’assurer de l’activer sur un seul des noeuds pour ne pas recevoir les alertes en double. NĂ©anmoins, si le noeud tombe, il n’y a plus d’alerting.

Comparaison TIG vs Zabbix

Avantages de TIG :

  • La configuration est plus simple (mĂ©triques et graphes)
    • Pour rĂ©cupĂ©rer une nouvelle mĂ©trique, il suffit de configurer en quelques lignes un plugin dans Telegraf, puis crĂ©er un dashboard dans Grafana.
  • La configuration est plus souple
    • Dans Zabbix on a besoin de dĂ©crire prĂ©cisĂ©ment chacune des mĂ©triques remontĂ©es, alors que dans TIG, InfluxDB n’a pas besoin de connaĂźtre la mĂ©trique Ă  l’avance pour pouvoir la stocker.
  • Simple sur une infra dynamique
    • Exemple: Autoscaling sur les principaux cloud provider, les VMs nouvellement crĂ©Ă©s (avec Telegraf configurĂ©) poussent auto-magiquement (sans configuration supplĂ©mentaire) dans InfluxDB.
  • Historique plus complet
    • La profondeur d’historique de Zabbix et d’InfluxDB est Ă©quivalente, nĂ©anmoins  Zabbix dispose d’une stratĂ©gie d’échantillonnage (configurable) entraĂźnant une dĂ©gradation de la qualitĂ© de la donnĂ©e sur le long terme.
  • Les dashboards dans Grafana sont plus conviviaux et plus simples

 

Avantages de Zabbix :

  • Gestion des droits
    • La gestion des droits est plus fine sur Zabbix
  • UtilisĂ© en prod depuis des annĂ©es
    • Release 1.0 sorti le 23 mars 2004
    • Stable, complet et reconnu
  • Ressources de la communautĂ© (templates, alertes, agent 
)
    • Les agents Zabbix sont disponibles pour de nombreux systĂšmes d’exploitation
    • De nombreux templates pour configurer les mĂ©triques/alertes/graphes sont disponibles sur internet

 

TIG vs Prometheus TIG vs Prometheus

Avantages de  TIG :

  • Historique plus complet (plusieurs annĂ©es vs plusieurs heures/semaines)
    • Le but premier de Prometheus est le monitoring temps rĂ©el, la rĂ©tention par dĂ©faut est de 1 mois. Il est cependant possible d’augmenter cette rĂ©tention.
  • Besoin d’un seul agent par VM
    • Telegraf permet de rĂ©cupĂ©rer plusieurs mĂ©triques avec un seul agent et pousse les donnĂ©es dans InfluxDB.
  • C’est l’agent Telegraf qui envoie les donnĂ©es Ă  InfluxDB
    • Pas besoin d’ouvrir de multiples ports comme c’est le cas avec Prometheus.

 

Avantages de Prometheus :

  • Prometheus peut utiliser des services discovery pour savoir quels sont les services Ă  monitorer
    • Exemple: Dans des environnements type Kubernetes, Docker, Prometheus est particuliĂšrement adaptĂ© pour rĂ©cupĂ©rer les mĂ©triques de conteneurs Ă  durĂ©e de vie variable.

 

Conclusion

Dans la stack TIG nous avons apprĂ©ciĂ© la simplicitĂ© d’installation et de configuration, la souplesse de collecte des mĂ©triques et la profondeur d’historique.

La version opensource d’InfluxDB ne scale pas mais il est possible de scaler en passant sur les versions payantes InfluxEnterprise ou InfluxCloud. Nous n’avons, Ă  l’heure actuelle, pas de retour d’expĂ©rience concernant ces deux derniers produits.

Pour la scalabilitĂ©, il est Ă©galement possible d’utiliser OpenTSDB qui est une “Time Serie Database” open source, mais elle est bien plus compliquĂ©e Ă  installer, et nous n’avons pas de retour sur son utilisation.

Il est possible de mettre Grafana en HA. NĂ©anmoins, le mode cluster de l’alerting n’est pas encore implĂ©mentĂ©. Cela signifie que soit on ne dĂ©finit les alertes que sur un nƓud, soit on les dĂ©finit sur tous les nƓuds mais les notifications seront dupliquĂ©es.

La modularitĂ© de cette stack nous permet si besoin d’utiliser :

  • d’autres collecteurs tels que Snap  (dans le cas, par exemple, oĂč Telegraf ne proposerait pas de plugin adaptĂ©).
  • d’autres outils d’alerting tels que Kapacitor que nous Ă©tudierons prochainement.

Le cas d’utilisation que nous avons prĂ©sentĂ© est disponible sur ce repo : https://gitlab.octo.com/tpatte/monitoring_influxdb

 

 

Articles suggested :

  1. Exemple d’utilisation de Prometheus et Grafana pour le monitoring d’un cluster Kubernetes
  2. Nous Ă©tions Ă  la KubeCon Europe (2/2)

Catégories: Blog Société

Réalité Virtuelle, Augmentée, Mixte: Faisons le point

jeu, 06/15/2017 - 10:03

Cet article a pour vocation de tenter d’éclaircir les nuances entre ces diffĂ©rentes expĂ©riences immersives, mais aussi de vous donner un bref aperçu des diffĂ©rents pĂ©riphĂ©riques existants actuellement sur le marchĂ©.

La RĂ©alitĂ© Virtuelle – VR

Application de formation sur les conduites de gaz des techniciens de GRTgaz

La rĂ©alitĂ© virtuelle est une simulation d’un environnement virtuel ou rĂ©aliste.

Son but est de crĂ©er une expĂ©rience sensorielle en faisant principalement appel Ă  la vue et l’ouĂŻe. Le toucher peut-ĂȘtre aussi simulĂ© avec le retour de force dans des contrĂŽleurs.

Les autres sens (odorat et goût) sont encore trop peu sollicités pour le moment car nécessitant un appareillage contraignant et souvent intrusif.

Le dispositif principal utilisĂ© pour la VR est un casque qu’on appelle aussi HMD (Head-mounted Display).

 

Les principaux acteurs sur le marché sont :

  • Google Cardboard et Daydream
  • HTC Vive
  • Oculus Rift
  • Samsung GearVR
  • Sony Playstation VR

 

 

Les casques dominent largement ce secteur mais ne sont pas les seuls dispositifs à faire de la réalité virtuelle.

Un peu moins grand public, les salles immersives sont aussi appelĂ©es CAVE (Cave Automatic Virtual Environment). L’utilisateur est dans une piĂšce oĂč l’on projette des images sur les diffĂ©rents murs qui l’entourent. La perspective du point de vue de l’utilisateur est calculĂ©e en temps rĂ©el Ă  l’aide d’un systĂšme de capture de position.

L’expĂ©rience peut ĂȘtre amĂ©liorĂ©e avec un son multicanal et des images projetĂ©es en 3D (rendu stĂ©rĂ©oscopique) mais dans ce dernier cas l’utilisateur devra s’équiper de lunettes 3D comme celles que l’on retrouve au cinĂ©ma ou sur les TV 3D.

 

PlutĂŽt utilisĂ© dans l’industrie, l’architecture, la conception et le design. L’avantage de ce type d’installation est l’immersion totale, il n’est pas nĂ©cessaire de reprĂ©senter notre corps.

Il faut prĂ©voir Ă  la fois un espace et un budget consĂ©quent de l’ordre de plusieurs centaines de milliers d’euros.

La réalité augmentée et la réalité mixte

Vous avez surement dĂ©jĂ  entendu parlĂ© de la rĂ©alitĂ© augmentĂ©e mais avez-vous dĂ©jĂ  entendu parler de rĂ©alitĂ© mixte ? Si oui, peut-ĂȘtre que la diffĂ©rence entre les deux n’est pas assez claire.

Les dĂ©finitions sur les technologies Ă©mergentes se crĂ©ent, parfois changent et s’affinent dans le temps.
La réalité mixte est venue préciser certaines attentes que nous avions de la réalité augmentée. Certains disent que la réalité mixte est simplement ce que nous attendions de la réalité augmentée.

La RĂ©alitĂ© AugmentĂ©e – AR

Le principe est d’afficher des images 2D/3D ou des informations en les superposant au monde rĂ©el sur un Ă©cran transparent. Ces informations sont donc au premier plan mais elles doivent prendre en compte l’environnement dans lequel nous sommes. ConnaĂźtre la position GPS ne suffit pas, il faut aussi reconnaĂźtre oĂč nous regardons, reconnaĂźtre par les formes ou par l’image, les objets qui constituent notre environnement. Il faut donc un alignement spatial avec la rĂ©alitĂ©.

Une expĂ©rience AR peut ĂȘtre une altĂ©ration comprendre ici une augmentation ou diminution directe ou indirecte du monde rĂ©el.

L’altĂ©ration indirecte ou par intermĂ©diation est prĂ©sente quand le rĂ©el est captĂ© par une camĂ©ra puis restituĂ© sur l’écran en l’augmentant avec du contenu. Nous voyons donc une reprĂ©sentation du rĂ©el au travers du pĂ©riphĂ©rique. Le cerveau distingue donc les deux environnements, celui rĂ©el qui l’entoure et celui augmentĂ© retransmis sur l’Ă©cran, il n’y a pas de confusion entre les deux.

Nos smartphones peuvent proposer des expĂ©riences AR, ils prĂ©sentent l’avantage de possĂ©der un certain nombre de capteurs utiles et d’ĂȘtre mobiles, trĂšs rĂ©pandus et peu encombrants. Malheureusement, ceux-ci ne peuvent pas encore proposer une altĂ©ration directe de notre environnement, seulement une altĂ©ration sur la restitution du rĂ©el.

Pour avoir une altĂ©ration directe, il faut donc voir “à travers” les pĂ©riphĂ©riques qui couvrent une partie significative de notre champ de vision. Cela peut-ĂȘtre un Ă©cran transparent sur des lunettes, une visiĂšre ou plus tard directement nos lentilles de contact, nous permettant de continuer d’observer le rĂ©el “en direct”.

Aujourd’hui, les pĂ©riphĂ©riques AR directs sont assez spĂ©cifiques dans leur domaine comme le F-35 Helmet Mounted Display System ou DAQRI Smart Helmet

Pour le marchĂ© grand public, si on fait fi des Ă©crans transparents, les smartphones peuvent ĂȘtre une trĂšs bonne alternative et possĂšdent dĂ©jĂ  tout l’équipement nĂ©cessaire pour une expĂ©rience d’AR: un module GPS, des capteurs de mouvements (accĂ©lĂ©romĂštres,  gyromĂštres et magnĂ©tomĂštres) et une camĂ©ra.

La RĂ©alitĂ© Mixte – MR

Ce nouveau terme fut popularisé par Microsoft pour la sortie de périphérique Hololens afin de mettre en avant la cohabitation entre le réel et le virtuel. Il est admis que la réalité mixte englobe entres autres la réalité augmentée.

Ce n’est plus une simple superposition comme avec l’AR, le contenu que nous allons reprĂ©senter aura une cohĂ©rence visuelle avec l’environnement rĂ©el dans lequel il sera positionnĂ© (coordonnĂ©es spatiales).

Un objet virtuel peut donc se retrouver cachĂ© derriĂšre un objet physique rĂ©el (occlusion). Il y a souvent reconnaissance des surfaces simples comme les plans du sol, des murs, des tables qui vont servir Ă  mieux reconnaĂźtre oĂč nous sommes et pour rendre rĂ©aliste le positionnement d’objets virtuels par rapport aux objets rĂ©els prĂ©sents (spatial awareness).

Si notre objet est en 3 dimensions, nous pouvons alors le poser sur une table réelle et tourner autour de celui-ci afin observer toutes ces facettes sous différents angles.

Comme pour l’AR, il est prĂ©fĂ©rable qu’il y ait une altĂ©ration directe de notre environnement et non une restitution du rĂ©el sur un Ă©cran.

Pour les pĂ©riphĂ©riques, Microsoft possĂšde son propre casque totalement autonome : Hololens, nous avons dĂ©jĂ  parlĂ© de l’HoloLens ici.

De son cĂŽtĂ©, Google avec Tango prĂ©pare une plateforme pour la rĂ©alitĂ© mixte Ă  l’instar de Microsoft avec HoloLens et le systĂšme d’exploitation Windows Holographic.

 

Google s’associe avec Lenovo pour sortir le Phab 2 Pro qui est une phablette Ă©quipĂ©e d’Ă©metteur/rĂ©cepteur infrarouge. Vous pouvez retrouver plus d’informations sur Tango dans cet article.

 

La rĂ©cente annonce d’Apple concernant la sortie du kit de dĂ©veloppement ARKit sur iPhone vient confirmer cette tendance.

Les faux-amis

Certains projets de rĂ©alitĂ© augmentĂ©e peuvent ne pas ĂȘtre acceptĂ©s par les puristes, voici deux exemples de projets assez connus.

Google Glass

Il faut souligner que ce projet avait fait l’effort de se munir d’un Ă©cran transparent sur lequel Ă©tait projetĂ© des informations. Il y avait donc bien altĂ©ration du monde rĂ©el en direct mais celles-ci ne s’alignaient pas sur le rĂ©el. Notre environnement n’était pas reconnu.

Il faut plus les voir comme un petit Ă©cran qu’on porterait Ă  la hauteur de nos yeux. Cela s’apparente plus Ă  un affichage tĂȘte haute (Head Up Display), comme le font certains GPS qui affichent des informations sur le pare-brise du vĂ©hicule.

Pokémon Go

MĂȘme si nous avions presque pardonnĂ© au cĂ©lĂšbre jeu de cet Ă©tĂ© que cela soit sur un Ă©cran qui ne permet pas l’altĂ©ration directe. Encore une fois, c’est le non-alignement avec le rĂ©el qui ne le caractĂ©rise pas d’expĂ©rience AR.

La sociĂ©tĂ© Niantic qui a rĂ©alisĂ© l’application tente de nous le faire croire avec l’affichage du flux vidĂ©o de la camĂ©ra mais les PokĂ©mons ne sont pas diffĂ©remment affichĂ©s suivant ce que vous regardez. Les PokĂ©mons qui volent vont ĂȘtre placĂ© plutĂŽt vers le haut de votre Ă©cran et inversement pour ceux qui ne le sont pas. L’horizon ou le sol ne sont pas calculĂ©s avec le flux camĂ©ra mais avec l’accĂ©lĂ©romĂštre de votre tĂ©lĂ©phone.

 

Notre vision

La rĂ©alitĂ© virtuelle va ĂȘtre largement portĂ©e par le secteur du divertissement avec le jeu vidĂ©o c’est indĂ©niable. NĂ©anmoins certaines entreprises ont dĂ©jĂ  compris que cela pouvait-ĂȘtre un trĂšs bon vecteur de communication en faisant appel directement aux sens et Ă  l’immersion, l’utilisateur est plus sensibilisĂ© au message que l’on veut transmettre.

ScĂ©nario de sensibilisation aux risques ferroviaires SNCF – 76.000 Ă©lĂšves formĂ©s en 2016

La VR nous permet aussi de nous reprĂ©senter des objets non percevables Ă  l’oeil nu, immensĂ©ment grand ou encore des concepts abstraits.
Dans l’éducation, Brian GREEN, un professeur physicien Ă  l’universitĂ© Columbia, propose Ă  ses Ă©tudiants d’expliquer la thĂ©orie des cordes grĂące Ă  la VR.

Mais nous pensons que la VR est un outil parfait pour la formation avec la capacitĂ© d’apprendre par l’erreur dans un milieu virtuel sĂ©curisĂ©. Les secteurs de l’éducation, l’industrie et de la santĂ© seront les marchĂ©s principaux Ă  en tirer parti.

MĂȘme si Microsoft nous propose un trĂšs beau produit avec Hololens, porter un casque 8h par jour est une contrainte et va freiner l’adoption. En ciblant une utilisation sur de courtes durĂ©es, la AR/MR seront utilisĂ©s pour la visualisation, la formation, l’assistance temps rĂ©el et la tĂ©lĂ©prĂ©sence.

Nous pensons que la dĂ©mocratisation de la rĂ©alitĂ© augmentĂ©e se fera avec l’intĂ©gration dans les pĂ©riphĂ©riques du quotidien (tĂ©lĂ©phones, tablettes
) et la crĂ©ation de pĂ©riphĂ©riques lĂ©gers et spĂ©cialisĂ©s (en tant qu’outils de productivitĂ©).

 

Si le sujet vous intĂ©resse ou que vous avez un projet sur lequel vous voudriez notre Ă©clairage, contactez notre pĂŽle d’expertise “Virtual Immersion & Bot Experience” sur vibe [at]  octo . com

Articles suggested :

  1. Créons ensemble vos premiÚres expériences HoloLens
  2. Améliorer sa productivité avec les expériences immersives
  3. Meetup Réalité Virtuelle: Compte-rendu et analyses

Catégories: Blog Société

Réalité Virtuelle, Augmentée, Mixte: Faisons le point

jeu, 06/15/2017 - 10:03

Cet article a pour vocation de tenter d’éclaircir les nuances entre ces diffĂ©rentes expĂ©riences immersives, mais aussi de vous donner un bref aperçu des diffĂ©rents pĂ©riphĂ©riques existants actuellement sur le marchĂ©.

La RĂ©alitĂ© Virtuelle – VR

Application de formation sur les conduites de gaz des techniciens de GRTgaz

La rĂ©alitĂ© virtuelle est une simulation d’un environnement virtuel ou rĂ©aliste.

Son but est de crĂ©er une expĂ©rience sensorielle en faisant principalement appel Ă  la vue et l’ouĂŻe. Le toucher peut-ĂȘtre aussi simulĂ© avec le retour de force dans des contrĂŽleurs.

Les autres sens (odorat et goût) sont encore trop peu sollicités pour le moment car nécessitant un appareillage contraignant et souvent intrusif.

Le dispositif principal utilisĂ© pour la VR est un casque qu’on appelle aussi HMD (Head-mounted Display).

 

Les principaux acteurs sur le marché sont :

  • Google Cardboard et Daydream
  • HTC Vive
  • Oculus Rift
  • Samsung GearVR
  • Sony Playstation VR

 

 

Les casques dominent largement ce secteur mais ne sont pas les seuls dispositifs à faire de la réalité virtuelle.

Un peu moins grand public, les salles immersives sont aussi appelĂ©es CAVE (Cave Automatic Virtual Environment). L’utilisateur est dans une piĂšce oĂč l’on projette des images sur les diffĂ©rents murs qui l’entourent. La perspective du point de vue de l’utilisateur est calculĂ©e en temps rĂ©el Ă  l’aide d’un systĂšme de capture de position.

L’expĂ©rience peut ĂȘtre amĂ©liorĂ©e avec un son multicanal et des images projetĂ©es en 3D (rendu stĂ©rĂ©oscopique) mais dans ce dernier cas l’utilisateur devra s’équiper de lunettes 3D comme celles que l’on retrouve au cinĂ©ma ou sur les TV 3D.

 

PlutĂŽt utilisĂ© dans l’industrie, l’architecture, la conception et le design. L’avantage de ce type d’installation est l’immersion totale, il n’est pas nĂ©cessaire de reprĂ©senter notre corps.

Il faut prĂ©voir Ă  la fois un espace et un budget consĂ©quent de l’ordre de plusieurs centaines de milliers d’euros.

La réalité augmentée et la réalité mixte

Vous avez surement dĂ©jĂ  entendu parlĂ© de la rĂ©alitĂ© augmentĂ©e mais avez-vous dĂ©jĂ  entendu parler de rĂ©alitĂ© mixte ? Si oui, peut-ĂȘtre que la diffĂ©rence entre les deux n’est pas assez claire.

Les dĂ©finitions sur les technologies Ă©mergentes se crĂ©ent, parfois changent et s’affinent dans le temps.
La réalité mixte est venue préciser certaines attentes que nous avions de la réalité augmentée. Certains disent que la réalité mixte est simplement ce que nous attendions de la réalité augmentée.

La RĂ©alitĂ© AugmentĂ©e – AR

Le principe est d’afficher des images 2D/3D ou des informations en les superposant au monde rĂ©el sur un Ă©cran transparent. Ces informations sont donc au premier plan mais elles doivent prendre en compte l’environnement dans lequel nous sommes. ConnaĂźtre la position GPS ne suffit pas, il faut aussi reconnaĂźtre oĂč nous regardons, reconnaĂźtre par les formes ou par l’image, les objets qui constituent notre environnement. Il faut donc un alignement spatial avec la rĂ©alitĂ©.

Une expĂ©rience AR peut ĂȘtre une altĂ©ration comprendre ici une augmentation ou diminution directe ou indirecte du monde rĂ©el.

L’altĂ©ration indirecte ou par intermĂ©diation est prĂ©sente quand le rĂ©el est captĂ© par une camĂ©ra puis restituĂ© sur l’écran en l’augmentant avec du contenu. Nous voyons donc une reprĂ©sentation du rĂ©el au travers du pĂ©riphĂ©rique. Le cerveau distingue donc les deux environnements, celui rĂ©el qui l’entoure et celui augmentĂ© retransmis sur l’Ă©cran, il n’y a pas de confusion entre les deux.

Nos smartphones peuvent proposer des expĂ©riences AR, ils prĂ©sentent l’avantage de possĂ©der un certain nombre de capteurs utiles et d’ĂȘtre mobiles, trĂšs rĂ©pandus et peu encombrants. Malheureusement, ceux-ci ne peuvent pas encore proposer une altĂ©ration directe de notre environnement, seulement une altĂ©ration sur la restitution du rĂ©el.

Pour avoir une altĂ©ration directe, il faut donc voir “à travers” les pĂ©riphĂ©riques qui couvrent une partie significative de notre champ de vision. Cela peut-ĂȘtre un Ă©cran transparent sur des lunettes, une visiĂšre ou plus tard directement nos lentilles de contact, nous permettant de continuer d’observer le rĂ©el “en direct”.

Aujourd’hui, les pĂ©riphĂ©riques AR directs sont assez spĂ©cifiques dans leur domaine comme le F-35 Helmet Mounted Display System ou DAQRI Smart Helmet

Pour le marchĂ© grand public, si on fait fi des Ă©crans transparents, les smartphones peuvent ĂȘtre une trĂšs bonne alternative et possĂšdent dĂ©jĂ  tout l’équipement nĂ©cessaire pour une expĂ©rience d’AR: un module GPS, des capteurs de mouvements (accĂ©lĂ©romĂštres,  gyromĂštres et magnĂ©tomĂštres) et une camĂ©ra.

La RĂ©alitĂ© Mixte – MR

Ce nouveau terme fut popularisé par Microsoft pour la sortie de périphérique Hololens afin de mettre en avant la cohabitation entre le réel et le virtuel. Il est admis que la réalité mixte englobe entres autres la réalité augmentée.

Ce n’est plus une simple superposition comme avec l’AR, le contenu que nous allons reprĂ©senter aura une cohĂ©rence visuelle avec l’environnement rĂ©el dans lequel il sera positionnĂ© (coordonnĂ©es spatiales).

Un objet virtuel peut donc se retrouver cachĂ© derriĂšre un objet physique rĂ©el (occlusion). Il y a souvent reconnaissance des surfaces simples comme les plans du sol, des murs, des tables qui vont servir Ă  mieux reconnaĂźtre oĂč nous sommes et pour rendre rĂ©aliste le positionnement d’objets virtuels par rapport aux objets rĂ©els prĂ©sents (spatial awareness).

Si notre objet est en 3 dimensions, nous pouvons alors le poser sur une table réelle et tourner autour de celui-ci afin observer toutes ces facettes sous différents angles.

Comme pour l’AR, il est prĂ©fĂ©rable qu’il y ait une altĂ©ration directe de notre environnement et non une restitution du rĂ©el sur un Ă©cran.

Pour les pĂ©riphĂ©riques, Microsoft possĂšde son propre casque totalement autonome : Hololens, nous avons dĂ©jĂ  parlĂ© de l’HoloLens ici.

De son cĂŽtĂ©, Google avec Tango prĂ©pare une plateforme pour la rĂ©alitĂ© mixte Ă  l’instar de Microsoft avec HoloLens et le systĂšme d’exploitation Windows Holographic.

 

Google s’associe avec Lenovo pour sortir le Phab 2 Pro qui est une phablette Ă©quipĂ©e d’Ă©metteur/rĂ©cepteur infrarouge. Vous pouvez retrouver plus d’informations sur Tango dans cet article.

 

La rĂ©cente annonce d’Apple concernant la sortie du kit de dĂ©veloppement ARKit sur iPhone vient confirmer cette tendance.

Les faux-amis

Certains projets de rĂ©alitĂ© augmentĂ©e peuvent ne pas ĂȘtre acceptĂ©s par les puristes, voici deux exemples de projets assez connus.

Google Glass

Il faut souligner que ce projet avait fait l’effort de se munir d’un Ă©cran transparent sur lequel Ă©tait projetĂ© des informations. Il y avait donc bien altĂ©ration du monde rĂ©el en direct mais celles-ci ne s’alignaient pas sur le rĂ©el. Notre environnement n’était pas reconnu.

Il faut plus les voir comme un petit Ă©cran qu’on porterait Ă  la hauteur de nos yeux. Cela s’apparente plus Ă  un affichage tĂȘte haute (Head Up Display), comme le font certains GPS qui affichent des informations sur le pare-brise du vĂ©hicule.

Pokémon Go

MĂȘme si nous avions presque pardonnĂ© au cĂ©lĂšbre jeu de cet Ă©tĂ© que cela soit sur un Ă©cran qui ne permet pas l’altĂ©ration directe. Encore une fois, c’est le non-alignement avec le rĂ©el qui ne le caractĂ©rise pas d’expĂ©rience AR.

La sociĂ©tĂ© Niantic qui a rĂ©alisĂ© l’application tente de nous le faire croire avec l’affichage du flux vidĂ©o de la camĂ©ra mais les PokĂ©mons ne sont pas diffĂ©remment affichĂ©s suivant ce que vous regardez. Les PokĂ©mons qui volent vont ĂȘtre placĂ© plutĂŽt vers le haut de votre Ă©cran et inversement pour ceux qui ne le sont pas. L’horizon ou le sol ne sont pas calculĂ©s avec le flux camĂ©ra mais avec l’accĂ©lĂ©romĂštre de votre tĂ©lĂ©phone.

 

Notre vision

La rĂ©alitĂ© virtuelle va ĂȘtre largement portĂ©e par le secteur du divertissement avec le jeu vidĂ©o c’est indĂ©niable. NĂ©anmoins certaines entreprises ont dĂ©jĂ  compris que cela pouvait-ĂȘtre un trĂšs bon vecteur de communication en faisant appel directement aux sens et Ă  l’immersion, l’utilisateur est plus sensibilisĂ© au message que l’on veut transmettre.

ScĂ©nario de sensibilisation aux risques ferroviaires SNCF – 76.000 Ă©lĂšves formĂ©s en 2016

La VR nous permet aussi de nous reprĂ©senter des objets non percevables Ă  l’oeil nu, immensĂ©ment grand ou encore des concepts abstraits.
Dans l’éducation, Brian GREEN, un professeur physicien Ă  l’universitĂ© Columbia, propose Ă  ses Ă©tudiants d’expliquer la thĂ©orie des cordes grĂące Ă  la VR.

Mais nous pensons que la VR est un outil parfait pour la formation avec la capacitĂ© d’apprendre par l’erreur dans un milieu virtuel sĂ©curisĂ©. Les secteurs de l’éducation, l’industrie et de la santĂ© seront les marchĂ©s principaux Ă  en tirer parti.

MĂȘme si Microsoft nous propose un trĂšs beau produit avec Hololens, porter un casque 8h par jour est une contrainte et va freiner l’adoption. En ciblant une utilisation sur de courtes durĂ©es, la AR/MR seront utilisĂ©s pour la visualisation, la formation, l’assistance temps rĂ©el et la tĂ©lĂ©prĂ©sence.

Nous pensons que la dĂ©mocratisation de la rĂ©alitĂ© augmentĂ©e se fera avec l’intĂ©gration dans les pĂ©riphĂ©riques du quotidien (tĂ©lĂ©phones, tablettes
) et la crĂ©ation de pĂ©riphĂ©riques lĂ©gers et spĂ©cialisĂ©s (en tant qu’outils de productivitĂ©).

 

Si le sujet vous intĂ©resse ou que vous avez un projet sur lequel vous voudriez notre Ă©clairage, contactez notre pĂŽle d’expertise “Virtual Immersion & Bot Experience” sur vibe [at]  octo . com

Articles suggested :

  1. Créons ensemble vos premiÚres expériences HoloLens
  2. Améliorer sa productivité avec les expériences immersives
  3. Meetup Réalité Virtuelle: Compte-rendu et analyses

Catégories: Blog Société

Meetup PerfUG – Java at speed: getting the most out of modern hardware

mar, 06/13/2017 - 09:00

Getting the most of your Java applications can be an interesting challenge. Understanding some of the optimizations that the latest crop of JVMs are able to apply when running on the latest servers may help with that. Gil Tene, CTO and co-founder of Azul Systems, will discuss some of those features and optimizations.

Along with discussing some JIT compiler capabilities & issues around the black art of micro-benchmarking, we will take a look at the evolution of Intel-based server platforms, quickly traversing through features that were introduced across the past few years, from Nehalem [55xx], through Broadwell [E-26xx v4] and beyond. We’ll highlight the some of the coolest capabilities, discuss new sets of instructions (like AVX2, AVX512, BMI2, TSX, HLE), pipeline improvements, and core counts and topologies. We will then demonstrate some examples of JVM JITs using these capabilities where available, as they adapt the code they generate to the specific processor types they run on.

If you like to geek out to the sound of mechanical sympathy discussions, this is the talk for you. Registration and more information on Meetup. Food and drinks will be offered after the session by OCTO Technology.

Gil Tene @giltene is CTO and co-founder of Azul Systems. He has been involved with virtual machine and runtime technologies for the past 25 years. His pet focus areas include system responsiveness and latency behavior. Gil is a frequent speaker at technology conferences worldwide, and an official JavaOne Rock Star. He pioneered the Continuously Concurrent Compacting Collector (C4) that powers Azul’s continuously reactive Java platforms. In past lives, he also designed and built operating systems, network switches, firewalls, and laser based mosquito interception systems.

Le Performance User Group (ou PerfUG) est un meetup parisien qui a pour objectif d’offrir un lieu d’échanges informels oĂč toutes les personnes intĂ©ressĂ©es par l’optimisation et la performance sont les bienvenues quel que soit leur niveau. Nous sommes convaincus que la performance est une feature implicite et non nĂ©gociable d’une application et pourtant bien souvent oubliĂ©e. Le PerfUG souhaite faciliter la diffusion des derniers outils et des meilleures techniques pour maĂźtriser au plus tĂŽt la performance d’un systĂšme informatique.

imgres

Pour en apprendre davantage sur la Performance, retrouvez notre formation OCTO Academy : Performance des applications et du SI Ă  l’Ăšre du digital

Articles suggested :

  1. PerfUG : DynaTrace pour monitorer tous vos problĂšmes de performance
  2. Second anniversaire du PerfUG : Nginx et JVM Off-Heap (Architecture NUMA)
  3. PerfUG : High Performance Java

Catégories: Blog Société

Meetup PerfUG – Java at speed: getting the most out of modern hardware

mar, 06/13/2017 - 09:00

Getting the most of your Java applications can be an interesting challenge. Understanding some of the optimizations that the latest crop of JVMs are able to apply when running on the latest servers may help with that. Gil Tene, CTO and co-founder of Azul Systems, will discuss some of those features and optimizations.

Along with discussing some JIT compiler capabilities & issues around the black art of micro-benchmarking, we will take a look at the evolution of Intel-based server platforms, quickly traversing through features that were introduced across the past few years, from Nehalem [55xx], through Broadwell [E-26xx v4] and beyond. We’ll highlight the some of the coolest capabilities, discuss new sets of instructions (like AVX2, AVX512, BMI2, TSX, HLE), pipeline improvements, and core counts and topologies. We will then demonstrate some examples of JVM JITs using these capabilities where available, as they adapt the code they generate to the specific processor types they run on.

If you like to geek out to the sound of mechanical sympathy discussions, this is the talk for you. Registration and more information on Meetup. Food and drinks will be offered after the session by OCTO Technology.

Gil Tene @giltene is CTO and co-founder of Azul Systems. He has been involved with virtual machine and runtime technologies for the past 25 years. His pet focus areas include system responsiveness and latency behavior. Gil is a frequent speaker at technology conferences worldwide, and an official JavaOne Rock Star. He pioneered the Continuously Concurrent Compacting Collector (C4) that powers Azul’s continuously reactive Java platforms. In past lives, he also designed and built operating systems, network switches, firewalls, and laser based mosquito interception systems.

Le Performance User Group (ou PerfUG) est un meetup parisien qui a pour objectif d’offrir un lieu d’échanges informels oĂč toutes les personnes intĂ©ressĂ©es par l’optimisation et la performance sont les bienvenues quel que soit leur niveau. Nous sommes convaincus que la performance est une feature implicite et non nĂ©gociable d’une application et pourtant bien souvent oubliĂ©e. Le PerfUG souhaite faciliter la diffusion des derniers outils et des meilleures techniques pour maĂźtriser au plus tĂŽt la performance d’un systĂšme informatique.

imgres

Pour en apprendre davantage sur la Performance, retrouvez notre formation OCTO Academy : Performance des applications et du SI Ă  l’Ăšre du digital

Articles suggested :

  1. PerfUG : DynaTrace pour monitorer tous vos problĂšmes de performance
  2. Second anniversaire du PerfUG : Nginx et JVM Off-Heap (Architecture NUMA)
  3. PerfUG : High Performance Java

Catégories: Blog Société

La patrouille de France : une Ă©cole d’excellence pour booster le management en entreprise !

lun, 06/12/2017 - 11:33

Vous connaissez tous cette patrouille emblématique qui fait des prouesses dans le ciel et maintient sa performance à chacun de ses spectacles.

Mais saviez-vous que l’équipe de la patrouille de France (PAF) se renouvelle tous les ans et que le moindre Ă©cart peut ĂȘtre fatal Ă  l’équipe entiĂšre ?

J’ai rĂ©cemment participĂ© Ă  une confĂ©rence animĂ©e par Patrick Dutartre, GĂ©nĂ©ral d’aviation, pilote de chasse et ancien leader de la patrouille de France, ancien directeur de la communication puis conseiller auprĂšs du ministre des affaires Ă©trangĂšres. Il a Ă©tĂ© Ă©galement DG d’un groupe privĂ©.

Il nous a fait part de son expérience de leader de la patrouille de France et en quoi les techniques de management utilisées sont pertinentes et transposables aux leaders et managers en entreprise :

  • Comment amener des fortes personnalitĂ©s individuelles Ă  rejoindre l’équipe et atteindre des sommets ?
  • Comment mettre au service du collectif sa propre performance individuelle ?
  • Comment instaurer une discipline “intelligente” ?
  • Comment responsabiliser ses Ă©quipes au service de la performance ?
  • Comment conjuguer Ă  l’extrĂȘme professionnalisme et cohĂ©sion ?

Au cours de cette confĂ©rence, j’ai pu faire de nombreux parallĂšles entre la PAF et ce que nous vivons en entreprise : dans les mĂ©thodes de management, les relations humaines et aussi dans les principes des mĂ©thodes agiles !

A travers cet article, j’ai souhaitĂ© vous retranscrire les propos et les enseignements de Patrick Dutartre et commencer Ă  effectuer quelques parallĂšles avec le monde de l’entreprise.

1. Bien comprendre l’organisation de la PAF pour bien cerner les techniques de management appliquĂ©es

La PAF est composĂ©e de 8 pilotes d’exception :

  • 1 Leader
    • Il reste Ă  son poste sur une pĂ©riode d’un an
    • Il est le seul pilote indispensable dans la patrouille et ne peut ĂȘtre remplacĂ©
    • Chef d’orchestre de la patrouille, il dĂ©termine avec son Ă©quipe les figures et formations que la patrouille utilisera
  • 2 IntĂ©rieurs
    • Ils sont en premiĂšre annĂ©e Ă  la patrouille et Ă©voluent au plus prĂšs du leader lors des vols en formation
  • 2 ExtĂ©rieurs
    • Ils font partie des Ă©quipiers les plus Ă©loignĂ©s du leader
    • Leur place respective au sein de la formation leur demande beaucoup d’anticipation et de concentration pour bien tenir les formations
  • 1 Charognard
    • Il tire son surnom de sa position : placĂ© derriĂšre le leader, il en avale littĂ©ralement les fumĂ©es et prendra sa place l’annĂ©e suivante.
  • 1 Leader Solo et 1 Second Solo
    • Ils effectuent des croisements et des percussions lors de la “synchronisation”, seconde partie du programme

La Patrouille de France en formation Diamant, et les différents postes

Il y a Ă©galement un pilote remplaçant. C’est le pilote le plus ancien Ă  la PAF, puisqu’il a occupĂ© les postes d’intĂ©rieur, de second solo et de leader solo les annĂ©es prĂ©cĂ©dentes. Il doit ĂȘtre capable de remplacer n’importe quel Ă©quipier. Il ne peut cependant pas remplacer le leader.

Toutes les places sont fixes pendant 1 an. A l’issue de cette pĂ©riode :

  • Trois pilotes sont renouvelĂ©s
    • Charognard
    • IntĂ©rieur gauche
    • IntĂ©rieur droit
  • Un plan de rotation Ă©galement est mis en place
    • Le charognard remplace le leader (qui quitte la PAF)
    • L’intĂ©rieur droit remplace l’extĂ©rieur droit
    • L’intĂ©rieur gauche remplace le second solo
    • Le second solo devient leader solo
    • etc.

Le vol en patrouille serrée à 8 avions requiert une expertise avérée, les pilotes évoluant à des vitesses oscillant entre 300 et 800 km/h, à des distances comprises entre 3 et 4 mètres. Au cours de l’enchaînement des figures, ils subissent des accélérations variant de -3 à +7 G.

De ce fait, le renouvellement est soumis chaque année à la même procédure. Trois nouveaux pilotes de chasse doivent justifier d’un minimum de 1 500 heures de vol et de l’obtention de la qualification de chef de patrouille avant d’intégrer la PAF au poste de charognard, intérieurs gauche et droit.

2. Comment la PAF arrive-t-il Ă  maintenir son niveau d’excellence avec un tel turnover  ? L’étape cruciale : le  recrutement

Après une présélection administrative, les candidats se présentent à l’école de l’Air de Salon-de-Provence pour une journée de sélection au cours de laquelle il découvrent de l’intérieur l’unité, et où ils ont l’occasion de faire un vol en place arrière.

Cette journée est ponctuée par l’entretien de sélection devant l’équipe : c’est au cours de cet entretien que sont évaluées la motivation ainsi que les qualités humaines des candidats, qualités indispensables à la mission de représentation et garantes d’une cohésion de groupe essentielle à la réalisation de leur mission. À l’issue des entretiens de tous les candidats, ce sont les pilotes de l’équipe qui choisissent leurs trois futurs équipiers. Ce mode de recrutement repose sur les compétences techniques et les qualités humaines des pilotes, garantes d’une cohésion de groupe indispensable à la réalisation de leur mission.

DĂšs lors que les trois nouveaux pilotes sont retenus, ils effectuent leur premier vol. Chacun d’eux Ă©tant placĂ© sur le siĂšge derriĂšre l’un des pilotes avec l’ordre formel de ne toucher Ă  rien, sauf se maintenir fermement le siĂšge du pilote avec ses mains. A l’issue de ce premier vol, les rĂ©actions sont les suivantes :

  1. “Ces mecs sont complùtement fous !”
  2. “Est-ce que je vais y arriver ?”
  3. “C’était vraiment gĂ©nial, quand est-ce qu’on recommence ?”

Il est important de noter que les nouvelles recrues sont dĂ©jĂ  d’excellents pilotes, pour autant la peur de ne pas y arriver fait partie de leurs premiĂšres inquiĂ©tudes ! C’est un sentiment que nous expĂ©rimentons tous dans notre vie professionnelle de tous les jours quand on change de poste, qu’on dĂ©marre un nouveau projet, qu’on remplace une personne sur un poste


Le rÎle clé du Leader

Le Leader a la responsabilité de la PAF et a un impact trÚs fort dans la réussite de son équipe. Il doit :

  1. dire ce qu’il va faire (principe de transparence)
  2. s’assurer qu’il est complĂštement compris par son Ă©quipe
  3. faire ce qu’il dit (principe d’exemplaritĂ©)
  4. ne pas changer d’avis toutes les cinq minutes
  5. ĂȘtre prĂ©dictible par son Ă©quipe
    • Plus un leader est prĂ©dictible, plus ses collaborateurs ont confiance en lui et se rapprochent de lui
    • L’inverse est Ă©galement vrai : moins un leader est prĂ©dictible, moins ses collaborateurs ont confiance en lui et plus ils s’éloignent de lui

Vous le comprenez aisĂ©ment que la PAF a dĂ» mettre en place un vĂ©ritable processus d’excellence Ă©prouvĂ© (issue des retours d’expĂ©rience des pilotes des annĂ©es prĂ©cĂ©dentes) pour embarquer les nouveaux, faire reculer leurs limites (sans mettre en danger leurs partenaires), crĂ©er une cohĂ©sion d’équipe et amĂ©liorer les performances du Groupe.

Pour faire reculer les limites des pilotes, trois facteurs :

  1. L’envie (ou la survie)
  2. La volonté
  3. Le travail (avec de l’entraĂźnement et de la mĂ©thode)

DĂšs lors, le management de l’équipe est fondamental pour piloter les limites de chacun tout comme la capacitĂ© Ă  oublier sa performance individuelle au profit de la performance collective (une rĂšgle d’or au sein de la PAF). Si vous prĂȘtez attention Ă  cela, vous remarquerez que ce principe est Ă©galement trĂšs important en entreprise au niveau du management et Ă©galement dans vos projets en agile !

La PAF s’appuie sur 12 paramĂštres clĂ©s pour rĂ©ussir (regroupĂ©s par catĂ©gorie) :

 

CONSTITUTION DES ÉQUIPES

1. Recrutement

2. Intégration

3. Place et rĂŽle de chacun

4. Formation

 

PROCESSUS DE TRAVAIL

5. Préparation

6. Briefing

7. Visualisation

8. DĂ©briefing

9. Transmission du savoir-faire

 

MANAGEMENT PUR

10. CohĂ©sion d’équipe

11. Motivation

12. Leadership

 

L’empathie et l’écoute sont des qualitĂ©s intrinsĂšques fondamentales et prĂ©sentes chez chaque pilote de la PAF. Ces Ă©lĂ©ments sont Ă©galement trĂšs puissants en entreprise, surtout pour ceux qui ont la responsabilitĂ© d’un ou plusieurs collaborateurs.

Au sein de la PAF, il est nĂ©cessaire d’ĂȘtre performant sur ces 12 paramĂštres. La rĂ©ciproque en entreprise est Ă©galement la mĂȘme si on souhaite amĂ©liorer la performance collective globale.

Vous trouverez ci-dessous quelques Ă©lĂ©ments de rĂ©flexion issus des retours d’expĂ©rience de Patrick Dutartre au sein de la PAF.

3. Les éléments clés à retenir des 12 paramÚtres de management de PAF Constitution des équipes (#1)  : Recrutement
    • Ne jamais recruter tout seul
    • Quand il y a un doute, il n’y a plus de doute ! (Google a appliquĂ© cette doctrine depuis sa crĂ©ation)
    • Ne jamais recruter par dĂ©faut
    • Recruter en s’appuyant sur 3 piliers :
      • Le savoir (en tant que savoir-conceptualiser)
      • Le savoir-faire
      • Le savoir-ĂȘtre : aujourd’hui c’est le pilier quasiment le plus important car le savoir et le savoir-faire peuvent s’acquĂ©rir (formation, expĂ©riences terrain
) alors que le savoir-ĂȘtre est intimement liĂ© Ă  votre personnalitĂ© (mĂȘme si celle-ci peut Ă©voluer)
    • Evaluer l’adĂ©quation du futur collaborateur Ă  la culture de votre entreprise (la pĂ©riode d’essai est gĂ©nĂ©ralement le meilleur moyen pour le faire)
      • Vision
      • Valeurs (qui doivent ĂȘtre incarnĂ©es, pas juste Ă©noncĂ©es)
      • FinalitĂ©s
        • Ex. Entreprise Bon Grains : gagner de l’argent, assurer le bien-ĂȘtre des clients et des collaborateurs
      • Principes d’action
        • Ex. Entreprise Bon Grains : le principe de subsidiaritĂ© (on en fait jamais au niveau N ce qui peut ĂȘtre fait au niveau N-1)
    • MĂ©thodes de travail
    • ADN de l’entreprise

Il ne peut y avoir de performance durable sans un alignement des notions fondamentales de la culture d’entreprise.

Constitution des équipes (#2) : Intégration

L’intĂ©gration est fondamentale Ă  la PAF pour comprendre le fonctionnement de l’équipe, connaĂźtre les procĂ©dures, monter en compĂ©tences, etc.

En fin de compte, cette approche est trĂšs similaire Ă  celle appliquĂ©e en entreprise. NĂ©anmoins il est important de noter que moins on s’occupe du nouvel arrivant, moins il restera dans l’entreprise. Inversement, plusieurs Ă©tudes ont Ă©tabli un lien entre performance et qualitĂ© de l’intĂ©gration : les plus performants sont ceux qui ont Ă©tĂ© le mieux intĂ©grĂ©s.

Pour aller plus loin, d’aprĂšs l’étude EDHEC “Les clĂ©s de succĂšs de l’intĂ©gration des jeunes talents” (Janvier 2015) :

 

  • Les principales raisons de satisfaction et d’insatisfaction lors de l’intĂ©gration dans l’entreprise

 

  • Les actions les plus apprĂ©ciĂ©es et celles les plus attendues lors de l’intĂ©gration

 

  • Les 3 conseils des jeunes diplĂŽmĂ©s aux entreprises afin de rĂ©ussir l’intĂ©gration

 

Ainsi, Patrick Dutartre recommande pour chaque nouvel arrivant de proposer :

  • Un kit d’intĂ©gration
  • Une journĂ©e d’intĂ©gration
  • Un parcours d’intĂ©gration individualisĂ© (incluant de la formation)
    • Ex. Michelin : sur 3 mois
    • Ex. L’OrĂ©al : sur 3 mois
    • Ex. Leclerc : sur 11 mois (pour les cadres)
  • Des mises en situation pour tester et valider les acquis
Constitution des équipes (#3)  : Place et rÎle de chacun

Au sein de la PAF,  vous avez pu remarquer qu’il y avait des rĂŽles spĂ©cifiques. Chaque pilote a une mission et doit Ɠuvrer pour le bien commun et la performance de l’équipe, le tout devant ĂȘtre rĂ©alisĂ© dans un cadre Ă©tabli Ă  l’avance (mĂ©thodes, compĂ©tences nĂ©cessaires, planning
).

L’objectif est d’obtenir le meilleur de chacun et libĂ©rer les Ă©nergies individuelles au profit d’une performance et de l’intelligence collectives.

Ces principes se retrouvent dans les projets agiles, notamment sur la mise en place d’équipes pluridisciplinaires, autonomes et responsables. Chaque membre de cette Ă©quipe a un rĂŽle bien dĂ©fini (Delivery Manager, Product Owner, Tech Lead, DĂ©veloppeurs, OPS
) avec une ou plusieurs expertises dĂ©diĂ©es, et partagent la mĂȘme vision du produit.

Constitution des équipes (#4)  : Formation

La formation est un des piliers de la PAF. Cependant, Ă  la diffĂ©rence des entreprises, les compĂ©tences sont sans cesse Ă©valuĂ©es et testĂ©es pour s’assurer que

  • chaque pilote ne met pas en danger la patrouille
  • chaque pilote monte en puissance progressivement, et au mĂȘme rythme que l’équipe globale

En entreprise, le fait que les compĂ©tences soient testĂ©es permet de s’assurer que chaque personne dispose d’un background technique et mĂ©thodologique lui permettant d’assurer ses fonctions dans les meilleures conditions : vous n’iriez pas confier les clefs de votre Ferrari Ă  une personne qui n’a pas son permis de conduire !

Processus de travail (#5) : Préparation

Bien que cela paraisse Ă©vident pour tout le monde, la prĂ©paration est un prĂ©requis non nĂ©gociable au sein de la PAF.  Pour autant en entreprise, ce n’est pas toujours le cas y compris pour les tĂąches qui peuvent nous paraĂźtre banales.

Processus de travail (#6) : Briefing (pour l’information descendante)

Le briefing (diffĂ©rent des rĂ©unions de travail) a pour objectif l’efficacitĂ© opĂ©rationnel de la PAF. En entreprise c’est la mĂȘme chose, il vise l’efficacitĂ© opĂ©rationnel du business.

Chaque briefing est propre à chaque entreprise sur le fond et sur la forme. Selon Patrick Dutartre, la forme d’un briefing repose sur 10 paramùtres :

  1. Quelle fréquence
  2. Quel jour
  3. Quelle heure
  4. Quelle durée
  5. Quel endroit
  6. Avec qui
  7. Debout ou Assis
  8. Avec ou sans café
  9. Préparé ou non préparé
  10. Avec ou sans compte-rendu
Processus de travail (#7) : Visualisation

Avant d’enfiler leur combinaison anti-G et leur casque, les pilotes de la PAF effectuent le mĂȘme rituel, ils font “la musique”. Une chorĂ©graphie manuelle (appelĂ© visualisation mentale proactive, Ă  la diffĂ©rence d’une visualisation subie) aussi surprenante que nĂ©cessaire. Les pilotes “mentalisent” leur vol, ils rĂ©pĂštent chacun des gestes qu’ils vont devoir effectuer Ă  bord de leur Alphajet.

Et si chaque pilote fait la musique à sa maniùre, il n’y a pas en effet de bons ou de mauvais gestes, reste que chacun a sa signification.

Dans cette phase de concentration, les huit pilotes ne font plus qu’un. Ils communient ensemble, attentifs au moindre mot lĂąchĂ© par le leader de la patrouille ou par l’un de leurs Ă©quipiers. Les ordres sont prĂ©cis, directs, courts, car Ă  1 000 km/h dans le ciel et Ă  quelques mĂštres seulement les uns des autres, il n’y a pas de place pour l’approximation.

“Faire la musique” est donc une chorĂ©graphie verbale, manuelle, un prĂ©lude avant qu’elle ne devienne aĂ©rienne.

Voici une vidĂ©o d’un extrait de briefing  de la PAF avant sa dĂ©monstration au salon AĂ©rotop (Poitier, 29 septembre 2012) durant laquelle vous pouvez observer une sĂ©ance de visualisation mentale : https://www.youtube.com/watch?v=WO5G_JM2Kws

La visualisation est vitale pour un pilote de la PAF est une source de préparation fabuleuse.

Ce principe est mis en Ɠuvre chez les sportifs de haut niveau dans leur prĂ©paration aux compĂ©titions. Des procĂ©dĂ©s similaires se retrouvent Ă©galement dans le monde du spectacle, avec les “filages” ou les rĂ©pĂ©titions “à l’italienne” avant une reprĂ©sentation. Pour autant, il est peu dĂ©ployĂ© en entreprise qui a encore du mal Ă  en voir l’utilitĂ© alors que les champs d’actions sont multiples (prĂ©paration d’un atelier de facilitation, prĂ©paration d’une rencontre Ă  fort enjeux, simulation du comportement d’autrui pour Ă©tudier ses propres rĂ©actions et anticiper ce que nous allons dire
).

Processus de travail (#8) : DĂ©briefing (pour l’information ascendante)

Il existe trois types de débriefings :

  1. Quand il y a un problĂšme
    • Un premier dĂ©briefing Ă  chaud (tout de suite aprĂšs l’apparition du problĂšme, avec toutes les parties prenantes) pour
      • reconstituer les faits et rien que les faits
      • aligner tout le monde sur une seule vĂ©ritĂ© et rĂ©alitĂ© communes, partagĂ©es par tous
        • il ne doit y avoir aucun jugement (Ex. Software Craftsmanship : “Dur avec le code, doux avec les Hommes”)
    • Suivi d’un deuxiĂšme dĂ©briefing Ă  froid (gĂ©nĂ©ralement une semaine Ă  un mois plus tard)  pour
      • dĂ©finir qu’est-ce qu’on peut faire pour que ça ne se reproduise plus
      • apprendre  individuellement et collectivement de nos erreurs (valeur trĂšs importante en Agile)
  2. Quand il y a un succĂšs
    • Objectif : comprendre les raisons de ce succĂšs pour pouvoir ensuite les reproduire
  3. Quand tout se passe bien (pour “contrer” la loi de Murphy)
    • Il arrive parfois que nous rĂ©ussissions une action alors que quelque chose n’a pas fonctionnĂ© dans votre process (mais qui n’était pas suffisamment critique pour tout arrĂȘter). De ce fait, ce genre de dĂ©briefing permet de dĂ©tecter de petites erreurs anodines qui auraient pu s’avĂ©rer problĂ©matique Ă  l’avenir.
      • Ex. Vous pouvez vous rendre d’un point A Ă  un point B en voiture avec les clignotants qui ne fonctionnent pas. Bien que vous ayez atteint votre destination en toute sĂ©curitĂ©, vous avez potentiellement mis en danger d’autres conducteurs sur votre route. Vous prenez donc l’action de faire rĂ©parer vos clignotants.
Processus de travail (#9) : Transmission du savoir-faire

Au sein de la PAF, l’historique, le retour d’expĂ©rience des opĂ©rations passĂ©es, les anciens, le suivi des dĂ©briefings
 sont des facteurs de progrĂšs et de performance.

Elle s’appuie sur plusieurs Ă©lĂ©ments pour former ses pilotes :

  • Des checklists pour tout ce qui est rĂ©pĂ©titif et qui a fait ses preuves
  • Des “Standard Operating Procedures” pour tout ce qui est connu
  • Des formations individuelles et collectives dĂ©diĂ©es
    • Rigueur dans l’exĂ©cution
    • MĂ©thodologie pour apprĂ©hender le nouveau
    • DisponibilitĂ© pour apprendre et se remettre en cause

Elle considĂšre qu’à partir du moment oĂč un pilote est formĂ©, il devient automatiquement formateur.

Chez OCTO, l’utilisation de checklists fait partie de notre ADN.

Management pur (#10) : CohĂ©sion d’équipe

La cohĂ©sion d’équipe au sein de la PAF se fait Ă  plusieurs niveaux :

  • AdhĂ©sion Ă  un objectif commun
  • Une vision et des valeurs partagĂ©es
  • Une fiertĂ© due au sens
  • L’exemplaritĂ© (de toute les parties prenantes : des mĂ©caniciens au top management en passant par les pilotes eux-mĂȘmes)
  • Le respect
  • La communication
  • La clartĂ©
  • Des rĂšgles du jeu claires et comprises par tous
  • La place et le rĂŽle de chacun
  • etc.

Il a Ă©galement Ă©tĂ© observĂ© que l’humeur du leader a une influence directe sur l’humeur de son Ă©quipe (rĂ©action purement humaine de mimĂ©tisme et d’exemplaritĂ©).

Autre Ă©lĂ©ment important au sein de la PAF et qui devraient ĂȘtre mis en place dans les entreprises ayant une prĂ©sence mondiale : la dĂ©finition d’un langage minimal commun (dĂ©fini et Ă©crit). Par exemple, dans l’aviation, pour tous les pays et toutes les nationalitĂ©s, on utilise le langage commun :

  • “Clear to land” : autorisation d’atterrissage
  • “Clear for takeoff” : autorisation de dĂ©collage

Ce langage commun doit ĂȘtre Ă©crit, partagĂ© et compris de tous.

Management pur (#11) : Motivation

Pour la PAF, la motivation résulte (entre autres) sur :

  • La crĂ©ation des bonnes conditions
    • La fiertĂ© due Ă  la performance
    • La visualisation de son apport
    • Le sentiment d’appartenance, bien sĂ»r renforcĂ© par la difficultĂ© de la sĂ©lection – ĂȘtre pilote est, comme pour les mĂ©decins, une vocation -, des conditions de la vie militaire et des entraĂźnement. “Souffrir ensemble” comme mĂ©canisme de cohĂ©sion.
    • etc.
  • Le dĂ©veloppement du bien-ĂȘtre
    • La responsabilisation et l’autonomie
    • La reconnaissance
    • Les conditions de travail
    • etc.

Nous retrouvons ces principes de motivation dans de nombreux ouvrages (dont celui de Daniel Pink “La vĂ©ritĂ© sur ce qui nous motive”) et Ă©galement dans les mĂ©thodes agiles.

Par ailleurs, il est prouvĂ© que la reconnaissance est l’une des meilleures mĂ©thodes pour amĂ©liorer la motivation au travail et l’engagement des employĂ©s : fĂ©licitez donc vos collaborateurs !

The Bottom Line Impact of Recognition

Le droit Ă  l’erreur (dans une moindre mesure bien entendu) joue Ă©galement un rĂŽle important dans la motivation Ă  partir du moment oĂč vous apprenez de vos erreurs et que vous ne persistez pas dedans.

AprĂšs avoir percutĂ© la cible volante sur laquelle il Ă©tait censĂ© tirer, puis atterrit en Ă©vitant le crash de son avion abĂźmĂ©, un pilote raconte que son instructeur l’avait amenĂ© de force, les jambes encore flageolantes, au bar du Mess, lui avait fait boire un verre de vin rouge et l’avait renvoyĂ© directement en vol, pour ne pas que la peur “infuse”.

Management pur (#12) : Leadership

Ce thĂšme est bien Ă©videmment trĂšs vaste et ne saurait, lui non plus, ĂȘtre couvert en quelques mots. Patrick Dutartre, dans son humble expĂ©rience, prĂ©conisait Ă  minima de rester soi-mĂȘme et d’ĂȘtre conscient de ses forces et de ses faiblesses (il est donc nĂ©cessaire de savoir s’entourer des bonnes personnes pour se complĂ©ter).

“La grandeur d’un mĂ©tier est peut-ĂȘtre avant tout d’unir les hommes, mais il y a un luxe vĂ©ritable et c’est celui des relations humaines.” – Saint ExupĂ©ry (Terre des hommes).

Sur le terrain, le leadership militaire est affaire d’exemplaritĂ©. Comme pour la PAF, le squad leader est toujours devant et montre l’exemple Ă  ses hommes (ceci reste tout aussi vrai en entreprise !).

La performance de l’équipe est donc la somme du meilleur de chacun.

4. Conclusion

Cette confĂ©rence m’a apportĂ© un regard diffĂ©rent sur le monde militaire que je voyais comme un milieu “processisĂ©â€ au maximum sans se soucier du bien-ĂȘtre des soldats, dans lequel la prise d’initiative est trĂšs faible
 et surtout des rĂšgles et mĂ©thodes qui ne pourraient pas fonctionner dans les entreprises libĂ©rĂ©es. Je suppose qu’on a tous Ă©tĂ© marquĂ©s par le film de Stanley Kubrick“Full Metal Jacket” et bien d’autres d’ailleurs :-)

Cet article avait pour vocation de vous prĂ©senter la partie la petite partie Ă©mergĂ©e de l’iceberg de la PAF. J’ai pu dĂ©couvrir qu’il y avait Ă©normĂ©ment de similitudes entre les Ă©lĂ©ments prĂ©sentĂ©s ci-dessus et ce que nous conseillons Ă  nos clients sur les mĂ©thodes Agiles (droit Ă  l’erreur, amĂ©lioration continue, capacitĂ© d’adaptation, rigueur dans l’exĂ©cution, vision claire et partagĂ©e
). Je pense Ă©galement ces principes peuvent nous aider Ă  amĂ©liorer nos mĂ©thodes de management et nos relations inter-personnelles.  

Rien qu’à mon niveau, je tĂącherai d’ĂȘtre plus disciplinĂ© de prendre plus de temps sur les “dĂ©briefings” pour identifier de nouvelles pistes de progrĂšs (Ă  la fin des avant-vente, projets
).

J’espĂšre que cet article aura suscitĂ© chez vous la mĂȘme envie que moi d’approfondir certains aspects. Peut-ĂȘtre d’autres articles Ă  venir sur des retours d’expĂ©rience personnels de mise en Ɠuvre et des similaritĂ©s entre le mĂ©tier de la PAF et celui d’OCTO ? :-)

Articles suggested :

  1. Management 3.0 : premiÚres réponses aux questions des petits-déjeuners
  2. Les grands groupes devraient-ils s’inspirer des startups ?

Catégories: Blog Société

La patrouille de France : une Ă©cole d’excellence pour booster le management en entreprise !

lun, 06/12/2017 - 11:33

Vous connaissez tous cette patrouille emblématique qui fait des prouesses dans le ciel et maintient sa performance à chacun de ses spectacles.

Mais saviez-vous que l’équipe de la patrouille de France (PAF) se renouvelle tous les ans et que le moindre Ă©cart peut ĂȘtre fatal Ă  l’équipe entiĂšre ?

J’ai rĂ©cemment participĂ© Ă  une confĂ©rence animĂ©e par Patrick Dutartre, GĂ©nĂ©ral d’aviation, pilote de chasse et ancien leader de la patrouille de France, ancien directeur de la communication puis conseiller auprĂšs du ministre des affaires Ă©trangĂšres. Il a Ă©tĂ© Ă©galement DG d’un groupe privĂ©.

Il nous a fait part de son expérience de leader de la patrouille de France et en quoi les techniques de management utilisées sont pertinentes et transposables aux leaders et managers en entreprise :

  • Comment amener des fortes personnalitĂ©s individuelles Ă  rejoindre l’équipe et atteindre des sommets ?
  • Comment mettre au service du collectif sa propre performance individuelle ?
  • Comment instaurer une discipline “intelligente” ?
  • Comment responsabiliser ses Ă©quipes au service de la performance ?
  • Comment conjuguer Ă  l’extrĂȘme professionnalisme et cohĂ©sion ?

Au cours de cette confĂ©rence, j’ai pu faire de nombreux parallĂšles entre la PAF et ce que nous vivons en entreprise : dans les mĂ©thodes de management, les relations humaines et aussi dans les principes des mĂ©thodes agiles !

A travers cet article, j’ai souhaitĂ© vous retranscrire les propos et les enseignements de Patrick Dutartre et commencer Ă  effectuer quelques parallĂšles avec le monde de l’entreprise.

1. Bien comprendre l’organisation de la PAF pour bien cerner les techniques de management appliquĂ©es

La PAF est composĂ©e de 8 pilotes d’exception :

  • 1 Leader
    • Il reste Ă  son poste sur une pĂ©riode d’un an
    • Il est le seul pilote indispensable dans la patrouille et ne peut ĂȘtre remplacĂ©
    • Chef d’orchestre de la patrouille, il dĂ©termine avec son Ă©quipe les figures et formations que la patrouille utilisera
  • 2 IntĂ©rieurs
    • Ils sont en premiĂšre annĂ©e Ă  la patrouille et Ă©voluent au plus prĂšs du leader lors des vols en formation
  • 2 ExtĂ©rieurs
    • Ils font partie des Ă©quipiers les plus Ă©loignĂ©s du leader
    • Leur place respective au sein de la formation leur demande beaucoup d’anticipation et de concentration pour bien tenir les formations
  • 1 Charognard
    • Il tire son surnom de sa position : placĂ© derriĂšre le leader, il en avale littĂ©ralement les fumĂ©es et prendra sa place l’annĂ©e suivante.
  • 1 Leader Solo et 1 Second Solo
    • Ils effectuent des croisements et des percussions lors de la “synchronisation”, seconde partie du programme

La Patrouille de France en formation Diamant, et les différents postes

Il y a Ă©galement un pilote remplaçant. C’est le pilote le plus ancien Ă  la PAF, puisqu’il a occupĂ© les postes d’intĂ©rieur, de second solo et de leader solo les annĂ©es prĂ©cĂ©dentes. Il doit ĂȘtre capable de remplacer n’importe quel Ă©quipier. Il ne peut cependant pas remplacer le leader.

Toutes les places sont fixes pendant 1 an. A l’issue de cette pĂ©riode :

  • Trois pilotes sont renouvelĂ©s
    • Charognard
    • IntĂ©rieur gauche
    • IntĂ©rieur droit
  • Un plan de rotation Ă©galement est mis en place
    • Le charognard remplace le leader (qui quitte la PAF)
    • L’intĂ©rieur droit remplace l’extĂ©rieur droit
    • L’intĂ©rieur gauche remplace le second solo
    • Le second solo devient leader solo
    • etc.

Le vol en patrouille serrée à 8 avions requiert une expertise avérée, les pilotes évoluant à des vitesses oscillant entre 300 et 800 km/h, à des distances comprises entre 3 et 4 mètres. Au cours de l’enchaînement des figures, ils subissent des accélérations variant de -3 à +7 G.

De ce fait, le renouvellement est soumis chaque année à la même procédure. Trois nouveaux pilotes de chasse doivent justifier d’un minimum de 1 500 heures de vol et de l’obtention de la qualification de chef de patrouille avant d’intégrer la PAF au poste de charognard, intérieurs gauche et droit.

2. Comment la PAF arrive-t-il Ă  maintenir son niveau d’excellence avec un tel turnover  ? L’étape cruciale : le  recrutement

Après une présélection administrative, les candidats se présentent à l’école de l’Air de Salon-de-Provence pour une journée de sélection au cours de laquelle il découvrent de l’intérieur l’unité, et où ils ont l’occasion de faire un vol en place arrière.

Cette journée est ponctuée par l’entretien de sélection devant l’équipe : c’est au cours de cet entretien que sont évaluées la motivation ainsi que les qualités humaines des candidats, qualités indispensables à la mission de représentation et garantes d’une cohésion de groupe essentielle à la réalisation de leur mission. À l’issue des entretiens de tous les candidats, ce sont les pilotes de l’équipe qui choisissent leurs trois futurs équipiers. Ce mode de recrutement repose sur les compétences techniques et les qualités humaines des pilotes, garantes d’une cohésion de groupe indispensable à la réalisation de leur mission.

DĂšs lors que les trois nouveaux pilotes sont retenus, ils effectuent leur premier vol. Chacun d’eux Ă©tant placĂ© sur le siĂšge derriĂšre l’un des pilotes avec l’ordre formel de ne toucher Ă  rien, sauf se maintenir fermement le siĂšge du pilote avec ses mains. A l’issue de ce premier vol, les rĂ©actions sont les suivantes :

  1. “Ces mecs sont complùtement fous !”
  2. “Est-ce que je vais y arriver ?”
  3. “C’était vraiment gĂ©nial, quand est-ce qu’on recommence ?”

Il est important de noter que les nouvelles recrues sont dĂ©jĂ  d’excellents pilotes, pour autant la peur de ne pas y arriver fait partie de leurs premiĂšres inquiĂ©tudes ! C’est un sentiment que nous expĂ©rimentons tous dans notre vie professionnelle de tous les jours quand on change de poste, qu’on dĂ©marre un nouveau projet, qu’on remplace une personne sur un poste


Le rÎle clé du Leader

Le Leader a la responsabilité de la PAF et a un impact trÚs fort dans la réussite de son équipe. Il doit :

  1. dire ce qu’il va faire (principe de transparence)
  2. s’assurer qu’il est complĂštement compris par son Ă©quipe
  3. faire ce qu’il dit (principe d’exemplaritĂ©)
  4. ne pas changer d’avis toutes les cinq minutes
  5. ĂȘtre prĂ©dictible par son Ă©quipe
    • Plus un leader est prĂ©dictible, plus ses collaborateurs ont confiance en lui et se rapprochent de lui
    • L’inverse est Ă©galement vrai : moins un leader est prĂ©dictible, moins ses collaborateurs ont confiance en lui et plus ils s’éloignent de lui

Vous le comprenez aisĂ©ment que la PAF a dĂ» mettre en place un vĂ©ritable processus d’excellence Ă©prouvĂ© (issue des retours d’expĂ©rience des pilotes des annĂ©es prĂ©cĂ©dentes) pour embarquer les nouveaux, faire reculer leurs limites (sans mettre en danger leurs partenaires), crĂ©er une cohĂ©sion d’équipe et amĂ©liorer les performances du Groupe.

Pour faire reculer les limites des pilotes, trois facteurs :

  1. L’envie (ou la survie)
  2. La volonté
  3. Le travail (avec de l’entraĂźnement et de la mĂ©thode)

DĂšs lors, le management de l’équipe est fondamental pour piloter les limites de chacun tout comme la capacitĂ© Ă  oublier sa performance individuelle au profit de la performance collective (une rĂšgle d’or au sein de la PAF). Si vous prĂȘtez attention Ă  cela, vous remarquerez que ce principe est Ă©galement trĂšs important en entreprise au niveau du management et Ă©galement dans vos projets en agile !

La PAF s’appuie sur 12 paramĂštres clĂ©s pour rĂ©ussir (regroupĂ©s par catĂ©gorie) :

 

CONSTITUTION DES ÉQUIPES

1. Recrutement

2. Intégration

3. Place et rĂŽle de chacun

4. Formation

 

PROCESSUS DE TRAVAIL

5. Préparation

6. Briefing

7. Visualisation

8. DĂ©briefing

9. Transmission du savoir-faire

 

MANAGEMENT PUR

10. CohĂ©sion d’équipe

11. Motivation

12. Leadership

 

L’empathie et l’écoute sont des qualitĂ©s intrinsĂšques fondamentales et prĂ©sentes chez chaque pilote de la PAF. Ces Ă©lĂ©ments sont Ă©galement trĂšs puissants en entreprise, surtout pour ceux qui ont la responsabilitĂ© d’un ou plusieurs collaborateurs.

Au sein de la PAF, il est nĂ©cessaire d’ĂȘtre performant sur ces 12 paramĂštres. La rĂ©ciproque en entreprise est Ă©galement la mĂȘme si on souhaite amĂ©liorer la performance collective globale.

Vous trouverez ci-dessous quelques Ă©lĂ©ments de rĂ©flexion issus des retours d’expĂ©rience de Patrick Dutartre au sein de la PAF.

3. Les éléments clés à retenir des 12 paramÚtres de management de PAF Constitution des équipes (#1)  : Recrutement
    • Ne jamais recruter tout seul
    • Quand il y a un doute, il n’y a plus de doute ! (Google a appliquĂ© cette doctrine depuis sa crĂ©ation)
    • Ne jamais recruter par dĂ©faut
    • Recruter en s’appuyant sur 3 piliers :
      • Le savoir (en tant que savoir-conceptualiser)
      • Le savoir-faire
      • Le savoir-ĂȘtre : aujourd’hui c’est le pilier quasiment le plus important car le savoir et le savoir-faire peuvent s’acquĂ©rir (formation, expĂ©riences terrain
) alors que le savoir-ĂȘtre est intimement liĂ© Ă  votre personnalitĂ© (mĂȘme si celle-ci peut Ă©voluer)
    • Evaluer l’adĂ©quation du futur collaborateur Ă  la culture de votre entreprise (la pĂ©riode d’essai est gĂ©nĂ©ralement le meilleur moyen pour le faire)
      • Vision
      • Valeurs (qui doivent ĂȘtre incarnĂ©es, pas juste Ă©noncĂ©es)
      • FinalitĂ©s
        • Ex. Entreprise Bon Grains : gagner de l’argent, assurer le bien-ĂȘtre des clients et des collaborateurs
      • Principes d’action
        • Ex. Entreprise Bon Grains : le principe de subsidiaritĂ© (on en fait jamais au niveau N ce qui peut ĂȘtre fait au niveau N-1)
    • MĂ©thodes de travail
    • ADN de l’entreprise

Il ne peut y avoir de performance durable sans un alignement des notions fondamentales de la culture d’entreprise.

Constitution des équipes (#2) : Intégration

L’intĂ©gration est fondamentale Ă  la PAF pour comprendre le fonctionnement de l’équipe, connaĂźtre les procĂ©dures, monter en compĂ©tences, etc.

En fin de compte, cette approche est trĂšs similaire Ă  celle appliquĂ©e en entreprise. NĂ©anmoins il est important de noter que moins on s’occupe du nouvel arrivant, moins il restera dans l’entreprise. Inversement, plusieurs Ă©tudes ont Ă©tabli un lien entre performance et qualitĂ© de l’intĂ©gration : les plus performants sont ceux qui ont Ă©tĂ© le mieux intĂ©grĂ©s.

Pour aller plus loin, d’aprĂšs l’étude EDHEC “Les clĂ©s de succĂšs de l’intĂ©gration des jeunes talents” (Janvier 2015) :

 

  • Les principales raisons de satisfaction et d’insatisfaction lors de l’intĂ©gration dans l’entreprise

 

  • Les actions les plus apprĂ©ciĂ©es et celles les plus attendues lors de l’intĂ©gration

 

  • Les 3 conseils des jeunes diplĂŽmĂ©s aux entreprises afin de rĂ©ussir l’intĂ©gration

 

Ainsi, Patrick Dutartre recommande pour chaque nouvel arrivant de proposer :

  • Un kit d’intĂ©gration
  • Une journĂ©e d’intĂ©gration
  • Un parcours d’intĂ©gration individualisĂ© (incluant de la formation)
    • Ex. Michelin : sur 3 mois
    • Ex. L’OrĂ©al : sur 3 mois
    • Ex. Leclerc : sur 11 mois (pour les cadres)
  • Des mises en situation pour tester et valider les acquis
Constitution des équipes (#3)  : Place et rÎle de chacun

Au sein de la PAF,  vous avez pu remarquer qu’il y avait des rĂŽles spĂ©cifiques. Chaque pilote a une mission et doit Ɠuvrer pour le bien commun et la performance de l’équipe, le tout devant ĂȘtre rĂ©alisĂ© dans un cadre Ă©tabli Ă  l’avance (mĂ©thodes, compĂ©tences nĂ©cessaires, planning
).

L’objectif est d’obtenir le meilleur de chacun et libĂ©rer les Ă©nergies individuelles au profit d’une performance et de l’intelligence collectives.

Ces principes se retrouvent dans les projets agiles, notamment sur la mise en place d’équipes pluridisciplinaires, autonomes et responsables. Chaque membre de cette Ă©quipe a un rĂŽle bien dĂ©fini (Delivery Manager, Product Owner, Tech Lead, DĂ©veloppeurs, OPS
) avec une ou plusieurs expertises dĂ©diĂ©es, et partagent la mĂȘme vision du produit.

Constitution des équipes (#4)  : Formation

La formation est un des piliers de la PAF. Cependant, Ă  la diffĂ©rence des entreprises, les compĂ©tences sont sans cesse Ă©valuĂ©es et testĂ©es pour s’assurer que

  • chaque pilote ne met pas en danger la patrouille
  • chaque pilote monte en puissance progressivement, et au mĂȘme rythme que l’équipe globale

En entreprise, le fait que les compĂ©tences soient testĂ©es permet de s’assurer que chaque personne dispose d’un background technique et mĂ©thodologique lui permettant d’assurer ses fonctions dans les meilleures conditions : vous n’iriez pas confier les clefs de votre Ferrari Ă  une personne qui n’a pas son permis de conduire !

Processus de travail (#5) : Préparation

Bien que cela paraisse Ă©vident pour tout le monde, la prĂ©paration est un prĂ©requis non nĂ©gociable au sein de la PAF.  Pour autant en entreprise, ce n’est pas toujours le cas y compris pour les tĂąches qui peuvent nous paraĂźtre banales.

Processus de travail (#6) : Briefing (pour l’information descendante)

Le briefing (diffĂ©rent des rĂ©unions de travail) a pour objectif l’efficacitĂ© opĂ©rationnel de la PAF. En entreprise c’est la mĂȘme chose, il vise l’efficacitĂ© opĂ©rationnel du business.

Chaque briefing est propre à chaque entreprise sur le fond et sur la forme. Selon Patrick Dutartre, la forme d’un briefing repose sur 10 paramùtres :

  1. Quelle fréquence
  2. Quel jour
  3. Quelle heure
  4. Quelle durée
  5. Quel endroit
  6. Avec qui
  7. Debout ou Assis
  8. Avec ou sans café
  9. Préparé ou non préparé
  10. Avec ou sans compte-rendu
Processus de travail (#7) : Visualisation

Avant d’enfiler leur combinaison anti-G et leur casque, les pilotes de la PAF effectuent le mĂȘme rituel, ils font “la musique”. Une chorĂ©graphie manuelle (appelĂ© visualisation mentale proactive, Ă  la diffĂ©rence d’une visualisation subie) aussi surprenante que nĂ©cessaire. Les pilotes “mentalisent” leur vol, ils rĂ©pĂštent chacun des gestes qu’ils vont devoir effectuer Ă  bord de leur Alphajet.

Et si chaque pilote fait la musique à sa maniùre, il n’y a pas en effet de bons ou de mauvais gestes, reste que chacun a sa signification.

Dans cette phase de concentration, les huit pilotes ne font plus qu’un. Ils communient ensemble, attentifs au moindre mot lĂąchĂ© par le leader de la patrouille ou par l’un de leurs Ă©quipiers. Les ordres sont prĂ©cis, directs, courts, car Ă  1 000 km/h dans le ciel et Ă  quelques mĂštres seulement les uns des autres, il n’y a pas de place pour l’approximation.

“Faire la musique” est donc une chorĂ©graphie verbale, manuelle, un prĂ©lude avant qu’elle ne devienne aĂ©rienne.

Voici une vidĂ©o d’un extrait de briefing  de la PAF avant sa dĂ©monstration au salon AĂ©rotop (Poitier, 29 septembre 2012) durant laquelle vous pouvez observer une sĂ©ance de visualisation mentale : https://www.youtube.com/watch?v=WO5G_JM2Kws

La visualisation est vitale pour un pilote de la PAF est une source de préparation fabuleuse.

Ce principe est mis en Ɠuvre chez les sportifs de haut niveau dans leur prĂ©paration aux compĂ©titions. Des procĂ©dĂ©s similaires se retrouvent Ă©galement dans le monde du spectacle, avec les “filages” ou les rĂ©pĂ©titions “à l’italienne” avant une reprĂ©sentation. Pour autant, il est peu dĂ©ployĂ© en entreprise qui a encore du mal Ă  en voir l’utilitĂ© alors que les champs d’actions sont multiples (prĂ©paration d’un atelier de facilitation, prĂ©paration d’une rencontre Ă  fort enjeux, simulation du comportement d’autrui pour Ă©tudier ses propres rĂ©actions et anticiper ce que nous allons dire
).

Processus de travail (#8) : DĂ©briefing (pour l’information ascendante)

Il existe trois types de débriefings :

  1. Quand il y a un problĂšme
    • Un premier dĂ©briefing Ă  chaud (tout de suite aprĂšs l’apparition du problĂšme, avec toutes les parties prenantes) pour
      • reconstituer les faits et rien que les faits
      • aligner tout le monde sur une seule vĂ©ritĂ© et rĂ©alitĂ© communes, partagĂ©es par tous
        • il ne doit y avoir aucun jugement (Ex. Software Craftsmanship : “Dur avec le code, doux avec les Hommes”)
    • Suivi d’un deuxiĂšme dĂ©briefing Ă  froid (gĂ©nĂ©ralement une semaine Ă  un mois plus tard)  pour
      • dĂ©finir qu’est-ce qu’on peut faire pour que ça ne se reproduise plus
      • apprendre  individuellement et collectivement de nos erreurs (valeur trĂšs importante en Agile)
  2. Quand il y a un succĂšs
    • Objectif : comprendre les raisons de ce succĂšs pour pouvoir ensuite les reproduire
  3. Quand tout se passe bien (pour “contrer” la loi de Murphy)
    • Il arrive parfois que nous rĂ©ussissions une action alors que quelque chose n’a pas fonctionnĂ© dans votre process (mais qui n’était pas suffisamment critique pour tout arrĂȘter). De ce fait, ce genre de dĂ©briefing permet de dĂ©tecter de petites erreurs anodines qui auraient pu s’avĂ©rer problĂ©matique Ă  l’avenir.
      • Ex. Vous pouvez vous rendre d’un point A Ă  un point B en voiture avec les clignotants qui ne fonctionnent pas. Bien que vous ayez atteint votre destination en toute sĂ©curitĂ©, vous avez potentiellement mis en danger d’autres conducteurs sur votre route. Vous prenez donc l’action de faire rĂ©parer vos clignotants.
Processus de travail (#9) : Transmission du savoir-faire

Au sein de la PAF, l’historique, le retour d’expĂ©rience des opĂ©rations passĂ©es, les anciens, le suivi des dĂ©briefings
 sont des facteurs de progrĂšs et de performance.

Elle s’appuie sur plusieurs Ă©lĂ©ments pour former ses pilotes :

  • Des checklists pour tout ce qui est rĂ©pĂ©titif et qui a fait ses preuves
  • Des “Standard Operating Procedures” pour tout ce qui est connu
  • Des formations individuelles et collectives dĂ©diĂ©es
    • Rigueur dans l’exĂ©cution
    • MĂ©thodologie pour apprĂ©hender le nouveau
    • DisponibilitĂ© pour apprendre et se remettre en cause

Elle considĂšre qu’à partir du moment oĂč un pilote est formĂ©, il devient automatiquement formateur.

Chez OCTO, l’utilisation de checklists fait partie de notre ADN.

Management pur (#10) : CohĂ©sion d’équipe

La cohĂ©sion d’équipe au sein de la PAF se fait Ă  plusieurs niveaux :

  • AdhĂ©sion Ă  un objectif commun
  • Une vision et des valeurs partagĂ©es
  • Une fiertĂ© due au sens
  • L’exemplaritĂ© (de toute les parties prenantes : des mĂ©caniciens au top management en passant par les pilotes eux-mĂȘmes)
  • Le respect
  • La communication
  • La clartĂ©
  • Des rĂšgles du jeu claires et comprises par tous
  • La place et le rĂŽle de chacun
  • etc.

Il a Ă©galement Ă©tĂ© observĂ© que l’humeur du leader a une influence directe sur l’humeur de son Ă©quipe (rĂ©action purement humaine de mimĂ©tisme et d’exemplaritĂ©).

Autre Ă©lĂ©ment important au sein de la PAF et qui devraient ĂȘtre mis en place dans les entreprises ayant une prĂ©sence mondiale : la dĂ©finition d’un langage minimal commun (dĂ©fini et Ă©crit). Par exemple, dans l’aviation, pour tous les pays et toutes les nationalitĂ©s, on utilise le langage commun :

  • “Clear to land” : autorisation d’atterrissage
  • “Clear for takeoff” : autorisation de dĂ©collage

Ce langage commun doit ĂȘtre Ă©crit, partagĂ© et compris de tous.

Management pur (#11) : Motivation

Pour la PAF, la motivation résulte (entre autres) sur :

  • La crĂ©ation des bonnes conditions
    • La fiertĂ© due Ă  la performance
    • La visualisation de son apport
    • Le sentiment d’appartenance, bien sĂ»r renforcĂ© par la difficultĂ© de la sĂ©lection – ĂȘtre pilote est, comme pour les mĂ©decins, une vocation -, des conditions de la vie militaire et des entraĂźnement. “Souffrir ensemble” comme mĂ©canisme de cohĂ©sion.
    • etc.
  • Le dĂ©veloppement du bien-ĂȘtre
    • La responsabilisation et l’autonomie
    • La reconnaissance
    • Les conditions de travail
    • etc.

Nous retrouvons ces principes de motivation dans de nombreux ouvrages (dont celui de Daniel Pink “La vĂ©ritĂ© sur ce qui nous motive”) et Ă©galement dans les mĂ©thodes agiles.

Par ailleurs, il est prouvĂ© que la reconnaissance est l’une des meilleures mĂ©thodes pour amĂ©liorer la motivation au travail et l’engagement des employĂ©s : fĂ©licitez donc vos collaborateurs !

The Bottom Line Impact of Recognition

Le droit Ă  l’erreur (dans une moindre mesure bien entendu) joue Ă©galement un rĂŽle important dans la motivation Ă  partir du moment oĂč vous apprenez de vos erreurs et que vous ne persistez pas dedans.

AprĂšs avoir percutĂ© la cible volante sur laquelle il Ă©tait censĂ© tirer, puis atterrit en Ă©vitant le crash de son avion abĂźmĂ©, un pilote raconte que son instructeur l’avait amenĂ© de force, les jambes encore flageolantes, au bar du Mess, lui avait fait boire un verre de vin rouge et l’avait renvoyĂ© directement en vol, pour ne pas que la peur “infuse”.

Management pur (#12) : Leadership

Ce thĂšme est bien Ă©videmment trĂšs vaste et ne saurait, lui non plus, ĂȘtre couvert en quelques mots. Patrick Dutartre, dans son humble expĂ©rience, prĂ©conisait Ă  minima de rester soi-mĂȘme et d’ĂȘtre conscient de ses forces et de ses faiblesses (il est donc nĂ©cessaire de savoir s’entourer des bonnes personnes pour se complĂ©ter).

“La grandeur d’un mĂ©tier est peut-ĂȘtre avant tout d’unir les hommes, mais il y a un luxe vĂ©ritable et c’est celui des relations humaines.” – Saint ExupĂ©ry (Terre des hommes).

Sur le terrain, le leadership militaire est affaire d’exemplaritĂ©. Comme pour la PAF, le squad leader est toujours devant et montre l’exemple Ă  ses hommes (ceci reste tout aussi vrai en entreprise !).

La performance de l’équipe est donc la somme du meilleur de chacun.

4. Conclusion

Cette confĂ©rence m’a apportĂ© un regard diffĂ©rent sur le monde militaire que je voyais comme un milieu “processisĂ©â€ au maximum sans se soucier du bien-ĂȘtre des soldats, dans lequel la prise d’initiative est trĂšs faible
 et surtout des rĂšgles et mĂ©thodes qui ne pourraient pas fonctionner dans les entreprises libĂ©rĂ©es. Je suppose qu’on a tous Ă©tĂ© marquĂ©s par le film de Stanley Kubrick“Full Metal Jacket” et bien d’autres d’ailleurs :-)

Cet article avait pour vocation de vous prĂ©senter la partie la petite partie Ă©mergĂ©e de l’iceberg de la PAF. J’ai pu dĂ©couvrir qu’il y avait Ă©normĂ©ment de similitudes entre les Ă©lĂ©ments prĂ©sentĂ©s ci-dessus et ce que nous conseillons Ă  nos clients sur les mĂ©thodes Agiles (droit Ă  l’erreur, amĂ©lioration continue, capacitĂ© d’adaptation, rigueur dans l’exĂ©cution, vision claire et partagĂ©e
). Je pense Ă©galement ces principes peuvent nous aider Ă  amĂ©liorer nos mĂ©thodes de management et nos relations inter-personnelles.  

Rien qu’à mon niveau, je tĂącherai d’ĂȘtre plus disciplinĂ© de prendre plus de temps sur les “dĂ©briefings” pour identifier de nouvelles pistes de progrĂšs (Ă  la fin des avant-vente, projets
).

J’espĂšre que cet article aura suscitĂ© chez vous la mĂȘme envie que moi d’approfondir certains aspects. Peut-ĂȘtre d’autres articles Ă  venir sur des retours d’expĂ©rience personnels de mise en Ɠuvre et des similaritĂ©s entre le mĂ©tier de la PAF et celui d’OCTO ? :-)

Articles suggested :

  1. Management 3.0 : premiÚres réponses aux questions des petits-déjeuners
  2. Les grands groupes devraient-ils s’inspirer des startups ?

Catégories: Blog Société

Partagez la connaissance

Partagez BlogsdeDeveloppeurs.com sur les réseaux sociaux