Pages

mercredi 10 octobre 2018

Gouvernance des systemes d'information et utopie numérique

Par Christophe Legrenzi


Cet article a été écrit à l’occasion de la 10ème conférence internationale de la Gouvernance des Système d'Information qui a eu lieu à Lisbonne le 9 Octobre sur le thème : « Gouvernance des SI et stratégie des organisations », ainsi qu’au dixième anniversaire du Club Européen de la Gouvernance des SI qui a eu lieu le 23 octobre 2018 à Paris (http://www.acadys.com/wp-content/uploads/2018/10/Programme-d%C3%A9taill%C3%A9-10-ans-ceGSI.pdf) en la présence de Gilles Babinet, digital champion de la France auprès de la Commission Européenne, et de certains des meilleurs experts européens du sujet.




Les avancées technologiques n’ont en général pas ou peu apporté en pratique de bénéfices mesurables aux entreprises utilisatrices. Ce phénomène est appelé le « Paradoxe de Solow » du Prix Nobel d’économie 1987. D’un côté, le « producteur » : l’industrie informatique s’enrichit année après année, alors que le « consommateur » et/ou « l’utilisateur » de ces nouvelles technologies, nos organisations publiques et privées, ont le plus grand mal à créer de la valeur. Voilà le véritable défi de notre société !
Dans un article de recherche publié en 2015, édité à l’occasion du numéro 200 de VSE (Revue de l’Association des Docteurs en Economie et en Sciences de Gestion) et intitulé « Informatique, numérique et système d’information : définitions, périmètres, enjeux économiques », qui, étrangement, caracole en tête des articles les plus lus (cf. Cairns), nous avons résumé les 3 causes majeures empêchant aujourd’hui les entreprises de profiter pleinement des opportunités offertes par la ‘fausse’ « Révolution numérique », que nous préférons appeler plus justement : « Révolution informationnelle et des services ».
Ces 3 causes sont :
1. La méconnaissance des enjeux financiers liés au numérique et aux systèmes d’information (versus informatique) due à l’absence de définition clairement acceptée et aux limites des systèmes de gestion actuels
2. L’utopie (voire le fantasme) technologique couplée à l’homéostasie organisationnelle souvent véhiculée par l’industrie informatique laissant croire qu’il suffit d’adopter une nouvelle technologie pour en obtenir les bénéfices
3. Une gouvernance SI déficiente se traduisant par une absence d’implication de la direction générale ou un manque de courage managérial pour initier les changements qui s’imposent pour créer de la valeur.

1. La méconnaissance des enjeux financiers liés au numérique et aux SI et les limites des systèmes de gestion actuels
Les entreprises utilisent couramment le vocable ‘numérique’ en remplacement voire au détriment des termes ‘informatique’ et ‘système d’information’. Pourtant, nos décideurs préparent et valident encore et toujours des budgets informatiques…
Pour donner une perspective concrète, l’activité numérique pèse en moyenne 10 fois plus que l’informatique et deux fois moins que celle liée au système d’information. Les managers qui ont compris toute l’importance de ces nouveaux terrains de jeu, identifient des gains de productivité d’au minimum 10 à 30%. Etrangement, quasiment personne ne définit ce qu’est le numérique ou le système d’information, et encore moins le mesure, alors qu’il semble être l’enjeu principal de la transformation de nos organisations.
Déjà à l’époque, Philippe Lorino resituait parfaitement l’inadaptation des pratiques comptables : « Les outils aujourd’hui utilisés par le contrôle de gestion portent la marque de ces origines historiques. Ils reflètent le type d’environnement pour lequel ils ont été forgés, la grande industrie naissante de 1880-1910. Il n’est donc pas évident qu’ils soient adaptés aux besoins des entreprises de 1980-2010, à moins de soutenir l’hypothèse hardie selon laquelle l’industrie n’aurait guère changé depuis un siècle… Dans quel domaine de l’activité humaine peut-on prétendre travailler aujourd’hui, à l’aube du XXIème siècle, avec des outils et des méthodes développés à la fin du siècle dernier ? » (Lorino, 1991)
Ils sont d’autant plus inadaptés quand il s’agit d‘activités nouvelles comme l’informatique, le numérique ou les systèmes d’information.

2. Utopie technologique et homéostasie organisationnelle
Jean-Louis Peaucelle, mandaté par le Ministère de l’Education, a démontré dès le début des années 80 dans le cas de l’informatisation des fonctions comptables et financières des Universités françaises que les gains de productivité induits par l’introduction de l’outil informatique sont conditionnés par des changements organisationnels (Peaucelle, 1981). Pire, ne pas les engager entraîne inéluctablement une détérioration de la performance. Simon Caulkin le confirme : « … trop d’entreprises ont surimposé de nouvelles technologies sur des organisations anciennes en automatisant les problèmes et non les solutions » (Caulkin, 1989). Tout comme Lorino : « Le gain virtuel apporté par le progrès technique a été souvent neutralisé par la transformation trop lente des mentalités et des organisations » (Lorino, 1989).
Il y a déjà un quart de siècle, le rapport Fontaine cité notamment dans le rapport de Jean Le Garrec explique parfaitement le phénomène d’homéostasie organisationnelle couplé à l’utopie technologique : « L’informatique vient en quelque sorte se plaquer sur l’organisation existante, bien souvent déficiente. Elle ne fait alors que la rigidifier, devenant par là-même un obstacle à l’efficacité des services…/… l’informatisation s’est développée sans lien suffisant avec les réflexions sur l’évolution des structures administratives et de l’organisation du travail. L’informatique est restée ‘plaquée’ sur les schémas et les procédures existants » (Le Garrec, 1992).
David Norton identifie trois raisons qui empêchent les entreprises de retirer tous les bénéfices de leurs investissements dans les technologies de l’information (Norton, 1987) :
Nous avons été dirigés par une vision technologique
Nous n’avons pas su identifier les changements organisationnels
Nous ne possédons pas les outils nécessaires pour appréhender les bénéfices
En synthèse, cela fait maintenant plus de 30 ans que les meilleurs experts ont dénoncé le mythe de l’utopie technologique, sans pour autant qu’il soit systématiquement remis en question dans nos organisations.
3. Une gouvernance SI déficiente
De nombreuses études, déjà anciennes, ont montré que l’implication de la direction générale dans le processus d’informatisation était clé (Delone, 1988) tout comme leur niveau de compréhension des enjeux (FITI, 1986) et la qualité de leur relation avec le responsable informatique (Austin, 1988).
En 2004, les Professeurs Weill et Ross avaient démontré sur la base d’une étude mondiale menée sur 250 entreprises que la valeur générée par des projets à composante informatique était directement dépendante du niveau de maturité en gouvernance informatique (Weill & Ross, 2004). Ils soulignaient d’ailleurs que près de 62% des décideurs étaient incapables de définir précisément ce qu’était la gouvernance informatique. En dehors de l’ouvrage de 2006 de Gérard Balantzian « Le Plan de Gouvernance du SI » (Balantzian, 2006), on observe dans le microcosme franco-français une définition très endémique associant les référentiels internationaux de type : ITIL, ISO 27002 ou CMMI à la gouvernance informatique, en parfaite contradiction avec les définitions pourtant officielles que sont celles de l’ISACA/ITGI reprise dans COBIT et de l’ISO 38500. L’erreur est de confondre les « bonnes pratiques de gestion interne » qui représentent avant tout une vision « endogène » et celles de « gouvernance » dont l’orientation est principalement « exogène », tournée vers l’entreprise, ses métiers voire ses actionnaires et autres parties prenantes (Legrenzi, 2009).
En 2010, reprenant d’autres études publiées, nous avons pu confirmer que lors du processus d’informatisation ce n’est pas tant la qualité des solutions envisagées, mais bien le niveau de maturité en Gouvernance Informatique qui conditionne la performance d’entreprise (Legrenzi & Salzman, 2010).
Le professeur Almiro de Oliveira et Claude Salzman, fondateurs du Club européen de la gouvernance des systèmes d’information, affirment dans leur Manifeste : « Dans une économie quaternaire dominée par le secteur de l'information et de la connaissance, le management de l'information émerge comme un nouveau facteur de distinction et de différentiation, source d'avantages compétitifs tant pour les entreprises que les organisations publiques, dans un contexte de globalisation accélérée.../… Ainsi, la connaissance des coûts et de la valeur de l'information permet de prendre en compte la variété des problématiques de management de l'information et concourt aux Bonnes Pratiques de la Gouvernance des Systèmes d'Information » (De Oliveira & Salzman, 2009).
C’est bien la Direction Générale qui est responsable de la Gouvernance des Systèmes d’Information comme le confirment clairement les référentiels COBIT et de l’ISO 38500. Or, si elle ne s’implique pas dans le processus de transformation, il y a effectivement peu de chance que les décisions synonymes de création de valeur, soient prises.
Recommandation : la gouvernance des SI pour lutter contre l’anarchie et l’utopie technologique
Même s’il semble indispensable de gérer la fonction informatique, ce serait une erreur de s’arrêter là. La distinction entre pilotage informatique, numérique et du système d’information réconciliant les visions technicistes avec les enjeux métier est incontournable.
Une fois les enjeux clarifiés, il s’agit ensuite de replacer le pilotage et la gouvernance des systèmes d’information au cœur des débats. La gouvernance des SI est d’autant plus importante que le monde connaît la 2ème plus grande révolution économique de son histoire : la Révolution Informationnelle et des Services. Or, sans véritable gouvernance des SI, utopie technologique et anarchie conduiront inéluctablement nos belles entreprises à leur perte.
C’est à ce prix que les entreprises et les managers du futur réussiront leur projet de transformation, pérenniseront leur activité et gagneront en compétitivité.

mardi 18 septembre 2018

La Gouvernance des Systèmes d’Information et la création de valeur



Le 23 octobre 2018 le Club de la Gouvernance des Systèmes d'information organise pour son 10ème anniversaire une manifestation exceptionnelle pour faire le point les évolutions sur la gouvernance des systèmes d’information au cours de la décennie passée et d’esquisser les évolutions à venir.

Durant ces dix dernières années les Systèmes d’Information ont jouée un rôle croissant dans la création de valeur. Le succès des GAFA et les nombreuses autres « plateformes » en sont de parfaits exemple. Dans les années à venir il est probable que toutes les entreprises vont voir leur « business model » impacté par la transformation numérique.

En 4 heures faite le point avec les meilleurs experts du sujet. La participation à la conférence est gratuite.


Pour lire le programme de cette conférence cliquez ici
Pour en savoir plus notamment le contenu de chaque intervention lisez le programme détaillé. Pour cela cliquez ici


Pour s'inscrire à la Conférence du 23 Octobre 2018 cliquez sur : https://www.acadys.com/2018/09/21/10-ans-du-cegsi/

Pour tout renseignement complémentaire envoyez un mail à  ceGSI_10ans@acadys.com



mardi 27 mars 2018

Blockchain et levées de fonds en cryptomonnaies


L’émergence de monnaies virtuelles va-t-elle transformer l’environnement économique et financier mondial ?

Daniel Bretonès – Président de l’ANDESE


La cryptomonnaie bitcoin a été créée en 2008 et s’appuie sur la chaîne de blocs (la blockchain). Depuis cette date les achats de cryptomonnaies, à partir de devises fiat (le dollar et l’euros), principalement le bitcoin suivi par l’ethereum, se sont développées pour atteindre 7 milliards de dollars en janvier 2016, 130 milliards de dollars en septembre 2017 et près de 300 milliards en décembre 2017 (Source : Fortune).
Il faut distinguer le protocole bitcoin et le jeton numérique bitcoin ou BTC qui est soumis à de fortes tensions spéculatives. Le protocole bitcoin est une innovation de rupture basée sur l’assemblage d’éléments faisant appel à de la cryptographie, à la mise en réseau entre pairs et au minage par la preuve de travail. Il permet de réaliser des transactions dans un environnement sécurisé et fonctionnant de manière décentralisée.

Du caractère hybride des cryptomonnaies et du bitcoin plus spécifiquement 

Le bitcoin (le jeton bitcoin) serait plutôt une monnaie : il permet d’effectuer des transactions entre un nombre encore restreint de particuliers quelle que soit leur localisation, à l’exception de certains pays ou régions.
Le bitcoin constitue une réserve de valeur dans la mesure où il est rapidement convertible en une autre monnaie sur certaines plateformes spécialisées dans la convertibilité entre cryptomonnaies et monnaies Fiat
Les fluctuations du bitcoin sont énormes et sont le résultat d’anticipations spéculatives extrêmement fortes. (Voir tableau ci-dessous)

Source : Cryptocoin


Le Bitcoin ne répond pas aux définitions conventionnelles d’une monnaie

Une monnaie nationale se développe en contrepartie de toutes les transactions effectuées au quotidien. Le bitcoin ne peut pas actuellement être associé à la quasi-totalité des transactions sur le territoire national (PIB) et international. Aujourd’hui il ne représente qu’une infime partie de toutes les transactions mondiales.
Le bitcoin n’est pas sous le contrôle des autorités monétaires (les banques centrales) sauf si l’on considère la possibilité de changer la limite maximale du stock de bitcoin actuellement à 21 millions. Cependant ce type de décision est décentralisé au sein du réseau de mineurs (ce sont les informaticiens qui mettent en œuvre les transactions au sein de la chaîne de blocs), et les détenteurs des plus importants stocks de bitcoin au sein de ce réseau ont une voix prédominante. Le bitcoin n’est pas garanti ni géré comme la majorité des monnaies institutionnelles dans le cadre des actions des banques centrales. Le nombre de bitcoins en circulation (16 millions à ce jour) est trop faible pour agir les prix au sein de l’économie mondialisée.

La blockchain et les principales cryptomonnaies 

Le développement des cryptomonnaies est un phénomène sociétal lié au l’Internet et aux orientations libertariennes des fondateurs de la blockchain : des mathématiciens et des cryptographes en lien avec les universités américaines. Ces chercheurs se sont fait connaître sous le nom de Satoshi Nakamoto, fondateur du bitcoin, qui représente semblerait-il un groupe restreint de chercheurs dans les domaines évoqués. Le bitcoin a été créé par Satoshi Nakamoto en réaction à la crise financière de 2008 et au scandale international des prêts hypothécaires (les subprimes) qui a nécessité l’intervention des autorités monétaires lesquelles se sont substituées au marché interbancaire qui était bloqué. Le code source du protocole bitcoin a été mis en ligne en 2009. Les cryptomonnaies ne sont pas contrôlées par les autorités monétaires centrales qui observent le phénomène avec intérêt semble-t-il !
Près de 1.000 cryptomonnaies ont été créées depuis 2009 mais les plus connues sont le BTC, l’Ether et le Ripple. Le BTC est la référence centrale en termes de valorisation. Son cours soumis à des demandes excessives et spéculatives. En 2017 le BTC est monté jusqu’à 20.000 dollars à la fin 2017. Cet élan spéculatif est retombé et il s’échange au début février 2018 à moins de 8.000 dollars et à moins de 7.000 dollars le 6 février.
Le BTC a été limité par ses créateurs à 21 millions d’unités et l’offre actuelle est voisine de 16 millions de bitcoins. Le dernier BTC devrait être émis en 2140 si le réseau existe encore.
La force de la chaîne de blocs (la blockchain) tient à cinq attributs spécifiques et simultanés ;
-       Les transactions sont opérées par des mineurs (c’est-à-dire des informaticiens) qui s’appuient sur un logiciel afin de vérifier, de sécuriser et d’inscrire les transactions dans un registre qu’on appelle la « block chain ». L’entité de base du bitcoin s’appelle un bloc. Les blocs étant reliés en chaîne forment la blockchain. Le système constitue une base de données décentralisée sans autorité centrale.
-       La transmission se fait de pair à pair et non pas en passant par un nœud central. Chacun des nœuds stocke et transmet l’information à tous les autres nœuds.
-       Chaque nœud ou utilisateur de la chaîne est identifié par une chaîne alphanumérique de plus de 30 caractères. Chaque transaction est visible de tous. Les transactions s’effectuent entre les adresses de la blockchain.
-       Les enregistrements des transactions inscrites dans le registre ne sont pas modifiables car ils sont liés aux enregistrements précédents au sein de la chaîne.
-       Les transactions numériques au sein du registre sont informatisées.
Les acheteurs de BTC disposent d’un portefeuille électronique (le logiciel Wallet) comportant une adresse, une clé publique, et une clé privée. Le Wallet permet de créer des comptes, de construire et d’opérer des transactions. En cas de perte de la clé privée, l’accès au compte de l’utilisateur n’est plus possible sauf à disposer d’une copie de secours.

La gouvernance du système

La gouvernance du système s’effectue à deux niveaux
-       Le niveau 1 concerne les transactions opérées par les mineurs. Le BTC ne dépend d’aucune banque centrale et d’aucun état. Des protocoles cryptographiques de hachage de l’information et de preuve de travail sont intégrés à la Block Chain du bitcoin.
-       Le niveau 2 rend obligatoire les « contrats intelligents ». Ces derniers ont été lancés sur la plateforme Ethéreum qui propose une monnaie différente l’Ether. Ce deuxième niveau de gouvernance a été créé pour renforcer la sécurité des transactions. Les contrats intelligents permettent d’identifier précisément les intervenants en amont des transactions et de sécuriser ces dernières par l’élimination préalable des pirates (les hackers).
Les autorités bancaires et financières sont intervenues pour pousser à la mise en place des déclarations d’identité préalables à des transactions sur les plateformes de cryptomonnaies. Ceci afin d’éviter des détournements de fonds sur des plateformes nouvellement créées.

A la recherche de l’Eldorado

L’or et l’argent ont tenu un rôle moteur dans l’histoire du monde. Les mines d’argent de Potosi et de Zacatecas dans le Nouveau Monde ont largement participé au financement du « siglo de oro et des tercios des rois d’Espagne » du XVIème siècle. L’or brésilien a retardé la chute de l’empire portugais et le sterling d’or, produit avec le métal provenant surtout de la Guinée Equatoriale, a contribué à l’essor de la British Navy et de la puissance britannique qui a utilisé la Cavalerie de Saint Georges (l’or versé aux alliés) pour combattre Napoléon [1].
Aujourd’hui, si l’or continue de fasciner, c’est aussi dû à la politique d’assouplissement quantitatif du Federal Board Reserve qui est venu relayer ce mirage. Il a permis après la crise de 2008 d’éviter la déflation et à relancer l’économie américaine et puis l’économie européenne grâce aux interventions de la BCE.
Un écosystème est en train de se créer autour des principales cryptomonnaies avec le contrôle des transactions, la mise en place de contrats intelligents, et l’émergence de places de conversion de monnaies réalisées entre les principales cryptomonnaies (Ether et BTC) et les monnaies fiat (dollar et euro), et dans le sens inverse.
Le protocole Blockchain est étudié en détail par la Banque Centrale Européenne et, en France, par l’AMF. De grandes banques françaises et européennes testent des applications avec le protocole Block Chain pour sécuriser des transactions et pour, à terme, renforcer leurs positions concurrentielles.
Les applications de la blockchain et des bitcoins sont nombreuses dans l’industrie et la distribution ;
-       Kodak prévoit d’émettre des jetons (Kodak Coins) pour mieux gérer les droits des images,
-       KFC Canada prévoit l’utilisation des bitcoins pour payer de petits achats,
-       Le système électoral brésilien utilisera la blockchain Ethereum,
-       Samsung, qui est devenu le leader mondial des circuits intégrés devant Intel, développe des puces ASIC (Application Specific Integrated Circuit) pour le minage des transactions en cryptomonnaies. C’est un nouveau segment de marché qui s’ouvre alors que les ventes de téléphones mobiles et de tablettes sont stabilisées voire en baisse. Ces puces ASIC en développement devraient accélérer les transactions de minage et réduire la consommation énergétique de ces opérations,
-       Shell développe une blockchain pour optimiser ses opérations commerciales,
-       Le Chicago Board of Trade (CBOT) et le Groupe CME préparent le lancement de contrats à terme sur le bitcoin,
-       L’autorité des marchés de Singapour, qui est à la pointe sur les cryptomonnaies, reste ouverte à leur développement sous réserve de l’application de la loi anti-blanchiment pour les intermédiaires de ces transactions et prévient les investisseurs que les cryptomonnaies comportent des risques très élevés à intégrer dans leur stratégie d’investissement.

Les levées de fonds en cryptomonnaies (LFC) ou ICOs (Initial Coin Offerings)

L’écosystème des monnaies virtuelles est à l’initiative d’un nouveau type d’opérations, les levées de fonds en cryptomonnaies (LFC) ou Initial Coin Offerings (ICOs). Il repose sur l’émission des tokens ou jetons et la possibilité pour des particuliers d’investir en direct sur des projets à risque mais avec des niveaux de retour très élevés caractérisent les LFC. Plutôt que d’investir en capital dans une entreprise et de détenir des titres en contrepartie il s’agit d’investir dans des entreprises qui développent des services et / ou des produits via une chaîne de blocs. Dans le cadre d’une LFC on achète des jetons en BTC ou en éther à partir d’un compte tenu dans ces monnaies. Les jetons achetés permettent d’investir dans le cadre d’une ou de plusieurs levées de fonds spécifiques. La SEC américaine accepte les LFC sous réserve qu’elles soient conformes à ses règlements.
Ce mode de financement est également hybride entre le financement participatif et le capital-investissement dans son volet capital-risque. Il est le produit de la spécificité de l’actif numérique.
En juillet 2017 le montant mondial des LFC s’élevait à 2,3 milliards de dollars et il atteignait les 3 milliards de dollars en décembre 2017.

Face à un processus d’ubérisation du secteur du capital-risque 

Dans les années 1950, les approches de l’ARD (American Research & Development), à l’origine de la création du capital-risque sous l’impulsion de Georges Doriot, révolutionnent le monde de la finance. La mise en application du concept de capital-risque permet le développement de jeunes pousses sur la Côte Est puis sur la Côte Ouest des Etats-Unis et procure un avantage concurrentiel significatif à l’économie américaine dans les domaines de la haute technologie. De nos jours, des créateurs ingénieux qui ont du mal à trouver des fonds auprès de capital-investisseurs arrivent à lever des fonds dans le cadre d’opérations de LFC lancées au niveau mondial. Ils délivrent en contrepartie des jetons qui ne sont pas des titres mais des services au même titre que les miles aéronautiques obtenues par les voyageurs en achetant des billets qui permettent par accumulation d’obtenir des voyages ou services divers gratuitement.
Les LFC ne sont pas soumises aux audits approfondis pratiqués par les investisseurs en capital-risque et aux contrôles réglementaires mis en place par les autorités de tutelle. Le plus souvent l’intérêt du projet, ses fondamentaux et le profil de l’équipe qui lance la LFC sont consignés dans un livre blanc mis à disposition des investisseurs potentiels. Le niveau de risque est très élevé mais en cas de succès de l’opération basée sur le développement de l’entreprise les plus-values potentielles sont aussi très élevées. Le jeton détenu par l’investisseur est un service dont la valeur peut fluctuer fortement à la hausse ou à la baisse.
Selon le journal Wired certains capital-risqueurs américains auraient participé à des LFC. Il est clair que pour les projets de qualité bien calibrés le recours aux LFC est une voie parmi d’autres pour trouver des financements pour de jeunes pousses innovantes. Elles permettent à des intervenants privés d’investir en direct sur des projets à risque portés par des starts-up. Jusqu’à présent ce type d’opérations est réservée aux capital-risqueurs. On assiste bien à l’émergence d’une désintermédiation des capital-risqueurs.

Quelques prévisions à moyen terme

Ces outils constituent une évolution majeure dans l’histoire monétaire :
-       La blockchain un moyen puissant pour déployer des applications pour des entreprises financières et ou industrielles,
-       Il est à prévoir que les cryptomonnaies sous-tendues par des technologies décentralisées et fiabilisées se développeront et s’imposeront progressivement comme le réseau Internet basé sur le protocole HTTP ouvert, s’est substitué et a remplacé les réseaux privés qui s’appuyaient sur des protocoles fermés et non-ouverts,
-       Des levées de fonds par LFC pourraient être disruptives pour les capital-risqueurs (VC) et complémentaires des formes de financement pratiquées dans cette industrie.
Les gourous de la Silicon Valley ont annoncé depuis près de 20 ans l’arrivée du New Age porté entre autres par Internet. Depuis des secteurs entiers ont été remodelés et transformés dans les médias, dans l’hôtellerie, dans la réservation en ligne. Les monopoles acquis par les GAFA ont pris à découvert les décideurs français et européens qui n’avaient pas anticipé ce qui pouvait se produire. Des secteurs entiers de l’économie mondiale ont été redessinés et en général les entreprises françaises et européennes sont peu ou pas présentes dans ces nouvelles configurations.
Le protocole blockchain est une technologie jeune mais porteuse. Elle peut être améliorée en termes de vitesse de transaction et de sécurisation des opérations en amont de la chaîne de blocs proprement dite. Les LFC montrent le potentiel de ce qu’il est possible de réaliser en matière d’investissement direct à risque. Les LFC complètent les financements de type participatif et les financements d’amorçage proposés par les capital-risqueurs.
A ne voir que la face négative de la chaîne de blocs et des pratiques de type LFC, les entrepreneurs français pourraient être dissuadés de tester ces nouvelles approches. Il convient donc de communiquer de manière neutre voire positive sur le sujet tout en appréciant les limites du protocole Block Chain et ses applications dans la finance et l’industrie. Les cryptomonnaies constituent peut-être un moyen de rendre plus liquide l’économie et il serait dommageable de les condamner à priori alors qu’elles sont émergentes et en phase de consolidation.




[1] Or, Argent et Folies des Grandeurs, Giraudo A., Eds Economica, 158 p., 2017


dimanche 5 novembre 2017

Mettre en œuvre DevOps

La fin du Fordisme en informatique

 Par Alain Sacquet

DevOps est un mot à la mode. Malheureusement chacun a tendance à lui donner un sens différent souvent très loin de ce que ce concept recouvre réellement. Ce terme a été inventé par Patrick Debois en 2009 à Gand. Pour populariser cette démarche il a organisé des conférences : les devopsdays. Cette nouvelle approche du développement informatique a connu rapidement un réel succès, notamment Outre-Atlantique.
Malheureusement on ne sait toujours pas très bien ce que recouvre ce terme. Ainsi Jez Humble a constaté que les promoteurs de DevOps ont « toujours - intentionnellement - manqué de définition ou de manifeste ». Ceci est peut-être dû au fait Patrick Debois n’a jamais donné une définition de ce concept, pas plus qu’il n’a écrit un Manifeste comme ce fut le cas pour les Méthodes Agiles, ni produit un référentiel de la gestion de projet comme PMBok, Prince 2 ou CMMI. Il n’y a pas non plus cherché à établir un recueil de bonnes pratiques comme COBIT qui tend à ressembler à une lettre au Père Noël. Malgré cette absence de définition le terme s’est rapidement popularisé car il correspond à une réelle demande.
Différents promoteurs de DevOps se sont exercés, avec plus ou moins de bonheur, à rechercher une définition de cette notion. Ainsi le même Jez Humble a proposé comme définition : « DevOps est un mouvement regroupant des personnes soucieuses de développer et d'exploiter à grande échelle des systèmes fiables, sécurisés et performants. » Il a précisé que c’est : « une communauté de pratiques interdisciplinaires dédiée à l'étude de la construction, de l'évolution et de l'exploitation de systèmes résilients évoluant rapidement à grande échelle ». C’est intéressant mais c’est encore un peu imprécis. Gene Kim a été plus loin en affirmant : « nous considérons que DevOps est le résultat de l'application des principes du Lean au flux de valeur informatique ».

Tentative de définition de DevOps

En fait l’idée est de s’y prendre de manière différente par rapport à l’approche traditionnelle de l’informatique. C’est une manière disruptive de travailler. Dans ces conditions on peut définir la démarche DevOps comme une manière de construire un système permettant d’avoir ensuite des évolutions rapides et d’avoir un système résilient. L’idée clé de cette approche consiste à chercher à produire des évolutions en continu.
Cette approche consiste, selon Gene Kim, à appliquer à l’informatique des principes du Lean Manufacturing en travaillant la « value stream » afin d’améliorer de manière continue les systèmes d’information. Pour cela on va s’attacher à effectuer en continu des séries de changements ponctuels.

Analyse du problème

L’informatique fonctionne de manière traditionnelle en mode silo avec un mur séparant les Etudes et l’Exploitation. C’est le mur de la confusion. Ceci est dû au fait que les objectifs de ces deux unités sont très différents. Les équipes de développement sont orientées vers le changement alors que les équipes d’exploitation sont préoccupés par la stabilité des systèmes.
Le Mur de la confusion
Apparemment cette organisation et notamment l’existence des silos est incontournable. Ceci explique les nombreux incidents apparaissant lors de la mise en production d’une nouvelle application ou d’une nouvelle version d’une application ancienne. Ils se traduisent par des tensions, voir des conflits. Mais en réalité c’est une fausse opposition car elle est due aux choix d’organisation lié à l’existence de deux équipes différentes.
Pour éviter ces difficultés il est nécessaire de supprimer le mur de la confusion. Pour cela il est nécessaire de refondre l’approche classique allant de l’expression des besoins à la mise en œuvre de l’application opérationnelle.
Pour améliorer « l’IT value stream » la réponse de DevOps est de :
-       Faire changer l’état d’esprit des équipes informatiques en changeant leur culture,
-       Développer la communication en cherchant à court-circuiter la hiérarchie, si c’est nécessaire,
-       Concevoir des systèmes facilement déployables, facile à étendre en fonction des besoins des utilisateurs et simples à exploiter,
-       Mettre à la disposition des informaticiens, les outillages puissants et efficaces.  
La démarche est ce qu’on appelle dans le domaine du mangement le « time to value ». Pour cela on doit s’attacher à mettre sous contrôle l’ensemble de bout en bout des processus.

L’approche Lean

Cette première approche intéressante mais elle ne règle pas le problème. Pour y arriver il est nécessaire d’aller plus loin dans la démarche en la combinant avec une approche de type Lean (Pour en savoir plus sur l’approche Lean sur Wikipédia cliquez ici). Pour cela on va s’attacher aux points suivants :
-       S’attacher à créer de la valeur pour le client en identifiant précisément ce qu’il attend et ce qui représente de la valeur pour lui.
-       Lutter contre les activités inutiles. Pour cela on va analyser les étapes successives du processus qui aboutissent à la création du produit ou du service puis on va s’attacher à supprimer toutes les étapes qui ne créent pas de valeur. On ne doit garder que ce que le client est prêt à acheter,
-       Supprimer les gaspillages. Pour cela on va s’assurer que les étapes restantes s’enchaiîent de façon fluide, sans gaspillage, ni stock intermédiaire, avec l’objectif d’accélérer au maximum le temps d’exécution du processus complet.
-       Éliminer les fonctionnalités qui ne serviront à rien et que personne n’utilisera en demandant au client d’intervenir tout au long du processus, plutôt que d’engager les travaux de réalisation sur la base de prévisions faites au moment de la commande. On ne réalise que ce que le métier est prêt à signer.
-       Rechercher perpétuellement la perfection qui n’est atteinte que lorsque la valeur est fournie instantanément et sans gaspillage. Il faut pour cela travailler à flux tiré.
C’est la réalisation effective de la promesse faite par le DevOps. Cela représente un changement profond des méthodes de travail traditionnelle. Pour apprécier l’importance de ces changements un exemple permettra de mieux comprendre leur importance.

Un exemple troublant

Imaginer un travail consistant à effectuer dix fois trois opérations successives simples consistant à réaliser un dessin sur une feuille de papier, puis la plier et enfin mettre sous enveloppe cette feuille. Deux solutions sont possibles :
-       Effectuer d’abord les dix dessins, puis faire les dix pliages et enfin mettre sous enveloppe les dix pages,
-       Faire un premier dessin, le plier et le mettre sous enveloppe puis ensuite faire un deuxième dessin, le plier et les mettre sous enveloppe et ainsi de suite.

Question simple : quelle est la solution la plus productive ?

La plupart des personnes pensent que la première solution est la meilleure grâce à la division du travail mais l’expérience montre qu’en fait la seconde est plus productive que la première. La raison est que la solution de type Lean est plus efficace car on supprime les stocks intermédiaires. De plus cette démarche facilite les changements en cours de production.

Cet exemple d’une très grande simplicité est troublant car toute la théorie managériale repose sur des concepts comme la division du travail, le taylorisme, … et cela nous induit en erreur

« La théorie c’est quand on a tout compris mais que rien ne marche. La pratique c’est quand tout marche mais on ne sait pas pourquoi »
                                                                                              Albert Einstein

Or justement l’expérience montre qu’en traitant une à une les trois opérations on obtient très vite des résultats. C’est un premier type de gain. Mais le véritable avantage tient à la gestion des incidents. Lorsque l’opérateur rencontre des problèmes dans le processus il lui est possible de les corriger rapidement. Il est ainsi possible d’éviter de devoir refaire une partie du travail déjà réalisé (le « reworking »).
Concrètement, en informatique, cela se traduit par un changement dans la démarche de travail usuelle. Traditionnellement on a une approche monolithique. La gestion de projet se fait étape par étape : on commence par effectuer l’expression des besoins, puis on effectue l’analyse fonctionnelle puis, quand elle est validée, on passe à la programmation, puis quand elle est terminée on effectue des tests. C’est une approche en mode palier. On effectue une chose après l’autre. Malheureusement cette démarche est lourde et lente. Pour éviter ces inconvénients il est nécessaire d’avoir une autre approche plus modulaire.

Une approche pièce à pièce

Pour éviter les gros projets monolithes il faut aller vers une démarche pièce à pièce. Cela consiste de traiter complètement une fonctionnalité, aussi complexe soit elle, de l’expression du besoin par l’utilisateur, à sa réalisation, à ses tests et à sa mise en production avant de passer à la fonctionnalité suivante. C’est le meilleur moyen d’optimiser le fonctionnement de l’usine informatique (IT Factory). Pour comprendre cela un exemple simple permet d’apprécier le phénomène
Lorsqu’on observe une autoroute on constate que les voitures circulent sans peine malgré un forte circulation puis soudain on constate que sans raisons les voitures s’arrêtent. Pour comprendre les bouchons il est nécessaire de prendre en compte trois facteurs :
-       Le débit. Il est mesuré par le nombre de voitures passant devant un compteur rapporté à l’unité de temps, par exemple 100 véhicules par minute.
-       La densité du trafic. Elle est appréciée par le nombre de véhicules se trouvant sur une distance donnée. Lorsque la distance moyenne entre chaque véhicule diminue la densité du trafic augmente et le risque d’embouteillage s’accroît.
-       La vitesse moyenne des voitures. Elle est stable pendant un certain temps puis soudain elle diminue et fini par s’effondrer. Lorsque la densité du trafic augmente la vitesse du flux de voitures diminue.
L’embouteillage survient lorsque le trafic est près de la saturation et que soudain un conducteur change de comportement : il freine car son téléphone sonne ou qu’un enfant pleur à l’arrière de sa voiture. Les conducteurs qui suivent freinent à leur tour et très vite le trafic se bloque.
On observe le même phénomène dans une usine fonctionnant à la chaîne : plus le débit augmente plus le risque de saturation est élevé. Lorsque un incident survient tout se bloque. Il en est de même dans le cas d’une équipe informatique. Normalement tout se passe bien mais lorsque cette dernière s’approche de la saturation et si un problème apparaît on assiste alors à un blocage et cela se traduit par une forte dégradation de la productivité. Une méthode de développement agile comme Scrum cherche à limiter les causes de ce type d’embouteillage (Pour en savoir plus sur Scrum sur Wikipédia cliquez ici). Dans cette approche on mesure la vélocité de l’équipe. Elle est mesurée à chaque Sprint. Plus on fait des Sprints courts meilleure est la fluidité de l’activité.  
La démarche pièce à pièce doit suivre les mêmes principes. Ses résultats sont simples :
-       La qualité des applications ainsi développées doit être meilleure,
-       La productivité des équipes informatiques doit s’améliorer,
-       La réactivité lors de l’apparition de nouveaux besoins doit s’améliorer.

Instrumenter la démarche

Pour y arriver il est nécessaire d’industrialiser la démarche DevOps en se dotant d’outils puissants et efficaces comme, par exemple, l’automatisation des tests. Dans une démarche classique la phase de tests est toujours trop lourde et comme en général le projet est en retard on la réduit au strict minimum. Ceci fait que les applications sont mises en production alors qu’elles sont imparfaitement testées.
Dans le cadre de la démarche DevOps on fait exactement le contraire. On teste le code tout au long du processus. Dès que le développeur a rédigé un ensemble cohérent de lignes de code on le test. Et pour améliorer la situation, dans la mesure du possible on cherche à automatiser les tests.
Il est pour cela nécessaire de concevoir l’application de façon à ce qu’elle soit facilement testable. La solution consiste à prévoir la testabilité dès la conception de l’application. De même il est nécessaire d’avoir un système de production fiable et notamment qu’il soit, en cas d’incident, facilement réparable comme ça été le cas de l’observatoire satellitaire Hubble. Un point clé de sa conception a été sa grande sûreté de fonctionnement. La Nasa a conçu le satellite pour être réparable. Lorsque elle s’est aperçue après son lancement que Hubble était myope il a suffi de concevoir sur terre les pièces nécessaires (les fameuses lunettes correctrices) et en quelques heures les astronautes ont réalisé la réparation dans l’espace.
Il est nécessaire d’arriver à la même situation en informatique. L’objectif est d’arriver à une production qui s’exécute sans anicroche. Si un incident survient il doit être rapidement résolu. C’est particulièrement le cas des sites de commerce électronique qui fonctionnent 24 heures sur 24, 365 jours par an.
Pour s’assurer de la fiabilité des applications et de l’installation il est nécessaire de mettre en place une procédure de « Chaos Monkey ». Celle-ci permet de provoquer des pannes aléatoires et de voir ce qui se passe. L’objectif est de rendre les systèmes d’information résilients. Le Chaos Monkey permet de s’assurer qu’en cas d’incident il ne se passe rien de grave et que la production continue sans observer de dégradation significative de la qualité de service.
Pour piloter le bon fonctionnement des systèmes d’information il est nécessaire de disposer de quelques mesures suffisantes permettant de constater que le service fourni est satisfaisant. On va pour cela suivre les temps de réponse, la charge transactionnelle, la taille des files d’attente, le nombre d’incidents, le nombre de processeurs actifs, …. Ces indicateurs doivent être pertinents et une personne, ou mieux un automate intelligent, doit en permanence les suivre pour, le cas échéant, intervenir.
Pour mettre en place la procédure de développement DevOps il est nécessaire de dégager dans l’ensemble des demandes des utilisateurs de petits incréments et de travailler séparément sur chacun d’entre eux. Dans le cadre de la méthode Scrum on cherche à avoir des Sprint de 15 jours. L’expérience montre que ce cadencement n’est pas un optimum et il faut chercher à réduire ce délai. L’idéal est d’emmener le code en production tous les jours quitte à masquer les développements inachevés. Le code rédigé dans la journée est immédiatement testé et, dans la foulée, mis en production. Les GAFA procèdent de cette manière et ceci explique, en grande partie, leur réactivité.
La principale contrainte freinant cette démarche est due aux bases de données. Chacun sait qu’il est toujours difficile de modifier la structure d’une base de données. Pour éviter ces difficultés on ne supprime pas et on ne modifie pas une colonne mais on ajoute de nouvelles colonnes à la base. Cela permet d’éviter la plupart des incidents et de faire des changements au fil de l’eau. Si on souhaite modifier une colonne on garde l’ancienne et on ajoute une nouvelle colonne. Ensuite, quand les modifications ont été faites et qu’elles marchent convenablement et qu’on n’a plus besoin de l’ancienne colonne il est alors possible de la supprimer.
Comme on le voit DevOps, c’est, en fait, une autre manière de travailler.

Le temple de Toyota

La démarche que nous venons de décrire est l’application fidèle à l’informatique de la démarche d’amélioration de Toyota appelée le modèle TPS qui décrit le système de production de Toyota (Toyota Production System). Le Lean Manufacturing s’appuie sur deux piliers :
-       Le juste à temps en charge de la productivité,
-       Le « Jidoka », ou autonomation, en charge de la qualité.
C’est ce que montre le schéma ci-dessous qui décrit ce qui est souvent appelé le Temple de Toyota.

Le temple de Toyota
Le « juste à temps » de la démarche de Lean Manufacturing, voir la colonne de gauche du temple ci-dessus, s’intéresse à la performance du processus par la maîtrise du flux de transformation. Il ne s’agit pas d’expliquer la nature des activités successives qu’il convient d’effectuer, mais de réfléchir à l’organisation de ces tâches pour traiter le plus grand nombre de besoins et créer ainsi le maximum de valeur pour le client avec un effort minimal.
La solution consiste à évaluer la séquence d’activité du point de vue de la création de valeur pour le client, supprimer les gaspillages (surproduction, attentes, rebuts-corrections, gammes opératoires mal adaptées, les transports/ruptures de flux, les mouvements inutiles et les stocks), supprimer des goulets d’étranglements, diminuer la taille des lots jusque au pièce à pièce et constituer des unités autonomes de production (ou équipes intégrées).
Le deuxième pilier du Lean Manufacturing poursuit la qualité et veille à ce qu’aucune cause de défaut ne perdure dans le processus de fabrication, c’est la colonne de droite du temple.

L’évolution des équipes

Pour mettre en place le DevOps il est nécessaire de changer la mentalité des personnels de l’informatique, que ce soit les développeurs ou les exploitants. C’est probablement un des points les plus délicat car il y a de mauvaises habitudes et il est nécessaire de les changer. Ainsi on a poussé les personnes à se spécialiser à outrance. Il faut au contraire développer la poly-compétence afin que chacun soit capable de faire de la conception, de la réalisation, des tests, la mise en production et de l’exploitation. Idéalement, toutes ces compétences sont réunies au sein de chaque équipe devenue autonome dans la satisfaction des besoins de leur métier utilisateur. Reste encore à ce que les différentes équipes fonctionnent sans qu’elles s’attendent les unes les autres et finissent par ralentir l’allure globale du projet.
Ces ralentissements peuvent venir de ce que certaines fonctions sont communes à toutes les équipes. Il est nécessaire alors de les codévelopper et de fusionner les modifications de chacun tous les soirs. Cette discipline connue sous le nom d’intégration continue permet la mise en production quotidienne de ce qui a été programmé et testé au cours de la journée. C’est du développement à haute fréquence.
On va ainsi aller progressivement vers un mode de développement intégré. Il concerne un grand nombre d’applications dont les sites Web et notamment l’amélioration des pages Web, les prototypes, le Big Data, …
Pour que chaque application puisse aller en production à son initiative, il faut que le respect des interfaces des autres applications suffise à garantir que l’on ne prend pas de risque sur le comportement business des processus transversaux aux dites applications. Ce n’est pas le cas lorsque l’architecture ancienne réalise un couplage trop fort et trop fragile entre les différentes applications ou leur différents modules applicatifs. Dans ce cas, on est obligé d’organiser ou de maintenir des rendez-vous d’intégration pour s’assurer que les nouvelles applications, chacune dans leur nouvelle version, fonctionnent correctement avec leurs sœurs siamoises. Cette caractéristique définit les monolithes applicatifs pour lesquels le fonctionnement en palier doit être maintenu : une mise en production globale en « big bang » suit le rendez-vous d’intégration.
Les applications métiers anciennes peuvent être des monolithes mais ce n’est pas toujours le cas. De même les ERP peuvent poser des problèmes d’intégration mais ce n’est pas une fatalité. Dans SAP, par exemple, la notion de « transport » peut permettre le fonctionnement en mode pièce à pièce jusqu’à la mise en production. On doit dans tous les cas essayer de multiplier les mises en production pour diminuer la taille des lots d’évolution, quitte à s’écarter d’un fonctionnement à haute fréquence.
Comme le montre le schéma ci-dessous de la pyramide digitale de la DSI Inclusive il est nécessaire de faire coexister dans les équipes informatiques trois modes de développement.


D’un côté il y a le mode prototype et le mode DevOps qui sont très voisins et s’adressent à des applications digitales mais aussi des applications traditionnelles qui ont été rendues modulaires et peuvent être modifiées et améliorées par incrément de code.
De l’autre il y a les applications traditionnelles que les anglo-saxons appellent les « légacy », souvent écrites en Cobol, et qui doivent être gérées selon le mode classique. Cependant, au fur et à mesure des travaux de réécriture, il est souhaitable de les faire migrer vers une architecture modulaire de façon à évoluer ensuite en mode DevOps.


vendredi 2 juin 2017

Est-ce que les robots tuent des emplois



Est-ce que les robots (ou l’IA) suppriment des emplois ?


Le débat est ancien mais il a été remis au gout du jour par l’élection présidentielle. Il est étonnant de voir la diversité des études, les différences dans les résultats et les grands écarts dans les interprétations. Essayons d’y voir clair et de comprendre les points essentiels.

Les études
L’étude mise en lumière par Benoit Hamon est celle de Frey et Osborne (2013) qui est résumée brutalement dans la presse par « les robots vont supprimer 47% des emplois ». Comme il est dit dans le titre elle porte sur les emplois susceptibles d’être fortement impactés voir supprimés par la technologie dans 20 ans. Les auteurs font un remarquable travail de décomposition d’emplois et d’analyse de l’impact de la technologie sur ces derniers. Avec cette méthode, dans d’autres pays, le pourcentage résultant est différent. En janvier 2017 et en France, le Conseil pour Orientation et l’emploi a repris ce principe pour une étude sur les tâches et non plus sur les emplois et là le pourcentage de disparition tombe à 9%.
Ces deux études sont très sérieuses et bien faites, elles ne sont pas appuyées uniquement sur un modèle mathématique et elles sont prospectives : « comment les technologies peuvent supprimer ou impacter fortement des emplois ou des tâches » en revanche, elles ne disent rien de ce qui se passe à côté (emplois créés ailleurs par la technologie) et elles raisonnent toujours « toutes choses égales par ailleurs » c’est-à-dire sans prise en compte des nouveaux secteurs, des développements de pays ou de nouvelle donnes écologiques.

Une étude du MIT relance le débat en mars 2017 : chaque robot détruit 6 emplois. Il s’agit ici d’une étude rétrospective et mathématique qui observe l’évolution du marché du travail de 1990 à 2007 dans chaque secteur d’activité qui a été robotisé. Un solide modèle mathématique est mis au point de manière sérieuse en prenant soin d’éviter les effets perturbateurs des autres facteurs de destruction d’emplois (importation ou offshoring). Mais comme les deux premières études prospectives, une faiblesse est la même : on regarde à un endroit (ce qui est entré dans le modèle mathématique) et pas partout. De plus, avec ce raisonnement (un robot détruit 6 emplois) nous devrions avoir en France moins de chômage qu’en Allemagne car nous avons beaucoup moins de robots.

Enfin le 3 avril 2017, une autre étude sérieuse prétend que les robots créent de l’emploi en Grande Bretagne ! Mais il s’agit là uniquement de déclaratif de responsables d’entreprises et c’est plus l’analyse sur la formation et l’impact social qui est ici pertinente.

Enfin n’oublions pas qu’une étude, même économique, mathématique et sérieuse, peut donner des résultats faux. On se souvient du bel exemple de l’étude de 2013 liant dette publique et récession.

Un vieux débat
Comme me l’a appris mon ami Claude Salzman, économiste et spécialistes de l’informatique, le débat sur l’impact des technologies sur l’emploi date de la révolte des luddites qui a précédée celle des Canuts en France. En modernisant les outils, on augmente la productivité donc a priori on supprime des emplois. Là où il fallait 3 ouvriers, s’il n’en faut plus que un, on a donc supprimé 2/3 des emplois : CQFD. Mais il faut tenir compte de la fabrication de ces outils modernisés (les métiers à tisser pour les Canuts) qui va demander de nouveaux ouvriers. De plus, l’augmentation de la productivité va (ou peut) créer de la richesse qui va augmenter la consommation et donc créer de l’emploi. La pure logique mathématique qui semble si évidente n’est donc pas toujours correcte.

Le même mode de raisonnement s’applique aux travaux agricoles où la taille des exploitations augmente, la main d’œuvre agricole diminue et la productivité augmente. Donc un homme seul peut cultiver toujours plus d’hectares en utilisant toujours plus de technologies (du tracteur jusqu’aux drones). La question de l’impact sur la santé et l’environnement est là si évidente qu’elle ne peut être oblitérée.

On voit sur ces exemples, que des emplois sont détruits mais que d’autres sont créés et que l’augmentation de la productivité est à prendre en compte. Quatre questions sont alors toujours posées par l’utilisation de la technologie sur l’emploi :
1.      Combien de créations d’emplois pour combien de destruction ?
2.      Quelles sont les compétences requises pour occuper ces nouveaux emplois ? Les ouvriers de l’ancien système peuvent-ils, en étant formés, travailler sur le nouveau système ? A-t’on le système de formation continue adéquate ?
3.      Où sont créés les nouveaux emplois ? Les ouvriers licenciés pourront-ils physiquement occuper ces emplois ? Quels est l’impact à l’international ?
4.      Si la technologie augmente la productivité et crée de la valeur ajoutée, quel est l’impact positif sur l’emploi ?

De nouvelles questions sont posées en 2017
On parle de technologie, d’informatique, de robots et d’Intelligence Artificielle (IA) en mettant tout dans le même sac. Est-ce exact ? L’IA n’a-t ’elle pas des caractéristiques différentes ? Combien d’emplois peuvent être supprimés dans un Call Center par l’utilisation d’un système intelligent de SAV ? D’un autre côté, combien de personnes sont capables de fabriquer un agent intelligent basé sur du « deep learning » ou du « quantum learning ».

La vision sociale et écologique est toujours absente de ces débats comme si on n’avait pas le choix et qu’il fallait forcement et toujours privilégier le robot à l’humain si c’est possible et moins cher. N’a-t’on vraiment pas le choix ? Ne peut-on écarter des nouveautés technologiques si elles produisent plus de dégâts que d’améliorations. N’y a-t-il pas d’autres solutions aussi innovantes mais moins couteuses pour l’environnement. On peut voir, par exemple, les expérimentations de permaculture dans le domaine agricole.

Enfin la taxe sur les robots est-elle vraiment une idée absurde ? La taxe carbone si difficilement et parcimonieusement mise en œuvre a aussi été jugée absurde dans les premiers débats. L’idée de taxer ce qui détruit un bien de la société n’est pas à rejeter à priori et sans autre argument que « c’est absurde » ou « cela va grever la compétitivité ». Et quand Bill Gates défend cette idée, on est en droit juste de réfléchir sans a priori.

En étant un peu plus intelligent, j’ose croire qu’on peut faire bouger les lignes et ne pas subir l’équation qui semble implacable : la technologie tue ou va tuer l’emploi.
Bernard Quinio