Jean-Marie Dulau

Direction de Projets et Transformation Digitale

Latest Posts

DevOps et Agile : le duo gagnant de la transformation digitale ?

Le succès de la transformation digitale passe par les pratiques agiles et le DevOps, et la France n’est pas en retard, puisque 87% des entreprises françaises les considèrent comme prioritaires. Les services financiers et clients sont déjà précurseurs sur le sujet.

DevOps: une étape dans l’agilité de l’entreprise

De plus en plus de projets digitaux mettent en oeuvre une approche DevOps pour développer avec un cycle court et mettre en production avec le même rythme, par exemple hebdomadaire.

Mais mettre en production toute les semaines si aucun client n’utilise chaque version livrée ne sert pas à grand chose, à part à dire qu’on travaille en mode agile. L’agilité n’a de pertinence que sur l’ensemble de la chaîne, donc en amont pour la production de besoins avec des cycles itératifs courts, et en aval avec la validation régulière des développements (plus rapide que le rythme choisi) et l’utilisation après mise en production de l’application par de “vrais utilisateurs”.

Est-ce que DevOps c’est mieux que le cycle en V?

L’agilité n’est pas la panacée si l’entreprise n’est pas prête ou si la MOA ne comprend pas les fondamentaux de la démarche. Au contraire, une démarche agile ou DevOps peuvent être un risque d’échec des projets. La bonne pratique exposée consiste à définir les critères à respecter avant de partir tête baissée dans un projet en mode agile. Trois de ces critères discutés lors de cette table ronde ont été :

  • Le besoin d’arriver rapidement en production avec quelques services puis d’itérer avec de nouveaux services.
  • La confiance établie entre ceux qui établissent le besoin, développent, gèrent la production et les utilisateurs finaux.
  • La possibilité de supprimer les validations formelles longues, notamment auprès d’instances externes à l’entreprise.

Un projet agile n’est pas un projet qui arrive plus vite. L’approche ne doit pas être choisie pour réduire les délais du projet. Au contraire, un projet agile peut même être plus long sur l’ensemble du besoin, puisqu’il multiplie par exemple les activités de tests ou de mise en production.

DevOps, c’est la fin de la documentation ?

C’est vrai que les projets agiles ont des exigences plus faibles en matière de documentation. Le manifeste agile reconnaît la valeur de la documentation mais lui préfère un logiciel opérationnel.
Il n’est pas trop tard pour prendre le virage de l’agilité, renforcer la satisfaction client et éliminer les silos, découvrons quelques chiffres et 3 recommandations clés.

Intégrer un nouveau modèle

Pour proposer une expérience numérique unique, il faut intégrer un nouveau modèle et pour cela
positionner les logiciels au cœur des activités
– prendre en compte régulièrement des retours clients lors du cycle développement
– favoriser la collaboration entre équipes de développement et production

Mesurer l’impact du DevOps et des pratiques agiles

Mettre en place ces méthodes implique de mesurer régulièrement leur impact grâce à une sélection d’indicateurs clés de performances livrant des informations sur
– le rendement : amélioration du rendement par les pratiques agiles (39 % – France) et par le DevOps (42%)
– la productivité des collaborateurs : les pratiques agiles augmentent la productivité des employés (44 % – France) et le DevOps (43 %)
– les délais de commercialisation des produits : diminution de la durée de développement et de lancement de nouveaux produits (pratiques agiles, 24 %)
– les délais des nouvelles applications : diminution du temps pour le développement et lancement de nouvelles applications (DevOps, 38%)
– la croissance des activités : réduction du temps pour saisir de nouvelles opportunités (pratiques agiles, 27%)

Combiner Agile et DevOps

La complémentarité des deux méthodologies permet d’optimiser les résultats. Ainsi, la combinaison des deux démarches

– améliore fortement l’expérience client selon 83% des utilisateurs
– fournit de bons indicateurs en termes d’efficacité
– booste les nouvelles activités (+38% – EMEA) et le rendement (+23% – EMEA)

DevOps permet de profiter plus rapidement des bénéfices du développement agile.

DevOps

Le terme DevOps correspond au mélange des tâches qu’effectuent les équipes d’une entreprise chargées du développement des applications (Dev) et de l’exploitation des systèmes (Ops, pour opérations).

Traditionnellement, dans l’entreprise, l’équipe de développement des applications est chargée de collecter les exigences métier dont doit tenir compte un logiciel, puis d’en rédiger le code. L’équipe de développement teste son programme dans un environnement isolé à des fins d’assurance qualité. Ensuite, si les exigences sont satisfaites, elle met le code à la disposition des équipes opérationnelles pour exploitation.

Résultat de recherche d'images pour "devops"

Ce paradigme pose un problème : lorsque les deux équipes travaillent séparément, le développement peut ne pas être au courant des obstacles opérationnels qui empêchent le programme de fonctionner comme attendu.

L’approche DevOps cherche à fusionner développement et déploiement au sein d’un exercice plus rationalisé.

Le kit d’outils DevOps comprend des outils de gestion des configurations, tels que Puppet et Chef ; un référentiel, comme GitHub, pour le stockage des versions du code ; des outils d’indexation comme Splunk ; des outils pour surveiller la manière dont les modifications apportées au code affectent l’environnement, comme Nagios ; sans oublier des langages de script, comme Perl, PHP et JavaScript.

Les entreprises se trouvent aujourd’hui confrontées à la nécessité de délivrer de plus en plus rapidement des applications de meilleure qualité, pour répondre aux demandes toujours plus pressantes des utilisateurs soucieux de diminuer le « Time to Market » .

Le goulot d’étranglement du processus ? La mise en production ! Le nombre toujours grandissant des applications livrées se voyant ralenti par les exploitants… Les directions des études s’opposent aux directions de l’exploitation, leur reprochant de ne pas être assez réactives. Quant à ces dernières, elles reprochent aux études de ne pas tenir compte de leurs problématiques et de ne pas comprendre que le système d’information est un environnement contraint, dans lequel toutes les briques sont interdépendantes les unes des autres, et dont la stabilité et la sécurité doivent être garanties.

DES EXEMPLES CONCRETS ET LEURS TRAVERS

Deux exemples s’avèrent représentatifs de ce qui se passe actuellement dans les entreprises. Dans le premier, un développeur ayant développé un contact de proximité avec une personne de la production « bypasse »  le processus mis en place et, grâce à cette complicité, délivre plus vite son projet, au bénéfice de l’utilisateur. Dans le second, l’environnement de développement est transformé en environnement de production géré uniquement par la MOE, sans que la production n’en ait connaissance. L’utilisateur bénéficiera là aussi d’une meilleure réactivité.

Dans ces deux exemples, la rapidité de livraison est favorisée. Nous serions donc enclins à dire que les utilisateurs seront satisfaits et, par conséquent, que le modèle serait de laisser les services de développement gérer les environnements … Jusqu’au moment où l’environnement de développement « tombera » et que la production ne pourra intervenir que plusieurs heures après, en restaurant un ancien backup, puisque le serveur n’aura pas été étiqueté comme critique ! Conséquence : une perte de temps, d’efficacité, de réactivité, de savoir-faire…

RAPPROCHER DÉVELOPPEMENT ET PRODUCTION

Le climat de défiance entre développement et production est dû à la différence sémantique de deux métiers aux intérêts divergents. Les développeurs, s’appuyant sur les méthodes agiles, cherchent à répondre rapidement aux besoins et demandes d’évolutions du métier. Ce qui se traduit par des livraisons et des demandes de mise en production beaucoup plus rapprochées, augmentant par contre le risque d’instabilité. De l’autre côté, l’équipe d’exploitation doit s’assurer que le système d’information de l’entreprise est un environnement stable, sécurisé et pérenne dans le temps selon les recommandations ITIL, le tout dans un contexte de réduction des coûts et de mutualisation.

Né de cette opposition, le mouvement DevOps (contraction de Development  et Operations ) vise à rapprocher les deux équipes et à aligner leurs objectifs sur les besoins de l’entreprise. Encore récent, il commence à émerger et se trouve actuellement dans la liste des « dossiers chauds » des DSI. Mais pour porter ses fruits, il doit impérativement s’appuyer sur une nouvelle forme d’organisation des équipes favorisant la communication, des processus partagés et des outils.

UNE MEILLEURE COMMUNICATION

Historiquement, les équipes de développement et d’exploitation sont séparées, tant d’un point de vue géographique que des objectifs. Le premier chantier sera donc de rapprocher ces équipes pour permettre une meilleure compréhension des contraintes de chacun, en organisant par exemple des ateliers destinés à faire travailler ces équipes ensemble. Autre point important : définir des objectifs communs. Car c’est en partageant un même but et, ensuite, la réussite d’un projet que les collaborateurs pourront se rapprocher et se comprendre.

DES PROCESSUS PARTAGÉS

La mise en place de processus adaptés et surtout efficaces car suivis par tous, ne peut se faire qu’après DR avoir identifié et intégré l’ensemble des contraintes. Le curseur devra être mis de manière à respecter des temps et fréquences de livraison attendus par l’entreprise, tout en garantissant la qualité et la fiabilité des systèmes. C’est au niveau de l’équilibre de cette équation que résidera la capacité du « Dev » à adhérer au « Ops » !

UN OUTILLAGE ADÉQUAT

Des processus non outillés ne pourront clairement pas répondre aux exigences de communication, de qualité, de standardisation et de fluidité. Mais cela nécessite un outillage adéquat et une formation des deux équipes.

L’outillage devra permettre d’industrialiser le cycle de vie d’une application, l’ALM (Application Lifecycle Management) et en particulier les outils favorisant la communication entre les deux parties  : gestion du versioning et industrialisation des transports de composants, pour permettre de faire du déploiement continu (Continuous Deployment). Les livrables sont ainsi déployés automatiquement dans les différents environnements en suivant un processus de validation. Les géants du web Google, Facebook, Amazon le font déjà plusieurs fois par jour sans que leurs utilisateurs ne s’en rendent compte !

DES BÉNÉFICES INDISCUTABLES

Au-delà d’un terme marketing dans l’air du temps, DevOps apporte de réels bénéfices à l’entreprise. Une récente étude menée auprès de plus de 9 200 professionnels ( Puppet Labs 2014 ) met indiscutablement en lumière les gains de performance enregistrés par les entreprises l’ayant adopté. Même si cela va prendre un peu de temps, DevOps va petit à petit s’imposer dans nos entreprises comme les méthodes agiles ont réussi à le faire, projet par projet, pour gagner enfin l’ensemble du système d’information.

La gestion du cycle de vie applicatif, ou ALL (Application Lifecycle Management)

La gestion du cycle de vie applicatif, ou ALL (Application Lifecycle Management), consiste à superviser une application de sa planification initiale jusqu’à son retrait. L’ALM englobe également la documentation et le suivi des changements apportés à un logiciel.

Concept à l’acception particulièrement large, l’ALM reflète un changement d’attitude à l’égard du développement de logiciels ; changement qui s’exprime également dans le terme DevOp. DevOp correspond au mélange des tâches qu’effectuent les équipes d’une entreprise chargées du développement des applications (Dev) et de l’exploitation des systèmes (Op pour « operations »).

Par le passé, une équipe de développement pouvait travailler en complète indépendance, via un modèle de développement en cascade, et livrer l’application logicielle achevée à une équipe d’exploitation qui se chargeait alors du déploiement et de la maintenance. Aujourd’hui, il est plus probable de voir les développeurs recourir à un modèle agile et rester impliqués après le déploiement de l’application aux côtés des responsables et des personnels opérationnels afin d’apporter d’éventuelles modifications incrémentielles.

De nombreux outils ALM permettent de suivre les changements apportés à une application. Ces outils vont de produits ALM dédiés, qui surveillent l’application de sa création à son achèvement, en triant automatiquement les fichiers en catégories logiques au fil des modifications, à de simples wikis qui obligent l’équipe à consigner manuellement les modifications.

Les solutions de gestion du cycle de vie des applications (ALM) permettent aux équipes qui travaillent sur les applications de fournir des applications de haute qualité avec plus de rapidité et d’efficacité. Cette solution combine les produits, les intégrations d’outils de développement, un écosystème partenaire et une approche flexible sur le plan technologique afin d’améliorer la qualité des applications, la collaboration et la productivité pour éviter tout retard dans les projets.

Ces activités, appelées DevOps (développement + opérations), couvrent le cycle de vie complet de l’application et incluent la planification et le suivi du travail, la conception et l’implémentation du code, la gestion d’un référentiel de code source, l’exécution des builds, la gestion des intégrations continues et des déploiements en continu, les tests (y compris les tests unitaires et les tests d’interface utilisateur), différentes formes de diagnostics dans les environnements de développement et de production, ainsi que la surveillance en temps réel des performances des applications et des comportements des utilisateurs via la télémétrie et l’analyse.

Le marché de ces solutions est dominé par les offres de 5 grands éditeurs : IBM (Rational), HP (et Mercury), Microsoft (Visual Studio avec Team Foundation), Borland et Serena. « Cette connaissance des solutions est toutefois à pondérer car 40% des répondants associent l’ALM à des solutions open source », constate Micro Focus.

L’application lifecycle management ou ALM est le processus global de gestion du cycle de vie d’un logiciel.

Ce terme couvre l’ensemble des moyens nécessaires au développement ou à la maintenance d’une application. Cela concerne les activités de gestion de projet comme les activités d’ingénierie logicielle. Ainsi, ce terme englobe les outils pour faciliter des activités logicielles telles que les exigences, l’architecture, la conception, le codage, les tests, les déploiements, ainsi que des outils à caractère transverse ou ayant pour but d’intégrer ces éléments entre eux.

Les différents cycles de développement en informatique

En cascade, en V , itératif… tout le monde connait le nom de ces modèles de cycle de développement, mais savez-vous comment ils fonctionnent ?

Cet article sera un peu encyclopédique, il a pour but de montrer les grandes lignes, les forces et les faiblesses de ces différentes façons de s’organiser qui ont été mises en place depuis près de 50 ans maintenant. Bien sûr, chaque modèle pourrait mériter un article, voire un livre, mais je vous propose de commencer par cette piqûre de rappel, souvent nécessaire, que vous soyez code guru, chef de projet ou même client.

Cycle en cascade

Présenté par Winston W. Royce en 1970, le modèle en cascade originel est hérité du BTP. Il se base sur 2 idées fondamentales :
Une étape ne peut pas être débutée avant que la précédente ne soit achevée : inutile de monter les murs tant que les fondations ne sont pas coulées (ça arrive parfois mais nous ne sommes pas dans une émission de défense des droits du consommateur…) ; La modification d’une étape du projet a un impact important sur les étapes suivantes.

Ce modèle comporte 7 phases : analyse des besoins, spécifications, conception de l’architecture, conception détaillée, implémentation, tests (validation) et enfin installation. Chacune de ces phases doit produire un ou plusieurs livrables définis à l’avance et a une date d’échéance fixée. On ne peut passer d’une étape à l’autre que lorsque les livrables de l’étape en cours sont jugés satisfaisants. Si tout se passe bien on passe à la phase suivante, sinon on remonte à la phase précédente, voire même en début de cycle si une anomalie critique est détectée.

Cycle en cascade
Avantages du modèle en cascade : Le planning est établi à l’avance et le maître d’ouvrage sait précisément ce qui va lui être livré et quand il pourra en prendre livraiso

Inconvénients du modèle en cascade : ils sont assez nombreux mais le principal inconvénient est la très faible tolérance à l’erreur (les anomalies sont détectées tardivement) qui induit automatiquement un coût important en cas d’anomalie.

Ce modèle a été présenté il y a plus de 40 ans comme étant imparfait et depuis, un grand travail a été fait pour trouver des modèles plus performants et plus robustes, c’est pourquoi je vous invite à ne pas l’utiliser, mais simplement à le comprendre et à l’accepter comme une base de départ. Je vous invite aussi à lire cet article du JDN qui est un bon plaidoyer pour l’abandon du cycle en cascade.

Cycle en V

Face aux problèmes de réactivité que pose l’approche en cascade, l’industrie informatique a adopté le cycle en v dans les années 80. Ce modèle ne se découpe plus en 7 mais en 9 phases qui se répondent 2 à 2 : à chaque étape de conception correspond une phase de test ou de validation, comme vous pouvez le voir ci-dessous.

Cycle en V

Nos neufs phases du cycle en V sont arrivent donc comme ceci :

Cycle en V.

Sur le schéma ci-dessus vous aurez constaté la présence de deux axes : le temps et le détail, c’est à cela qu’est dû l’appellation en V du cycle : plus on avance dans l’étude plus le niveau de détail est précis, ensuite on code, et plus on avance dans les tests moins le niveau de détails est précis.

Avantages du modèle en V : La stricte structure en V permet d’espérer que le livrable final sera parfait, puisque les étapes de test sont aussi nombreuses que les étapes de réflexion. De plus, il est facile de prévoir les tests à réaliser au moment où l’on conçoit une fonctionnalité ou une interface, le travail s’enchaîne donc de façon assez naturelle.

Inconvénients du modèle en V : Malheureusement ce modèle est rarement utilisé tel quel et le V est bien souvent déséquilibré, tantôt côté analyse, tantôt côté recette et la marge d’erreur est bien souvent proportionnelle à la marge de liberté prise par rapport au modèle théorique. Même si notre V de base diffère un peu, je vous invite à lire cet article qui explique bien les pourquoi et les comment de ces déséquilibres.

Cycle en spirale

Défini par Barry Boehm en 1988 dans son article « A Spiral Model of Software Development and Enhancement », le cycle en spirale reprend les étapes du cycle en V, mais prévoit l’implémentation de versions successives, ce qui permet de mettre l’accent sur la gestion des risques, la première phase de chaque itération étant dédiée à ce poste. A ce point il est nécessaire de définir la notion de prototype. En effet, on ne fait pas des versions successives d’un même produit fini, corriger une liste de bugs permet de passer de la béta à la finale mais pas de la v1 à la v2… Le cycle en spirale prévoit donc la livraison de prototypes, c’est à dire de versions incomplètes du produit. Il peut s’agir d’une simple maquette ou même des wireframes sans aucune fonctionnalité (on parle alors de prototype horizontal) ou bien de sites partiellement fonctionnels : telle version implémentera la navigation de

Cycle en spirale

Avantages du modèle en spirale : Le but premier de ce modèle étant la gestion des risques, ceux-ci sont logiquement limités. L’expertise du client croit à chaque itération du cycle, l’apprentissage se fait par touche et pas d’un seul bloc. Enfin, ce modèle est très adaptatif : si chaque prototype apporte des fonctionnalités indépendantes, il est possible de changer l’ordre de livraison des versions.

Inconvénients du modèle en spirale : Selon moi le principal défaut du cycle en spirale c’est qu’il n’est adapté qu’aux projets suffisamment gros, inutile de prévoir la livraison de 5 ou 6 prototypes pour un site vitrine sous WordPress (même si on peut considérer qu’une maquette puis le site en lui-même constituent 2 cycles complets). De plus l’évaluation des risques en elle-même et la stricte application du cycle de développement peut engendrer plus de coûts que la réalisation du logiciel. Enfin, ce type de cycle de développement est complexe, entre les étapes prévues en théorie et celles mises en pratique il y a une grande différence.

Cycle itératif

Simplifions un peu le modèle précédent en réduisant le nombre d’étapes du cycle et séparons les activités des artéfacts (c’est à dire les produits issus de ces activités). Nous arrivons logiquement au modèle itératif, que vous pouvez voir ci-dessous.

Tout commence par l’expression de besoin : le client explique ce qu’il veut, tout en sachant que ces besoins peuvent être modifiés par la suite du processus. Ensuite, on se lance dans le processus itératif en lui-même avec la rédaction des spécifications qui est suivie par le développement, puis la validation (c’est à dire les tests) et enfin une évaluation du travail qui servira d’information de départ pour le cycle suivant en dressant le bilan des difficultés rencontrées et des fonctionnalités abandonnées pendant le cycle. A l’issue de la validation on passe aussi au déploiement : les livrables (il peut s’agir d »une version du site ou logiciel, ou même d’une documentation) qui ont été validés sont déployés, c’est à dire mis à disposition.
Cycle itératif*
Avantages du modèle itératif : Ce type de cycle de développement est le plus souple de tous ceux présentés ici : chaque itération permet de s’adapter à ce qui a été appris dans les itérations précédentes et le projet fini peut varier du besoin qui a été exprimé à l’origine. Comme dans le cycle en spirale, la mise à disposition de livrables à chaque cycle permet un apprentissage de l’utilisateur final en douceur.

Inconvénients du modèle itératif : A mes yeux le plus gros piège de ce modèle de développement c’est la confiance qui amène bien souvent à négliger les test d’intégration. Ainsi les développeurs livrent une nouvelle fonctionnalité sans se rendre compte qu’ils ont cassé une chose qui fonctionnait dans les cycles précédents. Il faut donc que le chef de projet soit particulièrement vigilant lors de la phase de tests.

 Cycle Agile

Eh non le développement Agile n’est pas une question de cycle, c’est surtout une question de philosophie, de culture, qui place la réactivité et l’implication du client en priorité. En fait les méthodes Agile se basent sur un modèle semi-itératif qui peut être défini soit par la structure du projet (modèle Top-Down), soit par les besoins exprimés (modèle Bottom-Up).

Les principales méthodes agiles:

ASD (Adaptive software Development)

Créée par Jim Highsmith (signataire du Manifeste) en 2000 en publiant l’ouvrage Adaptative Software Development, a collaborative approach to managing complex systems. Ses caractéristiques principales sont :

  • Focaliser sur l’objectif (mission focused)
  • Se baser sur des composants (component-based)
  • Itérer
  • Découper le temps et fixer des deadlines (timeboxing)
  • Piloter le projet par les risques (risk-driven development )
  • Accepter le changement

Crystal

Cette méthode a été mise au point par Alistair Cockburn (signataire du Manifeste) en 1997. Elle consiste à sélectionner la méthode applicable en fonction du nombre de personnes à coordonnées.

Ses caractéristiques principales sont :

  • Des livraisons fréquentes
  • Des aménagements permanents
  • Une bonne communication interpersonnelle
  • Confiance, liberté d’expression et sécurité personnelle
  • Focus sur l’objectif et disponibilité
  • Un contact permanent avec les utilisateurs
  • Un environnement de travail approprié pour l’automatisation des tests, la gestion de configuration et les intégrations fréquentes
  • Une collaboration étroite entre toutes les parties prenantes, y compris en dehors de l’équipe
  • Une réflexion constante sur ces propriétés

Scrum

Le Scrum ou « mêlée », créée par Ken Schwaber et Jeff Sutherland (signataires du Manifeste) en 1993, est un terme emprunté au rugby qui désigne la solidarité et la force qui lient les membres de l’équipe au succès de l’itération.

Le cycle de vie de Scrum est rythmé par des itérations de quatre semaines qu’on appel sprints.

scrum

Avant chaque , on effectue une réunion de planification appelée le sprint planning meeting qui consiste à sélectionner les exigences prioritaires pour le client dans le produit qui seront développées, testées et livrées au client : le backlog sprint (sous-ensemble du produit backlog).

Des mêlée sont organisées quotidiennement (mêlée) durant le sprint afin de contrôler l’avancement pour s’assurer les objectifs sont tenus. A la fin du sprint, une démonstration des derniers développements est faite au client qui donnera lieu à un bilan qualitatif sur le fonctionnement de l’équipe.

Les valeurs mises en avant par cette méthode sont les suivantes :

  • Visibilité : Avoir une vision réelle sur le résultat
  • Inspection : Vérifier l’écart par rapport à l’objectif initial
  • Adaptation : S’adapter en fonction des écarts constatés afin de les ajuster. Scrum est favorable à des petits ajustements fréquents

Il existe d’autres méthodes agiles :

  • (Dynamic Software Development Method) créée en Grande-Bretagne en 1995
  • (Rapid Application Development) créée par James Martin en 1991
  • (eXtreme Programming) créée en 1999

Voici un tableau récapitulatif des différences entre les deux méthodes.

comparaison agiles & classique

Les méthodes agiles seront plus utilisées pour les gros projets car elles offrent une meilleure adaptabilité, visibilité et gestion des risques. Elles pourraient tout aussi bien être utilisées pour les projets où il n’y pas de documentations détaillées, le client peut alors voir l’évolution du projet et l’adapter selon ses besoins.

En revanche, les seront plus utilisées si vous avez une idée très précise de votre projet avec un cahier des charges et planning très détaillé où vous avez anticipé tous les risques possibles.

Le chef de projet se retrouve souvent seul face à lui-même lors de la prise de décision, de gérer les retours client, devant l’incertitude afin de satisfaire le client tout en respectant les 3C. On pourrait alors l’assimiler à un art martial car il doit avoir une grande maitrise de soi et de l’environnement de chaque projet auquel il est amené à gérer.

Alexa d’amazone

Le service d’assistant personnel d’Amazon, Alexa, a été une réussite surprise. L’outil, enfermé au sein de l’enceinte intelligente Amazon Echo, s’impose rapidement comme le hub de référence de la maison connectée.

Alexa peut être utilisée pour diverses tâches comme lancer de la musique, rédiger une liste de courses, régler un réveil ou contrôler les systèmes domotiques d’un domicile, et même démarrer sa voiture.

Alexa dispose désormais de 7000 “skills” ou aptitudes, c’est-à-dire des services associés à des commandes vocales. Amazon a déjà écoulé cinq millions d’enceintes Echo (et probablement plus grâce à la période des fêtes).

Ce mois-ci à l’occasion du CES, Alexa a été une des vedettes du salon avec des fabricants d’appliances et des entreprises de l’électronique grand-public annonçant leurs projets d’intégration de l’assistant vocal d’Amazon dans leurs produits.  À l’heure actuelle, la dynamique semble assurément se construire derrière Alexa, mais cela ne signifie pas que l’assistant numérique d’Amazon va régner sur le monde – du moins pas encore.

Afficher l'image d'origine

Voici quelques points à considérer.

1. Le contrôle vocal, c’est génial, mais ne sera pas utilisé partout

Recourir à un assistant électronique contrôlé par la voix fait beaucoup de sens dans certaines situations. Si vous avez les mains pleines – avec un volant, ou un dîner à moitié préparé, peut-être – prononcer une commande simple est nettement plus commode que de la taper.

Et ce que la récente fournée d’assistants numériques à commande vocale a fait est de commencer à combler les lacunes laissées par d’autres formes de saisie, comme le clavier. Mais cela ne signifie pas que la parole remplacera le clavier ou l’écran pour des tâches plus complexes. La parole fonctionne mieux avec des commandes simples, et non des requêtes longues, compliquées, précises et imbriquées. Deux raisons à cela : premièrement, parce que les algorithmes trouvent toujours difficiles à traiter ces demandes complexes, et deuxièmement parce que les humains les trouvent difficiles à composer, ce qui explique pourquoi nous écrivons des choses.
De même, l’utilisation de la commande vocale dans les entreprises est susceptible de demeurer une niche : il est beau de crier “Alexa, mets le minuteur” pour couvrir le bruit de la famille dans la cuisine -, cela l’est peut-être moins au bureau.

2. La monétisation des skills Alexa n’est pas évidente

Les écosystèmes smartphone ont explosé dans la vie quand les développeurs indépendants ont réalisé qu’ils pourraient faire de l’argent sérieusement à partir de la construction d’applications pour Android et iOS. S’il existe déjà de nombreuses skills Alexa, beaucoup sont triviales ou simplement des connexions à des applications existantes.
Il n’est pas évident que le contrôle vocal en lui-même soit suffisant pour soutenir un écosystème comme celui du smartphone avec des centaines de milliers d’applications. En effet, invoquer des applications Alexa est lui-même trop compliqué, parce que les utilisateurs doivent se rappeler les noms spécifiques et les mots clés nécessaires pour activer chaque application. Cela peut limiter le nombre utilisé (je ne peux moi-même me souvenir que d’une demi-douzaine), au moins jusqu’à ce que le processus d’appel soit simplifié.

3. Les problèmes de confidentialité pourraient s’accroître
Amazon est transparent à propos de ce qui est enregistré par le service Alexa et ce qui ne l’est pas – et vous permet d’écouter les enregistrements via l’app Alexa, et de les supprimer si vous le souhaitez.
Mais, écouter ces archives vous fera encore un choc en entendant votre propre voix – ou celles des membres de la famille –  envoyées dans les serveurs Cloud d’Amazon pour y être traitées. À mesure que les appareils à commande vocale seront plus largement utilisés, des problèmes supplémentaires autour de la vie privée apparaîtront sans aucun doute. La façon dont les fournisseurs traiteront ce sujet aura un impact important sur le succès des appareils à commande vocale.

4. Amazon profite de la dynamique, mais pour combien de temps ?

Amazon a certainement pris une longueur d’avance sur des concurrents comme Google et Apple en trouvant le bon appareil pour incarner son service Alexa. Mettre Siri ou Google Now dans un smartphone n’a jamais très bien pris : nous voulons parler sur nos téléphones, non leur parler à eux.

A son domicile, les situations potentielles d’embarras liées au fait de parler à un de ces services sont moindres, comme l’a réalisé Amazon. Google va certainement tenter de réduire l’avance d’Amazon en utilisant son haut-parleur Google Home, comme le fera Apple avec ses ambitions de longue date dans le domaine de la maison intelligente.

L’avantage d’Apple ici est susceptible de résider dans la question de la vie privée, tout comme cela est le cas dans le monde des smartphones. Dans la maison, cela pourrait être un gros enjeu.

Qu’est ce qu’un DMP ?

DMP est l’acronyme pour Data Management Platform ou plateforme de gestion des données. Il s’agit d’une plateforme proposée généralement en mode Saas et permettant de récupérer, centraliser, gérer et utiliser les données relatives aux prospects et clients. Les premières DMP était centrées sur les données de navigation Internet et utilisées à des fins de publicité comportementale. Désormais, les DMP les plus évoluées intègrent les différents points de contact pour la collecte de données et le ciblage marketing et réunissent le offline et le online en utilisant notamment des procédures de CRM onboarding.

Afficher l'image d'origine

Les données gérées par une DMP peuvent également être enrichies par des données en provenance de tiers « spécialistes de la data ». Les données gérées par une DMP sont utilisées pour optimiser le ciblage et l’efficacité des campagnes marketing et publicitaires. La DMP peut être vue comme l’héritière de la « traditionnelle » base de données clients et devient un pilier du CRM à travers notamment la mise en place d’un référentiel client unique. Les DMP proposent de nombreux types de services ou fonctionnalités aux entreprises utilisatrices dont certaines s’étendent à la gestion des prospects et audiences publicitaires dans une logique de PRM.

Avec le Big Data se développe donc le MDM (Master Data Management) et les DMP (Data Management Plateform) pour construire en particulier le Référentiel Client Unique (RCU) dont les objectifs principaux sont connaissance client, décisions et actions pour une relation efficiente et donc performante

—La gestion des données de référence, ou MDM (Master Data Management), est une méthode exhaustive permettant à une entreprise d’associer toutes ses données critiques à un seul et unique fichier, appelé « fichier maître », qui constitue un point de référence commun.

—De données dispersées et disparates dans l’entreprise, le MDM permet de bâtir de manière au maximum automatisée un référentiel maître (Master Data) unifié. Ce référentiel nourrit, par la suite, toutes les applications de l’entreprise. Désormais ces dernières, et par conséquent, tous les utilisateurs, parlent la même langue !

—Ce référentiel maître (Master Data) est alimenté via ce que nous appelons des “goldens records”. On appelle « golden record », la version d’une donnée référentielle que l’on considère comme la vérité. Dans le système d’information, une même donnée, par exemple un client, peut exister dans autant de versions que de systèmes en hébergeant une copie.

 

—Chaque version est, en général, une part de la vérité. Le golden record contient le maximum de véracité pour créer l’enregistrement véritable.

—Par exemple dans le système de réclamation on peut s’attendre à ce que le mail soit correct. Alors que dans le système d’inscription, il est possible que cette information soit peut pertinente alors que l’adresse du client y est surement pertinente. Le MDM (Master Data Management) va fusionner le système de réclamation et le système de d’inscription pour créer un golden record avec à la réconciliation des informations les plus pertinentes.

 

CDI
D’où la spécificité des solutions de type CDI (Customer Data Integration) qui ont pour particularité de fonctionner en mode hub (pour pouvoir intégrer automatiquement des
données hétérogènes). Une autre spécificité de ce type de MDM est de nativement intégrer des fonctionnalités de qualité de données (standardisation, validation d’adresse, rapprochement en logique floue, etc.) afin de garantir au sein du référentiel que les données de ce client sont bel et bien complètes, conformes, cohérentes et exactes.
Pour résumer les deux principales qualités d’un MDM de type CDI sont sa capacité de consolidation (mode Hub) d’une part sa faculté de garantir la qualité de données d’autre part.

PIM
PIM (Product Information Management) optimisent la gestion des données complexes en fournissant à vos équipes les bonnes informations,  au bon moment, et depuis une source
unique.

Qu’est-ce que la blockchain?

La blockchain est un outil novateur et révolutionnaire qui, selon de nombreux spécialistes, s’apprête à bouleverser nos vies comme l’ont fait avant elle l’imprimerie et Internet. Elle s’annonce d’emblée comme une promesse, celle de changer en profondeur l’organisation des transactions, et séduit gouvernements, grandes entreprises, fonds d’investissements et entrepreneurs. Mais qu’est-ce que la «blockchain» ?

La révolution «blockchain»

Nombreux sont ceux qui pensent aujourd’hui que ce qui a été fait pour la monnaie, à savoir le passage d’un fonctionnement centralisé à une organisation décentralisée, peut s’appliquer à d’autres domaines. La blockchain est une technologie de stockage et de transmission d’informations transparente, sécurisée, et fonctionnant sans organe central de contrôle. Par extension, elle constitue une base de données publique, distribuée – c’est-à-dire partagée par ses différents utilisateurs, sans intermédiaire – fiable et inviolable. Ainsi, elle peut être assimilée à un grand livre des comptes public, anonyme et infalsifiable.

Afficher l'image d'origine

La blockchain pourrait à terme remplacer tous les «tiers de confiance» centralisés (banques, notaires, cadastres, etc.) par un système informatique décentralisé.

Un cas concret: le projet Ethereum

Des différentes applications possibles du protocole Blockchain est né un projet ambitieux, porté par le programmeur Vitalik Buterin, celui de transformer l’ensemble d’Internet. C’est le projet Ethereum.

Ethereum permet à tous les utilisateurs de créer leur propre base de données publique, sécurisée, infalsifiable, et de se prémunir ainsi de la corruption, de la fraude ou de l’effacement des données. Se définissant comme une «nouvelle plate-forme révolutionnaire de développement d’applications», Ethereum s’apprête à bouleverser des domaines aussi divers que les systèmes de vote, les infrastructures financières, la propriété intellectuelle, encourageant la création d’organisations autonomes décentralisées.

La blockchain d’Ethereum permet également de programmer des «smart contracts» (contrats intelligents), dont le code est une réplique de l’exécution d’un contrat classique. Ces contrats sont accessibles par toutes les parties autorisées, leur exécution est contrôlée et vérifiable. Ils sont conçus pour appliquer les termes précis d’un contrat défini lorsque certaines conditions sont réunies. Les «smart contracts» permettent d’éliminer le risque de défaut d’une des contreparties et de renforcer l’égalité entre toutes les parties.

En somme, la blockchain est une façon décentralisée de contrôler et de stocker de l’information. Elle permet ainsi de développer des applications et des contrats programmables et autonomes. C’est une «nouvelle frontière» au-delà de laquelle nous attendent de nouvelles percées technologiques.