Le consultant, le technicien et les métiers

Prenons, si vous le voulez bien, le cas d’une entreprise dont le dirigeant est convaincu qu’il est temps d’amorcer sa transformation numérique. Soucieux de bien faire et ne disposant pas de l’expertise nécessaire en interne, il décide de faire appel à un conseil stratégique spécialiste – ça tombe bien – de la transformation numérique.

Le consultant mandaté est à pied d’oeuvre pendant quelques semaines et il déroule sa méthode sans accroc. Il observe, il analyse et il conseille enfin. Son rapport offre à l’entreprise une vision désormais claire des enjeux de la transformation numérique, de ses défis, des objectifs qui peuvent être atteints, et bien sûr de la route à suivre pour y parvenir.

Le consultant, n’étant pas numérique pour rien, est bien entendu sensibilisé aux questions de cybersécurité. D’autant plus que si l’on parle de transformation numérique l’on parle forcément de données personnelles, d’identifiants et de secrets (les fameuses clés d’API), d’applications mobiles, du stockage des-dits secrets dans les-dites applications mobiles, de bases de données, de chiffrement à la volée ou non, de PaaS et de… Stop ! Notre consultant est sensibilisé, mais il n’est pas expert. Il préconise donc simplement que « Toute donnée personnelle collectée doit faire l’objet d’une protection adéquate et d’une déclaration auprès de la CNIL » . Et il a raison.

Dans l’entreprise, après la remise du rapport, les rouages s’activent (et c’est déjà suffisamment rare pour être noté). Le marketing est à la manoeuvre, ce qui n’étonnera personne. Car après tout le marketing a planté depuis longtemps son drapeau sur les sommets embrumés de la transformation numérique.

La DSI, quand a elle, opère en soutien. Les préconisations du rapport ont été ventilées façon puzzle et l’une d’elles atterri sur le bureau de son directeur : « Toute donnée personnelle collectée doit faire l’objet d’une protection adéquate » (le lecteur attentif aura remarqué qu’il manque un morceau à cette recommendation : dans l’explosion façon puzzle, la seconde partie a atterri sur le bureau du directeur juridique).

Telle une fontaine de champagne dans un mariage, les responsabilités s’écoulent le long de la hiérarchie de l’entreprise pour finir sur le bureau (ou les épaules) d’un développeur web rattaché à une société externe spécialisée dans la création de sites internet. Et pour ce dernier, informaticien de son état, « Toute donnée personnelle collectée doit faire l’objet d’une protection adéquate » ne peut signifier qu’une chose : du chiffrement ! Du chiffrement partout ! Après avoir consulté l’oracle des développeurs, Notre Saint StackOverflow, il s’empare donc d’une librairie de chiffrement Libre (car c’est un professionnel et il sait donc très bien qu’il est péché de créer sa propre implémentation). Notre développeur entreprend alors de chiffrer à travers son application toutes les données clients qui doivent être écrites dans la base baptisée « Abonnes » (oui, les développeurs n’aiment pas les accents).

Que la librairie de chiffrement n’ait fait l’objet d’aucune validation par le client ou ne puisse présenter aucune garantie d’audit n’est pas le sujet ici. Que celui qui n’a jamais utilisé sans les auditer Fernet (Python) ou Defuse (PHP) lui jette la première pierre.

Ce qui est intéressant, en revanche, c’est qu’une fois revenue à l’échelon de la DSI, l’application exhibe un ralentissement significatif. Ce n’est pas tant lors de l’enregistrement d’un nouvel abonné que cela pose un problème. Mais en revanche lors des envois massifs de courriers à l’ensembles des abonnés, l’application (affectueusement affublée du petit nom de « moulinette ») met environ cinq fois plus de temps a s’exécuter que celle, maison, qui se chargeait jusqu’alors des envois de courrier. Etant homme de performance, le DSI décide que cela n’est pas acceptable et refuse de recetter l’application.

Dans un vaudeville qui n’est pas sans rappeler la valse amoureuse entre une Myriam El Khomri et un Philippe Martinez, les relations se tendent entre l’entreprise et son sous-traitant, au point de devoir faire intervenir le service juridique. Il est demandé à ce dernier d’arbitrer le débat : « peut-on se passer de chiffrer les informations personnelles des abonnés ? » .
Non, répond bien entendu le service juridique.

Et la situation est bloquée.

Jusqu’à ce qu’un autre consultant, qui n’a pas été sollicité mais a tout de même servi au DSI d’épaule pour pleurer, pose la question qui manquait : « Et sinon, vous voulez en faire quoi de ces données, exactement ? » .

Illico le marketing est sollicité. Ces données serviront à publier des messages sur les murs des réseaux sociaux des utilisateurs qui se seront inscrits au nouveau service. Il n’y a donc besoin, pour cette application là, que de très peu de données personnelles. Mieux : les utilisateurs sont déjà clients et donc beaucoup de ces informations sont déjà stockées dans une base de donnée gérée en interne qui fait l’objet d’une procédure de protection adéquate.

Il ne s’agit donc plus finalement que de stocker des jetons d’accès Twitter ou Facebook ( dits « jetons oAuth » ). Des objets dont le niveau de sensibilité est largement inférieur, fait remarquer le second consultant, puisqu’ils peuvent être annulés à tout moment par l’utilisateur, qui n’a en outre a aucun moment confié son mot de passe.

Ceux-ci peuvent bien entendu être chiffrés lors de leur stockage en base de données (c’est d’ailleurs ce que conseille Twitter), mais une analyse de risque sérieuse peut également déterminer que si la base en question est hébergée dans un environnement qui présente des garanties suffisantes en terme de traçabilité et de contrôle des accès physiques et logiques, d’administration et d’audit des accès privilégiés, un chiffrement des données au repos n’est peut être pas nécessaire. D’autant que les jetons oAuth ne représentent pas aux yeux du législateur une donnée à caractère personnel.

Dans ce mélo-drame d’entreprise, tout le monde a pourtant parfaitement joué son rôle :

  • Le consultant en transformation numérique, en alertant sur les obligations légales de l’entreprise et les risques liés à la cybersécurité
  • Le Marketing, en souhaitant mettre en oeuvre au plus vite une première préconisation du rapport du consultant, à savoir une application mobile associée à une API afin d’accéder aux données existantes
  • La DSI, en refusant une application qui ne répond pas à ses critères de performance
  • Le développeur web, en choisissant de chiffrer des données présentées comme sensibles
  • Le service juridique, a qui l’on ne fera jamais dire qu’il faut arrêter de protéger les données personnelles des utilisateurs. Même en échange d’une paire de Berluti ou de Louboutin pour l’ensemble du service.

L’on pourra trouver des dizaines d’occasions, dans cette affaire, où telle ou telle partie a manqué de précision ou d’expertise, aurait du creuser un peu plus son dossier ou n’a pas eu le temps d’affiner ses exigences. L’absence d’un CIL, aussi, est un handicap.

Mais le point essentiel est qu’il a surtout manqué d’un acteur incontournable : un monsieur loyal transverse, capable de parler à la fois le langage de la cybersécurité et de l’entreprise, capable de faire le lien entre un DSI généraliste, un développeur très technique et des métiers à qui, finalement, on prête beaucoup de pensées sans leur demander leur avis !

Appelez-le chef de projet interne, consultant externe ou tout simplement mouton à cinq pattes venu d’un autre monde, ce profil est désormais celui qui permettra de briser les silos, intelligemment et avec diplomatie, et d’accompagner l’entreprise dans ses projets à venir. Des projets numériques à la confluence de la stratégie, de la cybersécurité, de la réglementation et des métiers.  

Lire les articles précédents :
Les 10 règles qui auraient sauvé Hacking Team

Une lecture en creux de l'attaque contre la société Hacking Team. Nous tirons de ce formidable retour d'expérience 10 bonnes...

Fermer