-->
Archive for septembre 2017
L'intelligence artificielle fait en ce moment l'objet de toutes les interrogations et d'un buzz énorme dans les médias. L'écart entre les annonces et la réalité du quotidien, voire des possibilités actuelles, laissent en effet perplexe.
Quand dans la majorité des entreprises les applications opérationnelles
les plus avancées pour l'analyse des données utilisent de simples
modélisations sur des domaines limités, l'actualité se pose la question
de qui sera maître du monde par l'analyse de données ; ainsi que de
quand va démarrer la prochaine guerre mondiale dirigée par une
intelligence artificielle.
Cette actualité, souvent confuse, est entretenue par les propos de quelques entrepreneurs de talents comme Elon Musk ou Mark Zuckerberg et surtout par des prises de positions publiques de dirigeants du Monde comme Vladimir Poutine ou par le Royaume-Uni qui décide cette semaine de bannir les armes autonomes qui seraient pilotées par une IA.
Mais
au milieu de ce brouhaha, les GAFAs continuent de pousser leurs pions -
avec le support de startups qui rejoignent leurs "labs" comme à la Station-F (Microsoft) ou à Montréal (Facebook) - lancent
des fonds en centaines de millions de dollars, et rachètent des
sociétés mais surtout leurs équipes, car le recrutement de talents est
de plus en plus compliqué.
Au-delà des questions
d'éthique et d'enjeux stratégiques nationaux, d'ailleurs relevés par la
France avec une (nouvelle) mission #FranceIA, il n'y a pas de
doute que son développement aura un impact sociétal majeur. Ce sera
également une rupture clivante dans les entreprises. Il est donc également temps de commencer à prendre en compte ce sujet dans les stratégies d'entreprises.
L'avis du cabinet Gartner avec son classique "hype cycle" sur la "data science" et le "machine learning" nous rappelle que, concrètement, seules
l'analyse automatique de photos et vidéos, les techniques
d'apprentissage par catégorisation, et la modélisation sont aujourd'hui
opérationnelles (pastilles blanches dans la partie droite de
la courbe). Ceci qui mènera prochainement à l'analyse de texte, du
langage et à la simulation (bleu à droite de la courbe).
C'est une analyse qui tendrait à mettre les projets d'assistants autonomes dans la relation client ("chatbots"), classification automatique de données, d'amélioration des processus par l'analyse d'images ou de vidéos, et l'émergence de centre de pilotage intelligents, dans la catégorie des idées à explorer dès maintenant.
Elle
nous confirme également le nombre de sujets au plus haut sur le pic des
espoirs (ou angoisses) les plus fous, comme le "deep learning" quand le
programme (et la machine à travers lui) ira au-delà de l'apprentissage
assisté. C'est AlphaGo, le programme de Google arrêté cette année, qui
a rendu célèbre ces techniques en battant le champion du monde 4
parties contre 1. Depuis, en Corée du Sud, les clubs de Go s'inspirent
de la nouvelle façon de jouer d'AlphaGo sur ces 4 parties "uniques" pour
renouveler les stratégies humaines et les manuels du jeu de Go.
Au delà du buzz, l'IA est donc suffisamment mature pour rentrer dans les applications de l'entreprise.
Mais qui doit piloter ces initiatives dans l'entreprise ?
L'IA est un sujet amenant une rupture forte, avec un impact social engageant nécessairement la responsabilité de l’entreprise donc de son représentant au plus haut niveau.
On
n'imagine pas, par exemple, l'acceptation des dossiers de crédit d'un
conseiller virtuel autonome à base d'IA, en lien téléphonique directe
avec les demandeurs, sans que la Direction de la Banque ne soit
totalement au fait de ce service.
Pour GreenSI l’IA a donc vocation à être pilotée, au plus haut de l’entreprise.
Est-ce pour autant nécessaire de nommer un « Vice Président IA » ?
À titre provisoire, comme pour le Chief Digital Officer, ce peut être un moyen d'envoyer un signal fort dans l'entreprise sur les enjeux stratégiques associés à l'IA, et de coordonner les réponses de toutes les Directions Fonctionnelles avec un appui en amont :
- de la Direction de l’innovation pour tester le nouveau paradigme amené par
cette rupture, avant d'engager des projets structurés. Ce peut être dans le cadre d’un projet piloté par un Lab
interne ou dans un écosystème open-innovation d’acteurs dans l’industrie.
- de la "communauté data"
de ceux qui manipulent déjà les données dans l'entreprise, voire font
de la data science. Elle lui sera un autre appui majeur pour faire le
lien entre les nouvelles méthodes de l'IA et les cas métiers, donc la
capacité à transformer l'entreprise et les modèles économiques.
A
terme comme on est bien dans un processus de transformation. L'IA
impactera tous les processus de l'entreprise qui sauront générer des
données en masse pour alimenter les algorithmes. C'est là que
l'internet des objets va jouer un rôle de plus en plus fort pour
générer ces données (issues de photos, vidéos, capteurs, ...), en masse,
permettant d'optimiser ou de réinventer tous les processus de
l'entreprise.
La société SAP, au cœur des ERP, qui outillent nombreux de ces processus, ne s'y est pas trompée et propose déjà "SAP IoT Solutions"
de nouveaux processus dans la chaîne logistique digitale, mais
également dans ses verticaux industries, exploitant la collecte massive
de données IoT et avec SAP Leonardo le "machine learning". Unit4 avec Wanda, Oracle Applications et Sage sont aussi dans la course au chatbot pour interagir avec l'ERP.
À l'image de l'ERP qui se transforme, ce sont donc tous les processus de l'entreprise qui vont potentiellement se transformer et cela va également transformer le système d'information de l'entreprise au sens large.
La DSI est-elle légitime pour mener cette bataille ?
L'IA
et son "compagnon IoT" qui l'alimente vont être de bons révélateurs de
la transformation de la DSI sur ces dernières années.
Si
la DSI mène déjà la transformation numérique et qu'elle s'est orientée
vers le business et vers l'agilité demandée par les secteurs les plus
compétitifs de l'entreprise, elle est en bonne position pour accompagner
la bataille de l'IA. Ce sera une bataille qui va demander
une capture permanente de données en dehors des murs de l'entreprise (là
où elle n'est pas très à l'aise) et des services de traitement reposant
sur de la puissance de traitement à la demande (architecture data, IoT
et cloud).
Si la DSI n’a pas été - ou ne s’est pas -
impliquée sur les étapes des relations numériques et de maîtrise des
données, elle aura certainement peu de valeur ajoutée pour l’IA qui
arrive comme une étape de plus dans la transformation numérique des
entreprises.
Comme une partie contre AlphaGo qui a su
imaginer des coups jamais joués par les champions, une DSI trop
régalienne et trop "prévisible" a peu de chance d'accompagner son
entreprise dans cette prochaine bataille qui va demander de jouer des
coups non répertoriés dans les manuels de gouvernance et de protection
de la propriété intellectuelle et dans la liste des fournisseurs
référencés .
L'IA nous ramène donc à une réalité connue depuis bien longtemps, le SI sert en premier le business, la donnée en est devenue la principale marchandise.
C'est généralement à la rentrée que les projets SI se décident. Ils préparent les budgets d'investissements 2018 et vont influencer les futurs coûts d'exploitation à la hausse (nouvelles applications) ou à la baisse (rationalisation, dé-commissionnement...).
C'est donc la bonne période pour se poser la question des priorités et donner du sens à cette évolution du SI. Les développeurs agiles diraient qu'ils définissent le "sprint goal SI 2018", si un sprint d'un an reste encore dans le domaine de l'agilité ;-)
Par expérience, dans les organisations DSI qui sont plutôt conservatrices, ce sont souvent les projets de l'année, que l'on ne veut pas quitter, qui se perpétuent et occupent la majorité du temps de décision. Un projet technique qui dérape ou une conduite des changements métier sous-estimée, voilà deux raisons pour qu'un projet budgété sur 2017 se retrouve également en 2018 sans qu'on ne lui pose plus trop de questions sur ses finalités ou sur son ROI pourtant amputé par le coût du décalage.
En dehors du cadre d'un schéma directeur pluriannuel qui donnerait à l'avance les priorités, cette approche laisse parfois peu de place (et surtout peu de ressources) pour tester les nouveaux sujets comme par exemple l'Iot ou l'IA, deux infrastructures structurantes pour les applications de demain. GreenSI a donc toujours été favorable à "sanctuariser" à priori les budgets d'innovation (en pourcentage par exemple) pour éviter que les urgences du présent empêchent de préparer demain.
Mais ce n'est pas le seul problème d'avoir un présent... un peu trop présent. On en oublie également parfois le passé !
Ce que l'on a tendance à oublier dans cet exercice de budgétisation, ce sont les projets qui concernent les systèmes développés il y a quelque temps et qui n'ont pas été modifiés depuis; appelés souvent "legacy". Après tout ils ont fini par tomber en marche alors on n'y touche plus !
Pour GreenSI c'est une vision avec laquelle il faut être de plus en plus prudent, même si ce n'est pas très porteur auprès des métiers d'expliquer que l'on veut renforcer quelque chose qui pour eux n'est plus un sujet depuis longtemps. Et pourtant l'actualité nous montre que si.
En premier lieu à cause de la sécurité, comme nous l'ont rappelé en 2017 les attaques mondiales par "ransonware" Wanacrypt ou NotPetya.
Car ce "legacy" est peut-être stabilisé fonctionnellement mais il reste techniquement vulnérable en fonction de choix historiques qui ne pouvaient présager l'avenir des plateformes techniques et surtout de leur maintenance par les éditeurs, Microsoft dans le cas présent.
En second lieu quand ce legacy concerne l'ERP, une partie complexe à transformer au cœur de l'entreprise, car elle irrigue de nombreux métiers et processus. Or les risques de ruptures technologiques dans les stratégies des éditeurs augmentent actuellement, ce qui nous ramène au point précédent (le risque d'avoir une plateforme non maintenue). Mais on verra également que l'ERP aura un rôle à jouer dans l'efficacité de l'entreprise digitale qu'il pourrait hypothéquer.
Les cyber-attaques cherchent le maillon faible
Quand en mai 2017 les hôpitaux anglais NHS ont été bloqués plusieurs jours sans pouvoir gérer administrativement les patients, ou que deux semaines plus tard le site Renault de Sandouville a dû être mis à l'arrêt, c'est bien parce les SI de production utilisaient des composants techniques avec des portes dérobées ouvrant sur les milliers d'ordinateurs de l'entreprise. Ce n'était pas la première fois et ce ne sera pas la dernière fois, car l'étanchéité de ces systèmes ne sera jamais totale. Il vaut donc mieux considérer que ça va revenir et s'y préparer.
Comment? En ne laissant pas au hasard (et aux seules décisions métiers) la capacité à maintenir le socle technique des applications installées lors du lancement des systèmes. Ce socle technique devant être maintenu et mis à jour régulièrement, cela va relancer les projets de rationalisation par une réduction du nombre de technologies employées et surtout de ne garder que technologies maintenues par les éditeurs. Voilà donc déjà une idée pour 2018, certainement moins glamour que de connecter le CRM avec un chatbot, mais peut être plus rentable si les attaques reviennent...
Ceci remet donc sur le devant de la scène la capacité de l'entreprise à développer ses applications sur un socle technique commun, plus facile à sécuriser et à cloisonner,.. et non un socle technique par application, au grès des sous-traitances à tel ou tel fournisseur choisi pour être moins disant.
En y ajoutant un soupçon de "cloud", on peut également s'intéresser à créer une "Plateform as a Service"(PaaS), de préférence open source, pour éviter de dépendre du choix des éditeurs de stopper ou pas le support selon leur intérêt à ce que vous engagiez la migration sur une autre version.
L'ERP, socle back-office du monde digital
L'autre raison de regarder son legacy de près c'est de se préparer à une éventuelle mauvaise nouvelle du côté de votre ERP !
Avec la transformation numérique des organisations on aurait presque oublié que l'ERP, avec sa base de données unique pour toute l'entreprise et ses processus transverses, est le fondement de la stratégie SI et de l'efficacité des processus internes, fussent-ils back-office.
Or cette efficacité se révèle être un facteur clef dans la transformation numérique qui digitalise les processus et les étends au-delà de l'entreprise et au-delà des terminaux standards de l'entreprise.
Vous pensiez peut-être qu'Amazon n'était qu'un portail ? C'est surtout une machine logistique totalement automatisée, exploitant des robots dans ses entrepôts pour aider ses employés à tenir la cadence des commandes, et s'engager sur les délais jusqu'au point ultime de livraison de votre appartement au 13em sans ascenseur. La force d'Amazon est donc autant dans son front-office que dans la performance de son back-office à répondre aux engagements pris avec les clients.
On ne peut donc se résoudre à simplement garder son ERP "en l'état", parce qu'il est tombé en marche, sans se questionner sur son rôle à 3-5 ans quand les processus seront totalement numérisés.
Or l'ERP a quelques faiblesses potentielles dans ce nouveau paradigme, comme celui d'être fermé sur lui-même (par construction), de s'intégrer difficilement et de garder jalousement ses données.
C'est certainement un handicap pour pouvoir innover rapidement avec de nouveaux produits ou services numériques sans avoir à le faire évoluer. En effet, les projets ERP restent toujours très risqués (cf. Chaos report) et 1 projet sur 3 ne respecte pas ses délais, son budget ou ses fonctionnalités, s'il n'est pas arrêté avant.
D'autre part une étude CXP de 2014 montre que plus d'un ERP sur deux en France est âgé de 5 à 10 ans (54 %) et près d'un tiers (29 %) est installé depuis plus de 10 ans. Seules 16 % des installations datent de moins de deux ans. Les modules déployés le plus souvent étant la comptabilité et les achats, dans 73 % des cas chacun, puis la gestion commerciale (67 %), la gestion financière (51 %) et la gestion de production (43 %). Des sujets qui sont au cœur du fonctionnement de l'entreprise, même digitale.
Autre risque, les ruptures technologiques et la migration vers le Cloud demandent aux éditeurs des investissements importants pour faire évoluer leur progiciel. Une obligation que la concurrence des nouveaux entrants leur rappelle tous les jours. Les éditeurs avec une base installée plus faible, ou sans recapitalisation, risquent d'avoir du mal à financer cette bascule technologique en même temps que le passage vers un modèle à l'usage.
Deux exemples d'évolutions où l'ERP "traditionnel" est challengé :
- Le CRM est un module qui a déjà basculé du côté des domaines où plus d'une vente sur deux est en SaaS. Les éditeurs n'offrant pas de SaaS sont condamnés à court terme.
- Les objets connectés vont aussi permettre de rendre plus performant les processus avec plus de données pour les piloter, encore faut-il que ces données soient connues de l'ERP. L'ouverture de l'ERP, la création d'un écosystème autour de l'ERP sont deux sujets prioritaires à l'agenda des éditeurs qui proposeront demain les fonctionnalités les plus avancés.
Certains cabinets de conseil comme IDC vont même jusqu'à prédire l'arrivée d'une plateforme ERP post-digital (i-Erp, the new backbone for digital transformation).
En conclusion, que ce soit à cause de la sécurité de la plateforme technique, du risque d'obsolescence d'une solution éditeur ou des freins à automatiser des processus totalement numérisés depuis le smartphone du client, il y a certainement un intérêt à toujours regarder dans le rétroviseur si les systèmes d'hier suivent toujours.
Tous
ceux qui ont mis en place des projets agiles savent qu'ils vont se
heurter au frein de ceux qui n'adoptent pas cette démarche. Ceux qui
privilégient une approche d'étude globale avant toute réalisation ont du
mal à comprendre ceux qui avancent par itérations successives, validées
à chaque sprint par la satisfaction des clients ou des utilisateurs.
Dans ces multiples freins on trouve la sécurité, souvent mise en avant comme incompatible avec l'agilité.
En effet, comment arriver à faire homologuer avant la mise en service
la sécurité d'un système qui va être spécifié, construit, testé et mis
en production par morceaux ? La démarche de sécurité semble
difficilement compatible avec les projets agiles.
À tel point que
certains projets agiles ont certainement du avancer en dehors de
l'homologation fixée par la sécurité, sous couvert d'expérimentation ou
de priorité stratégique, pour tester de nouveaux services et sans mettre
en place dès le démarrage une sécurité disproportionnée avec les enjeux
du pilote engagé.
Entre deux enjeux majeurs - la transformation numérique et la cybersécurité - l'entreprise doit parfois choisir le plus important des deux pour assurer sa survie : la transformation numérique !
C'est elle qui va permettre de maintenir ses revenus dans cette
nouvelle économie incertaine, quitte à faire l'impasse dans un premier
temps sur la démarche sécurité, le temps d'assurer l'installation des
nouveaux services numériques, et y revenir ensuite une fois les premiers
objectifs atteints.
Alors comment réconcilier ces deux démarches sans que l'une ignore l'autre ?
Et bien cet été, c'est l'ANSSI, l'Agence Nationale de Sécurité des Systèmes d'Information créée en 2009, qui en a certainement surpris plus d'un en publiant une note en version bêta sur comment "Intégrer la sécurité numérique en démarche Agile ?".
Cette initiative est saluée par GreenSI via ce billet pour de nombreuses raisons.
Tout d'abord elle
démontre comment un organisme de gouvernance, au lieu de se cacher
derrière le caractère régalien de sa mission, reconnaît l'évolution
amenée par le digital et l'efficacité de l'agilité pour y répondre.
Ainsi,
elle fait avancer la réflexion et propose d'y répondre en conservant
l'objectif de sécurité à atteindre, mais en ouvrant un autre chemin pour
s'y rendre.
Cette démarche conforte tous les RSSI -
Responsable de la Sécurité des SI - qui ont déjà choisi de déchausser
leurs "bottes régaliennes" pour se mettre au service des métiers. Ces RSSI sont passés du contrôle au conseil et aident les métiers à mettre en oeuvre
les nouveaux systèmes souhaités au lieu de simplement en refuser les
dossiers de conception quand ils ne respectent pas les attendus, même
quand ces attendus sont discutables dans la nouvelle économie.
Ensuite, elle propose aux professionnels de l'informatique de consulter une version de ce document pour appel à commentaires. L'ANSSI propose
de confronter sa vision au retour d'expérience pratique de mise en
oeuvre dans les projets des entreprises publiques ou privées.
GreenSI trouve
cette co-construction ouverte très innovante et complémentaire des
travaux qui peuvent se tenir dans les commissions de groupes de DSI
comme le Cigref.
Enfin, la démarche proposée est simple et pragmatique.
Elle vise à répondre à une contrainte réglementaire d'homologation en
contournant l'approche traditionnelle. Pour cela elle s'inspire de
l'agilité, en adopte le fonctionnement, et adapte la démarche sécurité
pour intégrer ces projets construits de façon itérative avec des cycles
"Dev et Ops" qui s'enchaînent. La mécanique de comment intégrer cette
démarche dans les sprints et les activités de développement est très
bien détaillée. Globalement cela repose sur deux principes.
Le premier principe proposé est celui d'adapter le niveau de sécurité aux enjeux du projet.
Quand
un projet se construit de façon itérative, ce niveau de sécurité va
monter progressivement, mais surtout commence au bon niveau.
Si
votre premier sprint consiste à mettre en production une page blanche
avec inscrit dessus "Hello world!" (pour valider la chaîne de
construction par exemple), vous imaginez bien que même si un hackeur
s'empare de la page, l'impact pour l'entreprise est quasi nul et ce
système n'aura pas été connecté au reste du SI.
Dans le
paradigme classique de la sécurité, l'affichage de cette page (et donc
le test de la chaîne de bout en bout) n'aurait pu se faire qu'une fois
l'ensemble du système homologué et le système de sécurité complet des
serveurs mis en place... Même si finalement cette réponse sécuritaire
porte sur 99% de fonctions encore non développées !
A la clef, le time to market, car pendant que l'on étudie et on imagine
des solutions pour des problèmes qui ne sont pas encore posés, les
concurrents avancent et les startups innovent.
Le second principe est de traiter les risques de manière rigoureuse et itérative pour tendre vers l'exhaustivité.
C'est l'agilité adaptée à l'identification des risques ; mais en réajustant les objectifs de sécurité à chaque itération et
en intégrant les risques induits par les interactions entre composants
au fur et à mesure qu'ils sont présents ensemble dans le système. Les
fameuses 99% de fonctions non développées qui passent par la page "Hello
world!" n'induisent pas leurs contraintes à cette page tant qu'elles ne
sont pas développées.
Les premiers retours d'expérience des professionnels de la sécurité sur le site de consultation ouvert par la DINSIC montre une très bonne réception
à la fois de la démarche de co-construction de l'ANSSI, et de la
nouvelle démarche de sécurité agile. Beaucoup remercient également la
publication et la clarté du document d'accompagnement "Outils et bases de connaissance"qui pose les bases de la sécurité numérique.
GreenSI pense même que cette démarche peut renforcer la sécurité finale obtenue par rapport à une approche traditionnelle.
Non pas que l'analyse soit plus poussée, mais parce que les femmes et
les hommes de ces projets vont tout simplement collaborer et non
s'affronter quand l'approche régalienne instaure des hiérarchies de
pouvoirs.
- La démarche agile demande un niveau de
compréhension de la sécurité par les développeurs et l'équipe projet
plus élevé que dans la démarche classique ; donc demande plus de
dialogue entre développeurs et l'équipe sécurité.
- De
plus comme elle est itérative, à chaque itération ce dialogue va
permettre l'amélioration continue, et de revenir à la marge sur les
choix du sprint précédent. Les développeurs agiles font déjà cela pour
l'architecture logicielle avec le "code refactoring" qui consiste à
rendre générique au sprint suivant des parties du code qui avaient été
produites au départ pour un seul cas, sans changer les fonctionnalités
produites.
Sans aucun doute, c'est donc un processus à la fois beaucoup plus responsabilisant et très formateur à la sécurité pour les équipes projets qui
améliorera la sécurité des nouveaux systèmes produits de cette façon.
Bien sûr elle va demander plus de ressources aux équipes sécurité en
revenant régulièrement sur des dossiers qu'ils ont l'habitude de traiter
en une fois. Mais a priori c'est bien leur mission que d'améliorer la
sécurité globale des systèmes donc d'explorer toutes les méthodes pour y
arriver, et pas d'en imposer une à priori.
Cela n'est pas sans rappeler la démarche DevOps,
quand les Développeurs et les Opérations ont commencé à se parler et ne
plus se retrancher derrière les dogmes de chacun de ces métiers (comme
celui des évolutions du SI globales et par paliers).
L'agilité démontre une fois de plus sa capacité de transformation des organisations. Elle
est ici en train de transformer une interface de plus dans le processus
collaboratif de construction du logiciel, celle entre la conception et
la sécurité, car comme GreenSI aime bien l'écrire, l'agilité c'est dans toutes les directions.
Alors, allez vite contribuer et poster votre commentaire sur le document de l'ANSSI avant le 15 septembre. Dans 5 ans quand l'agilité sera devenue une évidence pour toute monde, vous pourrez dire "j'y ai contribué !".
Ne ratez pas non plus les "Assises de la sécurité 2017" qui auront lieu le mois prochain.
La conférence d'ouverture sera tenue par Guillaume Poupard, le Directeur Général de l'ANSSI qui "pitchait" cette semaine à l'université d'été du MEDEF pour
rappeler aux patrons d'entreprises que la sécurité était d'abord leur
sujet, avant d'être celui de leur RSSI.
Maintenant c'est au tour de ces RSSI de montrer
qu'ils savent répondre aux enjeux d'agilité du business.