mercredi 19 avril 2017

Stratégie digitale : Flip your mind !

Stratégie digitale : Flip your mind !


En 2012, GreenSI publiait une série de billets intitulés "Transformers" pour illustrer avec l'image de ces voitures robots (autobots) le besoin de changement des DSI pour aborder le numérique qui était en train de "digivorer" les industries une par une.

Cinq ans plus tard, la transformation numérique est sous tous les projecteurs et dans toutes les conférences, et l'ubérisation est à l'agenda de tous les comités de direction. Ce sont cinq années qui ont vu dans beaucoup d'entreprises beaucoup plus de changements que les dix années précédentes.

Pourtant, pour avoir eu l'occasion récente de faire un point sur ces changements dans quelques entreprises, on mesure que la route à parcourir est encore longue, et même peut-être sans fin, que les questions sont multiples comme celle du rôle du CDO que l'on redécouvre maintenant comme le "Chief Transformation Officer", une transformation à l'échelle de l'entreprise.

Quand en 2012 les enjeux de l'internet étaient sur les plateformes clients et la consolidation de la présence en ligne des entreprises pour prospecter, vendre et assurer des services, en 2017 le champ de l'internet des objets étend cette relation clients toujours plus loin, et demain, la nature même de cette relation sera chamboulée par l'intelligence artificielle et la blockchain.

GreenSI considère donc que le sujet de la transformation n'est plus celui de la technologie mais celui des usages (Entreprise du futur arrêtons de parler de technologies) et surtout de la conduite de la transformation. La méthode et la capacité d'apprentissage prends le dessus sur la technologie.

Car la technologie émerge à une vitesse plus rapide que celle de son assimilation et encore plus que celle de son adoption. En revanche, la façon d'apréhender la technologie structure encore l'organisation des entreprises et c'est pour celà qu'il faut encore lui préter attention.
Pour GreenSI les entités de l'entreprise qui exploitent la technologie (donc au delà de la seule DSI) se répartissent trois catégories :
  • celles qui gèrent l'infrastructure interne, la sécurise et la connecte à une infrastructure externe gérée par d'autres (Cloud public, Broker, BYOD, API ouvertes ...). C'est généralement le rôle régalien de la DSI.
  • celles qui accompagnent les usages des services numériques internes (notamment le Collaboratif ) mais aussi externes (notamment l'usage des API de l'entreprises par des communautés de développeurs). Le sujet de cette "Direction de l'Efficacité et de l'Attractivité des Collaborateurs" mêlant DSI et DRH est exploré dans "N'est-il pas temps de rebooter l'empire DSI?"
  • enfin, celles qui numérisent les processus pour adapter l'entreprise au digital, des entités aux compétences hybrides (métiers, data et numérique) incluant une approche agile adaptée à ces nouveaux processus et à l'organisation du travail et de la logistique qui en découle. Ces nouveaux processus peuvent alors porter de nouvelles offres de l'entreprise dans cette économie numérique.

La prise de conscience du digital est donc maintenant acquise

En 2012, les difficultés que l'on pouvait rencontrer entre les Directions métiers et la DSI commençaient ; quand seule la Direction métier prenait conscience du besoin de transformation, et que la DSI gardait son fonctionnement traditionnel. Elle gardait sa trajectoire souvent par déni de l'émergence de quelque chose de nouveau (l'internet, le Cloud et même l'iPhone on tous été considérés comme des "aberrations" par les DSI - et leur conseils - quand ils sont apparus.).

D'ailleurs, le déni (après l'ignorance) est la première étape de résistance de toutes les démarches de conduite des changements. Elle montre que le processus de changement a bien commencé. Mais en 2017, qui peut encore affirmer que la transformation digitale de l'économie est une mode qui va passer ? Bien sûr personne ne se retranchera derrière ces arguments.

Mais alors est-elle réellement assimilée ?

Qu'est-ce qui freine encore les projets de transformation numérique en 2017 ? GreenSI en a une petite idée et vos commentaires et nos échanges sur les réseaux sociaux la compléteront. L'hypothèse principale est: Nous sommes entrés dans une phase où nous cherchons à agir à l'ère du digital mais nous pensons encore comme à l'ère précédente.

Et c'est bien souvent sans s'en rendre compte. Parfois malgré un processus de changement engagé, nous ne nous sommes pas encore assez convaincus au fond de nous-mêmes que ce changement est irréversible.


Ce dernier cas, facile à repérer, n'est pas celui qui intéresse le plus GreenSI.
C'est par exemple quand quelqu'un qui n'a jamais fait d'agile vous explique que l'agile ne doit pas être une échappatoire aux projets au forfait et qu'il vous à déjà planifié sur 3 mois ce qu'il y aura dans chaque sprint et vous demande même de piloter selon un découpage arbitraire ignorant le retour clients. 

C'est aussi quand quelqu'un vous explique qu'il n'y a pas de problème pour utiliser le Cloud mais qu'il veut avant en définir les normes et standard.

De vaincre ces resistances au changement qui viennent plus des personnes qui ne se jettent pas à l'eau, que de la démarche collective de transformation, prendra certainement un peu de temps, mais pour GreenSI ce n'est pas le frein principal.

Flip your mind !

Ce qui intéresse GreenSI c'est quand les règles ont changé et qu'il faut penser différemment. Faisons un test pour vous en convaincre.

Pourquoi les gouttes d'eau de l'image ci-dessous vont du haut vers le bas? Et pourquoi les chiffres défilent aussi du haut vers le bas ? Ne passez pas tout de suite à la suite du billet.




Dans le monde de Newton, c'est la gravité qui régit ce mouvement. Et les distributeurs d'eau en profitent pour faire circuler l'eau dans les réseaux sans trop d'effort. C'est un monde où les méthodes locales du monde de la construction se sont imposées à l'informatique (Maîtrise d'oeuvre, maîtrise d'ouvrage,  recette, cycle en V, ...) et cette informatique s'est développée en dehors des métiers (paradigme de la DSI autonome). La conduite des changements est le moyen de déployer ces constructions relativement figées pour que les utilisateurs les adoptent.

Dans le monde numérique (celui de la matrice mise en avant par le film Matrix), les chiffres défilent du haut vers le bas, parce que les développeurs l'ont décidé ! Ils auraient pu programmer de les faire remonter de bas en haut ou aller de gauche à droite. La conduite des changements est remplacée par l'Agilité, cette habilité de créer et de répondre au changement dans le but d’avoir du succès dans un environnement fortement évolutif.

Le monde numérique se manipule donc comme on le souhaite.
Il se construit collaborativement sur des plateformes interconnectées au niveau mondial.

Les développeurs sont les magiciens dont l'entreprise a besoin pour enfreindre les règles du monde physique, car on n'est plus soumis aux règles de la construction et de la gravité mais à celles de l'agilité sous toutes ses formes, et dans toutes les directions. C'est le monde du minimum viable product (MVP), de l'expérience utilisateur (UX), des itérations et de l'amélioration continue (Lean), des plateformes qui amènent des économies d'échelles et un coût marginal, ...


GreenSI va donc rédiger une série de billets intitulée "Flip your Mind" dont l'objectif est de faire prendre conscience, à ceux qui n'en seraient pas déjà convaincus, que les règles du monde dans lequel dorénavant l'entreprise est en compétition et la collectivité opère, ont changé. 

Il faut en être totalement convaincu pour réellement adopter entièrement ce changement pour ensuite manipuler les règles et en prendre le contrôle.

Pour ceux qui ont vu le film Matrix, et la scène mythique des pilules, vous savez que le moment est venu d'explorer la matrice par vous-même : "Choisissez la pilule bleue et tout s'arrête. Après vous pourrez faire de beaux rêves et penser ce que vous voudrez. Choisissez la pilule rouge et vous resterez au pays des merveilles (numériques) et on descendra avec le lapin blanc au fond du gouffre".

Are you ready to flip your mind ?!

jeudi 13 avril 2017

L'État plateforme (numérique) se met en place

L'État plateforme (numérique) se met en place

Cette semaine, GreenSI explore les enjeux de l'ouverture par l'État de la plateforme nationale des données de référence.




C'est donc avec 9 jeux de données que le nouveau portail du service public de la donnée porté par Etalab a ouvert sur data.gouv. C'est la réalisation de la mission chargée de la politique Open Data de l’administration intégrée à la DSI de l’État (la DINSIC). Cette ouverture s'inscrit dans le cadre de la nouvelle dynamique de l'open data en France (et de la loi République Numérique) qui faisait l'objet du dernier billet de GreenSI.


Avec un oeil initié aux SI cette ouverture ressemble furieusement à un... MDM !

Le MDM est le fameux Master Data Management, au sein du système d'information, sur lequel toutes les autres applications peuvent s'appuyer pour projeter leurs propres données. L'enjeu d"une démarche MDM est de réduire les coût de maintenance par rapport à une gestion des référentiels dans une multitude d’applications distinctes et bien sûr aussi de réduire le risque d'incohérence et de multiplicité de définitions et de versions.
L'approche MDM se résume souvent par la phrase souvent entendue: "n'avoir qu'une seule version de la vérité".

Ce qui est intéressant dans le cas présent c'est qu'Etalab arrive à mettre en place une approche de type MDM pour organiser l'extérieur du SI (open data) alors que dans les entreprises l'approche sert d'abord pour gérer la cohérence en interne. La réduction des coûts et de l'incohérence portera donc ses fruits en externe chez ceux qui réutilisent ces données de référence. On peut cependant imaginer que les SI des ministères et des agences au sein de l'État vont aussi s'en emparer si elles utilisent aussi ces données.
D'autre part il est amusant (ou pas) de noter que ce qui relève du simple bon sens dans une architecture SI, voire d'un peu de gouvernance des données entre acteurs, conduit au niveau de l'État à définir par la Loi le côté "souverain" de ces données. Il s'agit certainement d'une autre exception bien française dans le monde de l'open data découvert par les anglo-saxons il y a plus de 15 ans.
Avec ce portail de données de référence, c'est donc une vision très architecturale de l'open data qui concrétise le concept d'État Plateforme numérique, et qui se met progressivement en place. On a une plateforme qui permet à tous d'interagir avec les services numériques de l'État et maintenant avec les données de référence gérées par l'État.

Ces neuf bases de données de référence sont des données qui sont utilisées au-delà des SI de l'État et du service public. Par exemple, la base adresse permet de géo-référencer toute adresse, donc de la positionner sur une carte, un besoin que l'on retrouve dans tous les secteurs et qui est essentiel depuis longtemps pour tous les acteurs de ville par exemple. Quand on regarde les statistiques d'utilisation des données sur data.gouv, la base Sirene ou des associations, maintenant devenues des données de référence, figurent dans les jeux de données les plus consultés.


Avec ce type de plateforme, on va certainement voir émerger de nouvelles organisations pour gérer le cycle de vie de la donnée au sein d'un écosystème et d'en répartir les responsabilités entre les différents acteurs :
  • Les producteurs produisent la donnée de référence et documentent les métadonnées. Ce sont eux qui doivent prendre des engagements pour leur mise à jour, instruire les retours des utilisateurs : par exemple, l'INSEE pour les données Sirene des entreprises.
  • Les diffuseurs mettent à disposition les données avec un haut niveau de qualité et s’engagent sur la performance et la disponibilité. Etalab dans le cadre du portail open data national, mais de multiples diffuseurs existent aussi en région avec des portails locaux.
    Un rôle en rupture avec les approches plus centralisatrice habituelles et où le "réseau" (producteurs et reutilisateurs) doit s'animer via la valeur d'usage des données.
  • Enfin les utilisateurs ou réutilisateurs qui (ré)utilisent ces données de référence pour produire de nouveaux services et créer de la valeur économique et sociale. Avec leurs retours, ils participent à la montée en qualité des données (signalement des erreurs, propositions d’amélioration).
Ces bases permettent donc d'avoir une source de référence, que l'on espère pérenne et rapidement mise à jour par les administrations concernées. Cependant, à ce jour, toutes ces bases n'offrent pas encore d'API pour une utilisation simplifiée. Mais ce n'est pas le plus compliqué une fois que l'on a des données de qualité.



L'été dernier, Etalab avait déjà ouvert quatorze API, comme celle qui permet de rechercher et consulter les annonces de Marchés Publics (BOAMP) directement depuis une autre application ; ou comme le dispositif France Connect, qui permet aux internautes de s’identifier sur un service en ligne par l’intermédiaire d’un compte déjà existant (celui des impots.gouv.fr, ameli.fr…). Dans ce dernier cas, la plateforme Etalab assure un niveau de sécurité supplémentaire puisque c'est elle qui fait le lien avec les fournisseur d’identité et non l'application appelante.

La convergence du sujet open data avec celui des API est une évidence pour GreenSI depuis plusieurs années, il se concrétise au niveau national, entre autres, avec ces nouveaux portails.


Cependant, le chemin sera certainement long pour passer des 14 API plus 9 données de référence actuelles, aux centaines d'API que l'on peut estimer si on considère la place de l'État et de l'Administration dans tous domaines de l'économie française (et donc de facto des données qui s'échangent en amont ou en aval). Il faudra donc des compétences techniques nouvelles au niveau d'Etalab et de la DINSIC mais aussi dans chaque direction SI de chaque Ministère pour produire ces données directement depuis les SI, et exploiter le potentiel de cette architecture, sans s'arrêter au sujet réglementaire imposé par la Loi.

GreenSI fait le lien entre ces SI de l'État plus interconnectés et s'ouvrant sur un écosystème, un État qui doit s'adapter pour exploiter le numérique et ne pas se laisser distancer par une société qui s'en est emparé à tous les niveaux, et la gouvernance interministérielle qui se met en place en matière de filière RH des ingénieurs des systèmes d'information et de communication (ISIC) et qui a fait l'objet d'une circulaire le mois dernier.
À la clef, l'amélioration de l'attractivité de la filière des métiers du numérique au sein de l'État, la fluidification des parcours professionnels et bien sûr l'harmonisation des pratiques (notamment salariales) entre les ministères. Traduisez : ne nous piquons pas les talents entre nous ;-)



Car en terme d'attractivité 
des candidats externes talents du numérique l'État a encore du chemin à faire. On s'en rend compte quand on consulte l'annonce de l'ouverture de plusieurs postes de développeurs en CDD de 3 ans (sic!) pour rejoindre l’incubateur de l'État, et travailler sur les projets numériques qui doivent transformer les services de l'État (sinon, à quoi bon avoir un incubateur).

Ce cadre RH contraint empêche clairement de rivaliser avec les offres de startups qui embauchent immédiatement en CDI après une période d'essai de 3-6 mois et offrent en bonus des actions de la startup. Sans compter sur les entreprises qui se battent aussi pour avoir les meilleurs profils. Et c'est sans anticiper la pénurie de bons développeurs annoncée qui va s'accentuer sur Paris quand l'incubateur "Station F" aux mille startups sera totalement déployé dans le sud est parisien et aura aspiré tous les jeunes des prochaines promotions de la 42, Epitech, Epita et autres écoles du numériques environnantes.

En synthèse, l'ouverture des données est donc un formidable levier de transformation qui oblige à se poser les bonnes questions comme celle de l'architecture, des API, de l'urbanisation du SI, des rôles et responsabilités des acteurs et même de l'attractivité qu'il faut pour conserver les talents qui sauront tirer parti de ces plateformes.

Des sujets auxquels la filière SI de l'État s'attaque et que l'on retrouve également dans les DSI des entreprises privées où, à quelques exceptions, le cadre de la Loi République ne s'applique pas. Finalement l'architecture des SI n'a pas de frontière pour la circulation et la valorisation des données.

lundi 3 avril 2017

Opendata: nouveau départ!

Opendata: nouveau départ!

La conférence EFE "L'open data en pratique" le 23 mars a été l'occasion de rencontrer de nombreux acteurs de l'opendata en France, tous engagés dans des projets dans leur collectivité locale, mais bien souvent aussi ambassadeurs de l'open data au delà des limites de son territoire.

Ce fut une belle occasion de faire le point sur cette démarche open data qui est entrée dans la loi République Numérique par la grande porte en 2017, et qui n'attend plus que son dernier décret d'application pour que les 3800 collectivités (de plus 50 agents et plus de 3500 habitants) soient immédiatement concernées par son déploiement.

L’ouverture des données publiques est donc désormais une obligation. Pourtant, comme l'a présenté Olivier Deviller, conférencier sur la transformation numérique qui a travaillé en collectivités, et animateur de la journée, la question n'est pas une contrainte réglementaire de plus mais bien un levier du changement pour favoriser l'innovation dans les collectivités locales, et plus largement dans tout l'écosystème de la future Smart City. 

Pour cela il va falloir quitter le monde limité des premiers "ambassadeurs", qui a caractérisé la période de ces 7 dernières années, (les premières ouvertures comme Rennes ou Bordeaux datent de 2010-2011), et trouver le moteur à allumer pour aller vers l'appropriation la plus large possible.

Dans un contexte financier restreint, l’open data est donc clairement un levier d’optimisation des politiques publiques, de développement de l’innovation et pourquoi pas du territoire (numérique) pour les plus audacieux.

L'Occitanie, la nouvelle région qui rassemble en autres Toulouse et Montpellier, est certainement l'un des barycentres français de ces territoires qui veulent utiliser l'open data pour dynamiser leurs actions. Sandrine Mathon, chef du service Administration de la Direction du Numérique (ex DSI) de Toulouse Métropole, responsable de l'ouverture des données de la Métropole et membre active de l'association Open Data France, a rappelé les fondamentaux derrière l'open data.

Un business modèle qui reste à trouver

Les données publiques concernées sont les données que la collectivité collecte et utilise pour ses missions de services publics et qu'elle ouvre ensuite publiquement pour le bénéfices de tiers, internes (les agents des autres services) ou externes (entreprises, startups, grand public...), avec des formats facilement ré-exploitables.

Les limites fixées à cette ouverture sont celles des données personnelles (régies par la CNIL), et celles des données sensibles sur le plan de sécurité (OIV, Loi de Programmation Militaire...).

Les collectivités qui confient des missions à des prestataires externes (PS) ou délèguent leur services (DSP) ont commencé l'insertion de clauses dans les marchés publics pour collecter les données relatives à ces missions au fil de l'eau, et pas uniquement en fin de contrats (qui sont souvent de plusieurs années). La nouvelle loi viendra les aider en modifiant également les règlements des codes qui s'appliquent à ces contrats.
Mais dans les 3800 collectivités concernées par l'opendata, la très grande majorité regroupent entre 15.000 et 20.000 habitants. Elles n'ont donc pas les moyens d'une grande Métropole. Pour GreenSI, il est donc évident que seule la mutualisation et les économies d'échelles permettront d'amener ce service de la donnée sur tous les territoires.
L'autre difficulté qu'il faudra lever, c'est de répondre au "business modèle" du financement des coûts du service avec des moyens complémentaires.
Pour GreenSI, il est en effet illusoire de penser que le service sera "gratuit" puisque les données, même si elles sont déjà collectées et utilisées, devront être nettoyées, anonymisées (contraintes CNIL, LPM, ...) et exposées avec un niveau de service et de disponibilité suffisant pour qu'elles soient réutilisées.

Tout ceci a donc un coût : serveurs, stockage, supervision... qu'il faudra bien financer soit directement (vendre l'accès au service open data), soit indirectement (utiliser les ressources de la collectivité donc réaffecter des impôts)
Or, la loi Valter a fixé la gratuité des données publiques et la nouvelle loi a confirmé les licences de réutilisation à titre gratuit qui seront fixées par un décret qui n'est pas encore publié (ODBL, License ouverte et CCBY devraient être confirmées). Une équation qu'il reste donc à résoudre avant d'allumer le moteur pour passer à l'échelle...

Au niveau national le décret du 14 mars met en place le service public de la donnée (nationale) pour les données de références (base SIRENE des entreprises, répertoire des associations, bases RGE de l'IGN, Organisation administrative...). Sa mise en oeuvre demande aussi un haut niveau de disponibilité, de sécurité et de fiabilité qui conduit naturellement à l'ouverture d'API. Les entités productrices de ces données vont donc également devoir leur allouer des moyens supplémentaires à cette mise à disposition, mais elles en ont certainement plus les moyens que les collectivités de moins de 15.000 habitants.

Les ingrédients législatifs sont en train de s'assembler  pour passer à l'échelle, mais le plus dur reste à faire : accompagner le changement à cette échelle, en interne mais aussi en externe.

La conduite des changements pour passer à l'échelle

Pour cela, Romain Lalanne de la Direction Digitale de la SNCF qui a piloté l'ouverture de l'API SNCF (ouverte en déc. 2015), riche aujourd'hui de 88 jeux de données  (sur data.sncf.com - horaires, régularité, comptage voyageurs, incidents) s'est appuyé sur un écosystème digital le plus large possible : développeurs, sociétés de services, startups de la Frenchtech...

L'open data conduit à créer et animer la communauté des réutilisateurs. Sinon, les données ouvertes resteront sans usages à dormir sur les serveurs.

L'ouverture d'API, par rapport à des fichiers XLS ou CSV, prépare l'avenir quand les robots dans les gares ou les chatbots dans les messageries instantanées voudront eux aussi connaître les horaires pour renseigner les usagers avec qui ils sont en contact. Le choix de SNCF est de proposer son API gratuitement jusqu'à 150.000 requêtes par mois, puis de tarifer le service quelles que soient les données demandées (et donc de son coût de mise à disposition). Un modèle lissé qui permet une plus grande lisibilité.

Parmi les autres retours d'expériences de collectivités qui ont lancé un projet de portail open data, on trouve la Métropole Européenne de Lille qui reconnaît être partie parce que toutes les autres grandes métropoles avaient déjà lancé un portail. Pourtant, faut-il ne pas ouvrir tant que les données ne sont pas parfaites ? Et bien non justement !

L'ouverture a permis d'exposer les données et de corriger les erreurs en travaillant directement avec les producteurs. L'ouverture n'est que la partie émergée de l'iceberg, une étape vers une animation autour des données du territoire en commençant par les producteurs et en allant vers les réutilisateurs.

L'implication de tous les acteurs

Autre témoignage, celui de David Poncet, responsable Open Data de l'Agglomération de Saint Malo qui a mis en place une démarche systématique de scoring (faisabilité politique, technique et juridique) des données de la collectivité pour évaluer leur potentiel d'ouverture. Un scoring auquel GreenSI ajoute bien sûr l'usage et l'attente de la donnée par une écosystème, même si ce n'est pas toujours facile à évaluer et que cela peut cacher des surprises.

Par exemple, Saint malo a ouvert les menus des cantines municipales et déclenché le développement par un particulier d'une application citoyenne pour les partager ("Y'A D frites"). La rencontre avec ce ré-utilisateur et les différentes prestataires des cantines a permi de normaliser le format d'échnage de ces menus et de donner plus de rayonnement à l'application.

Une histoire parallèle à celle qui s'est passée à Toulouse Métropole avec l'application ("QuiDitMiam!") démontre que cet usage, promis partout où il y a des enfants avec un smartphone, a un bel avenir. Il se pose alors la question du rôle (ou pas) de la collectivité à soutenir le développement d'une application au-delà de son territoire, et pour la startup à trouver un modèle économique. C'est ce qu'a fait cette semaine QuiDitMiam en participant au salon Restau'Co pour y présenter une version nationale de son application.

La cantine scolaire en train de devenir le premier succès à grande échelle de l'open data ?!...
Autres surprises, le jeu de données le plus réutilisé à Saint Malo est celui de la position des bateaux pour le départ de la route du Rhum et au Département 92 (qui a reçu un trophée pour sa démarche open data), ce sont les photos libérées des archives de la planète du Musée Départemental Albert-Kahn

Ces données permettent de créer de nouveaux services dans le domaine des loisirs et de la culture.Au final, c'est donc bien par "test & learn" que les avancées sont les plus significatives. Le DGS et DGA doivent être impliqués en amont avant d'aller travailler avec les services pour l'ouverture de leurs données. On note que le processus s'accélère quand les élus s'impliquent, et qu'au final ce sont eux qui doivent trancher quand les services ne sont pas en phase pour ouvrir tel ou tel jeu de données. Le portage règlementaire était nécessaire mais il n'est pas suffisant.

L'open data comme ouverture du SI

C'est un diagnostic partagé par Yann Mareschal de Bordeaux Métropole qui a retracé l'historique des multiples démarches open data du territoire depuis 2010. Sans réduire l'engagement de chacun, l'heure d'une plus grande mutualisation au niveau régional est arrivée. De plus, si à l'avenir l'open data est un signe de vitalité de l'aménagement numérique du territoire, il s'inscrira dans une compétition entre grandes collectivités pour attirer les investissements.

Jusqu'à présent la motivation des convaincus a été essentielle pour faire avancer les projets. Mais pour passer à l'échelle il faudra convaincre à tous les niveaux. C'est donc avec un projet "Smart Data" fédérateur que Bordeaux Métropole s'attaque à cette nouvelle étape de rationalisation qui doit mobiliser en interne les élus, les métiers et bien sûr la DSI. L'open data est aussi vu comme un moyen de "garder la main sur l'architecture" du Systèmes d'Information et un formidable moteur pour les réorganiser.

Voici une idée que GreenSI ne peut pas renier : l'open data comme brique du SI et de la normalisation des données. C'est une condition qui n'était pas présente dans les projets et qui est certainement devenue nécessaire. Elle n'est bien sûr par suffisante et ce sont les nouveaux services/usages et leur succès qui resteront les critères de succès de la démarche. C'est une évidence que la DSI ne doit pas oublier quand elle n'est pas en prise directe avec les citoyens et/ou que son périmètre se limite aux SI internes de la collectivité.

Après la première vague des projets commencée en 2010, la période est donc propice aux retours d'expériences avant un nouveau départ de l'open data dès 2017, mais certainement plus en 2018 quand le calme sera revenu en France sur le front électoral pour remobiliser nos élus.

jeudi 30 mars 2017

Pas d'Internet des objets sans écosystème

Pas d'Internet des objets sans écosystème

Cette semaine, c'était l'effervescence à Paris pour les acteurs de l'Internet des Objets (IoT) avec à la fois l'IoTWorld et la conférence LPWAN. L'Internet des objets, cette infrastructure qui se développe sur l'internet mondial, se déploie dans l'entreprise et les collectivités locales pour des applications plus industrielles au cœur de la transformation numérique.


Dans ce contexte, GreenSI s'est penché sur les prévisions du cabinet IDC en matière d'IoT. Des prévisions très pertinentes sur plusieurs points, en tout cas plus originales que celles qui se contentent de projeter de façon linéaire l'internet actuel à l'échelle de 50 milliards d'objets.

Mais connaissez-vous le LP Wan, le Low-Power Wide Area Network ?

Dans un contexte d'entreprise numérique étendue, le WAN dépasse les murs de l'entreprise et parfois a besoin de se déployer là où il n'y a pas d'énergie pour alimenter les objets qui émettent des mesures permettant de numériser les processus. La disponibilité d'une place de parking dans la ville est facilement mesurable par un capteur dans la chaussée, mais celui-ci doit avoir de l'énergie pour émettre régulièrement son état et signaler que la place est disponible. 

C'est là que ces liaisons sans fil à faible consommation énergétique sont de plus en plus utilisées. Elles permettent de maîtriser la durée de vie des batteries dans les capteurs (durée de vie de 20 ans nécessaire dans certains cas!)

Cela concerne bien sûr les villes et les collectivités locales qui gèrent leur aménagement, mais aussi les entreprises pour tracker les processus de bout à bout, notamment dans la logistique ou le suivi de chantiers.

Pour l'OVUM dans une récente étude, le LPWAN, longtemps réservé aux distributeurs d'eau ou de gaz (l'electricité utilise son propre réseau électrique) devient une tendance forte dès 2017.  Ses usages vont se multiplier, mais aussi ses technologies avec l'arrivée du NB-IoT (à bande étroite IoT) et du LTE-M (Long Term Evolution pour machines).

C'est donc cette semaine que GRDF, SUEZ, Sagemcom et une trentaine d'autres acteurs, historiques ou startups, ont choisi pour annoncer leur alliance: l'Alliance WIZE. Ils ont rappelé au marché que leur technologie éprouvée depuis plus de 10 ans fait l'objet de milliards d'investissements (à comparer aux 150 millions d'euros levés récemment par Sigfox), et se déploie massivement sur les territoires pour télérelever les compteurs d'eau et de gaz.
Alors pourquoi ne pas réutiliser cette infrastructure, dont la fréquence est normalisée et la qualité de service est connue, pour d'autres usages ?



Libérée au niveau de l’Europe à l’aube des années 2000, la fréquence 169 MHz utilisée par ces opérateurs, largement intégrée par les fabricants de semi-conducteurs dans des composants radio de faibles coûts, offreune portée de plusieurs kilomètres en champ libre. Elle permet aussi des débits compris entre 2400 et 6400 bits/s, qui permettent d’échanger des télégrammes de plusieurs dizaines d’octets.

Le réseau n'est bien sûr qu'une partie de la solution pour assurer les nouveaux usages, mais ses caractéristiques physiques, comme le besoin en énergie ou le fait que les communications soient bi-directionnelles, en font un élément de choix essentiel. Il est donc vraisemblable que l'avenir sera fait de plusieurs réseaux, dont la fidèle 3G/4G (et dans 3 ans 5G), mais aussi d'autres réseaux longue portée (WIZE, Sigfox, LoRa,...), qui seront choisis en fonction des usages.

C'est finalement plutôt une bonne nouvelle pour les DSI soucieux de la pérennité de leurs investissements de pouvoir faire ce choix.
Sigfox, très présent dans les médias, pouvait nous laisser croire qu'il n'y aurait qu'un seul réseau IoT qui traiterait tous les usages. Il n'en est rien. Sigfox est par exemple vu par l'analyste IDC principalement pour les applications non critiques, pour une partie relativement faible de l'ensemble des applications.


La ville et les infrastructures ne sont d'ailleurs pas le seul usage de l'IoT.


Pour IDC, en 2017, les véhicules connectés, les objets pour le bien-être personnel et les bâtiments intelligents seront à l'honneur dans l'ensemble des régions du monde, et représentent $96 milliards en dépenses. Reprenons maintenant les principales prévisions d'IDC sur l'IoT dans les 3 prochaines années :
  • Le smartphone reliant en bluetooth les objets personnels par millions sera dominant pour le B2C - ou directement en WiFi - et n'aura pas besoin d'autre réseau. En revanche, pour le B2B la collecte sera facilitée par les réseaux étendus de faible puissance LPWAN.
  • D'ici 2018, l'enjeu pour les entreprises se situe dans la remontée d'informations, via des capteurs ou des mesures bien situées le long des processus opérationnels pour en améliorer l'efficacité.
  • Un besoin au départ principalement interne à l'entreprise. Mais d'ici 2018, le besoin d'une plateforme "Open Data" se fera sentir et structurera les choix et les architectures. Les entreprises ayant déjà investi dans des solutions de plate-forme IoT pour ses besoins internes devront alors les ouvrir sur leur écosystème ou se synchroniser avec ces nouvelles plateformes "Open Data".
  • A mesure que l'adoption de l'IOT croîtra dans les principaux secteurs de l'industrie, du gouvernement et des consommateurs, le besoin de confiance dans ces donnés fera que 20% de tous les déploiements d'IOT auront des services Blockchain activés pour assurer la traçabilité au sein d'écosystèmes.
  • De plus, au moins 40% des données créées par IoT seront stockées, traitées, analysées et mises en œuvre à proximité ou en bordure du réseau, donc dans l'architecture de ce réseau et non dans des plateformes centralisées.
  • Les fabricants d'équipement IoT devront également améliorer leurs sécurité et leur traitement de la confidentialité, qui actuellement est la faille principale de ces systèmes.
  • D'ici 2019, 40% des collectivités locales et régionales utiliseront l'IOT pour transformer les infrastructures (routes, lampadaires, réseaux...) en actifs au service de l'évolution des villes à l'ère du numérique (Smart City). La quantité de données produites en constante augmentation permettra de poursuivre des stratégies d'analyse en continu et d'apprentissage par la machine au lieu de programmer les règles et seuils de pilotage de la performance.
Pour GreenSI, cette perspective est pertinente sur plusieurs points :
  • le fait que l'IoT est bien une infrastructure partagée par des écosystèmes, avec sa propre architecture, qui va se mettre en place progressivement avec ses standards, et non la vision d'un seul opérateur de bout en bout,
  • dans cette architecture la blockchain, autre technologie structurelle pleinement opérationnelle vers 2020, trouve bien sa place pour gérer des transactions au sein des écosystèmes qui vont se développer sur l'IoT. D'autres services se développeront au sein de cette architecture.
  • l'apprentissage se fera en interne dans chaque entreprise mais c'est bien la perspective externe et l'ouverture qu'il faut viser dès le départ pour éviter de remettre en cause ses investissements,
  • enfin, en B2Bn la sécurité est un élément essentiel à intégrer tout au long de la chaîne, ce qui est loin d'être le cas des déploiements B2C actuels (voir: les objets connectés sont des passoires).
Pour McKinsey, dans son étude sur l'impact de l'IoT sur les différentes industries, le potentiel de création de valeur de ces écosystèmes à l'horizon de 2025 sera principalement dans les usines et les villes (compteurs intelligents, éclairage urbain, parkings, environnement,...). C'est donc certainement ces deux cas d'usages qui vont structurer fortement l'architecture et les infrastructures de l'IoT à ce même horizon.



Pour les SmartCities, la présentation il y a 10 jours de la vision du Grand-Dijon qui mobilise plus de 100 millions d'euros pour mettre en place une gestion centralisée de l'espace urbain, intégrant la signalisation, l'éclairage... complété par une démarche unique d'open data s'inscrit totalement dans ces tendances IoT. Elle est le signe de ce changement de braquet des projets de villes intelligentes et montre, si on en doutait, le savoir-faire français après les premières vagues de technologies des géants américains il y a 5-7 ans.

Dans ce contexte, l'écosystème de la nouvelle Alliance WIZE (169MHz), qui vise les collectivités et les industriels et qui utilisent des passerelles sécurisés installées sur des toits d’immeubles, est certainement une technologie qui assurera de façon perenne de multiples usages aux côtés des autres réseaux déjà existants.

Sans aucun doute l'avenir sera celui des écosystèmes et de l'interopérabilité.

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.