mardi 14 mars 2017

La France en avance pour DevOps et l'agilité

La France en avance pour DevOps et l'agilité


Cette semaine dans le cadre des rencontres d'affaires mobilité et digitale de ROOMn, s'est tenue une table ronde pour faire le point sur la mise en oeuvre de DevOps dans les entreprises. Dans une salle pleine et très participative, ce fut l'occasion de faire le point sur les questions pratiques que se posent encore les directions SI et marketing sur DevOps et sur l'agilité en général, des démarches indispensables pour toute transformation digitale.

Gaettan Falletta, qui participe à la stratégie Internet des Objets d'Airbus, Philippe Bedu, chargé de mission à la DSI groupe d'EDF et moi-même en charge de la Stratégie Digitale de Suez Smart Solutions, étaient interrogés par Olivier Bouzereau qui animait le débat avec la salle.

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".
Résultat de recherche d'images pour

D'ailleurs sans vouloir dévaloriser le travail d'une équipe dite de maîtrise d'ouvrage pour valider les nouvelles fonctions, la seule validation qui compte est celle des utilisateurs qui, en conditions opérationnelles réelles, vont utiliser ces nouveaux services, se les approprier voire en imaginer de nouveaux usages auxquels l'entreprise n'avait pas pensé au départ.


DevOps a t-il vocation a être la règle pour l'ensemble des projets d'une DSI ?

Les retours d'expérience d'Airbus et EDF montrent qu'une partie uniquement des projets sont gérés avec cette approche et que les objectifs sont au mieux de l'utiliser pour 20% à 50% des projets. Le "cycle en V" a donc encore de beaux jours devant lui ! Par exemple quand on veut travailler avec un prestataire unique au forfait. Le forfait est difficilement compatible avec une approche agile puisque le besoin n'est pas totalement spécifié au départ et donc ne peut faire l'objet d'un engagement ferme pour sa réalisation.

Pour GreenSI, pour les projets de transformation numérique, on assiste à une augmentation du nombre de développements spécifiques pour développer des plateformes de plus en plus différenciantes. DevOps est totalement adapté aux développements spécifiques. On peut donc penser que cette approche pourrait représenter à terme 100% des développements spécifiques liés à la transformation digitale, principalement dans la mobilité et les plateformes numériques pour les clients.

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.



Un projet agile amène plus vite UNE PARTIE des fonctionnalités (ex. "la patinette") en production. Il permet d'itérer et donc de s'améliorer, pour avancer vers un service de plus en plus adapté à l'utilisateur. C'est pour ces raisons que l'on doit choisir DevOps, et cela demandera une énergie au quotidien.

Une maîtrise d'ouvrage n'ayant pas cette énergie, ou trop prise dans son quotidien opérationnel, ne sera pas à l'aise dans un projet agile, et l'échec sera probable. En premier lieu, ce sera le rejet de la méthodologie de façon plus ou moins affichée, notamment le rejet des outils collaboratifs transverses pour revenir à des outils individuels et des documents, et parfois par la fin du projet lui même. En revanche si le projet est adapté à l'agile, ses chances de succès seront multipliées par rapport à celles dans un cycle en V.

Le second élément est LA CONFIANCE. Elle est cruciale. La question peut sembler politiquement incorrecte dans l'entreprise où tout le monde devrait se faire confiance. Pourtant de multiples procédures dites de contrôle ou de validation ne semblent être là que pour compenser un niveau de confiance moindre dans les autres équipes avec qui on travaille. C'est antagoniste avec l'agilité, qui, elle, se conçoit dans une démarche d'amélioration continue, donc de confiance puis d'amélioration, et donc pas de contrôle absolu a priori et permanent.
C'est cette confiance et cette compréhension mutuelle qui est à l'origine et à la base du rapprochement des "Dev" et des "Ops", puis avec l'agilité des métiers et des développeurs.

Alors quand un chef de projet veut tout contrôler car il croit (comme dans un cycle en V) que son rôle est d'être justement le "chef" du projet, vous savez que la méthode agile n'est pas adaptée et qu'un cycle en V frustrera moins les équipes.

De même, elle n'est pas adaptée quand on n'arrive pas à nommer un product owner UNIQUE, et quand chacun veut donner son avis ou tout contrôler de l'interface aux priorités des scrums. Ceci sachant d'ailleurs que le seul avis qui compte à la fin, c'est celui de l'utilisateur final et de sa perception de son expérience (utilisateur), le Saint Graal du succès digital.

L'approche DevOps suppose donc la maitrise d'un fonctionnement transversal pour les équipes techniques ET métiers, plus ou moins simple en fonction de la culture d'entreprise. Elle s'inscrit donc bien dans la transformation - changer de forme - digitale de l'organisation et dépasse largement le cadre de la DSI et des équipes SI.

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.


Pour GreenSI, DevOps oblige en fait à se reposer la question de ce qu'est une documentation, de sa finalité et donc du format et du moment le plus a approprié pour la produire :
  • À quoi bon faire des spécifications détaillées dans d'épais classeurs si les développeurs ne les lisent pas?
  • Ne vaut-il pas mieux documenter son besoin pour qu'il soit compris par ceux qui vont le réaliser plutôt que par ceux qui l'écrivent?
  • À quoi sert un cahier de recette quand les tests sont automatisés?
  • À quoi sert une documentation d'installation quand on a le script du robot qui déploie en continu dans la minute les versions successives et gère les retours arrière ?
Autant de questions qui démontrent que la documentation a souvent été pensée dans un cycle en V et qu'elle doit être repensée dans une approche DevOps.

La France en avance sur DevOps !

Une enquête menée à l’échelle mondiale en partenariat avec CA Technologies révèle que 87% des organisations françaises considèrent les pratiques agiles et le DevOps comme essentiels à la réussite de leur transformation numérique.
Une sélection d’indicateurs clé de performances (KPI) permet de mesurer l’impact du DevOps et les conclusions pour la France sont sans équivoques :
  • Les pratiques agiles diminuent la durée de développement et de lancement de nouveaux produits de 24% (de 9,59 à 7,33 semaines) ;
  • Le DevOps raccourcit le temps nécessaire pour le développement et lancement de nouvelles applications de 38% (de 13,43 à 8,27 semaines) ;
  • Les pratiques agiles augmentent la productivité des employés de 44% ; le DevOps de 43% ;
L'étude montre aussi que les structures françaises font preuve d’une grande maturité en matière de DevOps avec 39% d’utilisateurs avancés (Allemagne - 40%, Royaume-Uni - 32%), et 33% quand on considère l'agile en général, soit autant que l’Allemagne et l’Espagne, et plus que le Royaume-Uni (29 %).

Cela fait 3 ans depuis le premier billet de GreenSI en 2014 qui s'étonnait que le sujet DevOps très développé outre Atlantique, n'avait pas encore atteint les côtes françaises. Visiblement en 3 ans la France a commencé à adopter cette bonne pratique, et certains prédisent que 2017 sera l'année de la généralisation. 

mardi 7 mars 2017

Le "low code" une chance que la DSI pourrait manquer

Le "low code" une chance que la DSI pourrait manquer


Il y a un an GreenSI écrivait "L'Empire DSI stoppé dans son expansion" et explorait une idée étrange : n'est-il pas temps de quitter la DSI et de la re-booter ? Sous-entendu quitter la DSI actuelle, cette DSI "Empire" qui s'est étendue avec l'informatisation croissante de toutes les fonctions, afin de créer une nouvelle organisation des SI dans l'entreprise, beaucoup plus adaptée à l'économie numérique et au business.

La publication ce début d'année de plusieurs articles sur la tendance du "low code" (comme Nouvelles menaces sur les prérogatives de la DSI), une approche qui challenge une fois de plus une organisation traditionnelle des systèmes d'information, est l'occasion de remettre le projecteur sur une activité essentielle dans une économie numérique : développer !

Un bon carreleur sait carreler, et bien pour GreenSI une bonne DSI doit savoir coder !

On a peut-être tendance à l'oublier, voire à croire qu'il suffit de le sous-traiter au forfait en Inde, mais le développement et l'architecture sont les activités stratégiques dans une économie numérique, faite de plate-formes, où la différenciation est dans la performance, la mobilité et l'expérience des utilisateurs. 

Ainsi, après avoir eu une l'idée d'une application, passé des mois d'études et de conception, de réunions et de comités de décision, il faut bien un jour passer à l'essentiel: la faire développer, la mettre en production et monitorer l'expérience utilisateur.

Et c'est là que le "low code" amène un nouveau paradigme à la DSI en cherchant à fournir aux métiers le service d'une plate-forme technique unique de développement rapide (et surtout minimaliste) pour intégrer cette chaîne.


Le "low code" est pourtant perçu comme un danger par les DSI se sentant court-circuitées alors que c'est bien sûr une formidable opportunité de transformation et de "re-boot" d'un processus applicatif parfois à bout de souffle.

Ce nouveau paradigme mixe technique ET organisation (processus collaboratif de développement), alors qu'une DSI "traditionnelle" pense souvent uniquement technique. Dans ce type de DSI, après avoir proposé un développement rapide "low code", ne vous étonnez pas d'être invité à une réunion pour savoir quelle est la meilleure solution entre Mendix, Appian ou Outsystems - des plate-formes "low code" - et des environnement de développement plus classiques comme Symfony2 (PHP) ou VisualStudio.
En fait la question n'a pas de sens. On ne parle pas de la même chose. On ne peut comparer des plate-formes de développement permettant de faire du sur-mesure, qui demandent aussi de mettre en place et d'outiller une démarche de développement Agile et Devops, avec des plate-formes de développement rapide "low code" simplifiées intégrant la méthode, dont l'environnement Devops de mise en production et de supervision.
Pour aborder le développement deux approches alternatives s'offrent donc aux DSI:
  • Monter une organisation outillée et une plate-forme à même de développer rapidement les besoins des métiers, quitte a sourcer les développeurs dans des sociétés spécialisées, et donc qui pousse en production rapidement sur une plate-forme Cloud et suit l'expérience utilisateur. C'est ce que les équipes digitales des organisations ont généralement fait ces dernières années pour suivre le rythme de la transformation numérique des métiers.
    C'est l'approche préférée de GreenSI depuis plusieurs années récemment abordée dans le billet "Entreprise du futur: arrêtons de parler de technologies"
  • Adopter une plate-forme "low code" qui offre ce service sous la forme d'une plate-forme, former et animer la communauté des métiers pour l'utiliser et quitter son rôle régalien pour remonter ses manches et passer du côté des "makers". Elle ne permettra pas de traiter tous les développements, mais c'est un moyen d'acquerir un processus collaboratif nouveau, par exemple pour les applications mobiles ou celles avec des transactions simples.
En revanche ce qui est sûr pour GreenSI c'est qu'il n'y a pas d'avenir au mode qui laisserait la technique et la méthode aux choix d'un sous-traitant de la DSI, quand elle même se concentrerait uniquement sur l'achat et le contrôle de la prestation et le "verrouillage" de la plate-forme de production au nom de la sécurité. Cette approche a non seulement aucune chance d'être agile mais n'est pas non plus adapté à la livraison en continu et à l'itération rapide pour adapter rapidement le service.

Le "low code" vient donc réveiller les DSI qui ne sont pas engagées dans la mise en place d'organisations de développements efficaces, qui n'ont pas encore abordé lé DevOps, en offrant leurs services directement aux métiers.
 
Peut-on s'attendre à un sursaut ?

Malheureusement par expérience le premier réflexe d'une DSI devant une nouveauté ou d'un changement de paradigme n'est pas nécessairement l'adoption. Alors ne vous étonnez pas si elle consacre en priorité  100% de son analyse à la comparaison technique des outils et considère la méthode comme un détail de l'implémentation...
Le problème c'est que techniquement il est assez simple de démontrer qu'un environnement de développement sur-mesure est supérieur techniquement au "low code", ce qui peut conforter la DSI dans sa position alors que ce n'est pas la question posée.

La bonne question c'est quel avantage concurrentiel l'entreprise peut-elle acquérir en maitrisant une chaîne de développement rapide et agile ?

Donc sans surprise, d'après l'enquête dirigée par Appian, 73% des DSI pensent que ces plate-formes "low code" sont un risque en terme d'utilisation de mauvaise données et de vulnérabilités, et peu voient les avantages en agilité qu'elles procurent.

Le "low code" pour rebooter la DSI ?

Une DSI "en phase de reboot" devrait au contraire considérer que c'est à elle d'aller chercher et amener les bonnes données à ces plate-formes, par exemple sous la forme d'une plate-forme API du SI, d'assurer la bonne intégration dans le SI, de former les utilisateurs et de les accompagner pour garantir la sécurité. Il est vrai que cette approche demandera de nouvelles compétences à la DSI, donc de l'énergie et des budgets pour convaincre la DG de ce nouveau rôle. 

Et dans la perspective d'un SI de plus en plus ouverts sur des écosystèmes externes avec qui l'entreprise échange des données via des API, ces nouvelles compétences sont finalement les mêmes que pour animer une communauté de développeurs externes et pour développer l'opendata. Comme l'imagine dans le système complexe de la "smart city", et comme c'est déjà le cas pour les API dans le secteur du transport, où elles représentent de nouveaux services numériques et des revenus additionnels.

C'est donc bien une transformation interne ET externe qui est devant les DSI qui sauront en saisir l'opportunité.

En terme de plate-forme, le cabinet Forrester, qui conseille les DSI, recommande depuis 2016 de s'intéresser à ce sujet, sans pousser cependant à la transformation radicale. Les plate-formes "low code" ont donc été benchmarquées et ont ainsi obtenu leurs lettres de noblesse ; ou au moins du sérieux pour être considérées par les organisations des grandes entreprises, souvent frileuses à s'engager dans de nouvelles voies.



Mais attention, car le choix de la plate-forme n'est que la moitié du problème.

Si la DSI n'adopte pas aussi le nouveau paradigme d'une organisation agile, le risque est de rigidifier ces plate-formes avec une gouvernance et des procédures non adaptées, issues de la gestion d'un SI historique pas assez réactive pour tirer de la valeur de ces nouveaux environnements. Et après l'echec de leur mise en place la DSI aura alors beau jeu de dire que techniquement elles n'étaient pas assez solides, ce qu'elle avait démontré par ses études, et qu'il ne fallait pas les choisir. CQFD...

Changer la technique et l'organisation en même temps reste donc toujours une tâche très compliquée sans une volonté venant du haut de l'entreprise et une conduite des changements appropriée.

C'est d'ailleurs certainement le facteur qui freinera l'évolution du "low code" dans les prochaines années. Après avoir rejeté l'internet dans les années 2000, et le cloud dans les années 2010, la DSI a une nouvelle chance pour ne pas rater sa nouvelle place dans l'entreprise amenée sur un plateau : celle de l'usine à logiciels adaptés rapidement aux besoins des métiers et bien intégrée avec les plateformes de déploiements.
Résultat de recherche d'images pour "greensi moebius"

samedi 4 mars 2017

Les robots sont dans le près

Les robots sont dans le près

Avec l'ouverture du Salon de l'Agriculture jusqu'au 5 mars, GreenSI s'est posé la question de l'évolution de cette industrie au travers des âges et ce qu'elle pouvait nous apprendre sur la révolution technologique en cours.

Contrairement à une idée reçue, les agriculteurs sont souvent en tête de l'usage de nouvelles technologies. La crise de ce secteur est une crise de business modèle (quel intermédiaire tire la valeur, comment assurer sa production à l'heure du dérèglement climatique...) et non une crise technologique et encore moins de productivité.

Le billet de GreenSI d'avril 2014, rédigé à la Startup Academy nous le rappelle dans le contexte des éleveurs. La société BioPic y avait gagné la compétition avec ses vaches connectées. Objet connecté pour mesurer des paramètres physiologiques, pile intégrée transformant le glucose en énergie électrique, géolocalisation des individus du troupeau, données remontées dans un "Farm Cloud Service", tous les ingrédients technologiques étaient là pour inventer des usages particulièrement innovants.

Même le modèle économique basé sur la location des capteurs avec un abonnement mensuel par tête de bétail était en avance sur son temps.
Car l'adaptation du monde agricole aux nouvelles technologies ne date pas d'hier.

Depuis les premiers Hommes sédentarisés par cette activité, la mécanisation a toujours permis d'augmenter les rendements et la productivité de la ferme. Ces cent dernières années ont vu la révolution des machines agricoles sophistiquées et spécialisées remplacer la traction animale et développer l'agriculture intensive. En parallèle, la gestion économique, technique et écologique des exploitations s'est informatisée. Cette révolution s'est aussi accompagné d'un usage de plus en plus intensif des données, accessibles directement aux agriculteurs (les premiers utilisateurs des Minitel dans les années 80) pour la météo, le suivi des parcelles ou les cours des marchés agricoles. 

Le fait que ces machines soient pilotées par des humains et qu'elles ne soient pas totalement autonomes explique certainement pourquoi on parle rarement de robots pour les désigner.

Pourtant la tendance est prise car les technologies qui permettent de les rendre autonomes existent et elles auront alors tous les attributs des robots dans un monde agricole.
Ces technologies "smart" sont par exemple:
  • les données collectées par les drones pour individualiser les opérations sur chaque parcelle et mieux les connaître,
  • la géolocalisation des mesures et des machines,
  • les nouveaux capteurs qui peuvent être embarqués dans les machines,
  • la connexion de la machine au logiciel qui peut les piloter pour coordonner les engins entre eux. Par exemple une moissonneuse-batteuse sera suivie par une remorque autonome pour récupérer les grains et ira se vider toute seule pendant qu'une autre remorque prendra sa place.
Comme dans d'autres industries à d'autres époques, la machine, la donnée, la connexion, puis l'intelligence logicielle ont eu un effet de rupture dans l'équipement des travailleurs agricoles.

De plus, en 2008 certains fabricants de machines se sont rassemblés dans un organisme de normalisation (AEF - Agriculture Electronic Foundation) pour permettre au matériel de l'un de communiquer avec le matériel de l'autre (Isobus - protocole de communication universel entre tracteurs) et de ne pas obliger l'agriculteur d'avoir un parc homogène comme une certaine marque à la pomme.

Et pour demain, un groupe de travail de l'AEF refléchit d'ailleurs à l'extension de cette norme au niveau de la ferme et donc aller vers un "système de systèmes intelligents".



À l'avenir ce sont donc bien des robots que nous auront dans les champs.



L'évolution de la mécanisation de l'agriculture est donc intéressante pour aborder deux questions actuelles sur les robots :
  • Les robots vont-ils prendre la place de l'Homme ?
  • Faut-il les taxer ?
Oui si on en juge par la population agricole divisée par 10 depuis 1945, les robots, comme les machines avant qu'elles ne deviennent autonomes, vont prendre la place de l'homme pour toutes les tâches automatisables par des machines de plus en plus sophistiquées. Ceux qui restent se sont adaptés à la taille des exploitations demandées par les investissements en mécanisation et aux compétences requises pour les opérer. Les enquêtes montrent que les agriculteurs reconnaissent le confort et la productivité amenée par la mécanisation et sont loin de la contester.

En revanche, on oublie parfois que cette mécanisation a créé des emplois ailleurs. La chaîne de valeur de l'agriculture ne s'arrête bien sûr pas à la ferme ou à son code APE. Elle irrigue toute l'industrie de la transformation des produits agricoles, la logistique, la grande distribution, les restaurants sous toutes leurs formes... 

Taxer les robots voudrait dire dans le monde agricole taxer les tracteurs autonomes, les données et les logiciels.

Heureusement que personne n'y a pensé avant car cela ne ferait que rendre encore plus précaire l'équilibre des investissements en mécanisation des agriculteurs (qui portent déjà ce risque) et retarder d'autant la création d'emplois dans la fin de la chaîne (l'économie du pays).

Un État économiste et un tantinet visionnaire dirait au contraire qu'il faut aider l'automatisation comme on aide l'innovation dans les entreprises par exemple avec le Crédit Impôt Recherche.

Taxer les robots, c'est pourtant une proposition qui revient régulièrement dans le débat et qui a été supportée le week-end dernier par Bill Gates dans une interview au magazine Quartz. Les supporters de Benoit Hamon ont alors certainement pensé que l'heure était arrivée pour leur champion, mais c'était sans compter les réactions de tous les économistes de la planète cette semaine (par exemple James Bessen dans Fortune) qui ont rappelé au co-créateur de Microsoft qu'il s'était certainement un peu "égaré".

Comme on l'a vu dans le dernier billet sur l'Intelligence Artificielle, c'est une question que le Parlement européen demande à la Commission européenne d'explorer en demandant de fixer le régime légal des robots, mais la "taxe robot" n'est pas privilégiée par le Parlement. Espérons que dans le groupe de travail qui va s'emparer du sujet, il y aura des économistes et surtout des fils d'agriculteurs pour rappeler le bon sens paysan.