Les rôles et impacts de l’IA dans le monde professionnel

Lorsque l’on évoque le sujet des “IA” de manière générale, on entend beaucoup de banalités, pas mal d’inquiétudes. Et en fait, beaucoup de méprises et d’incompréhensions. Les cas les plus visibles sont les voitures autonomes par exemple, ou bien les tentatives de systèmes semi-autonomes dont le comportement dérive très vite.

Je voudrais essayer de rendre ces problématiques un peu plus claires, en synthétisant mes lectures et recherches diverses.

Quelques bases de conversation

Tout d’abord, posons les bases. Je n’apprécie pas beaucoup le terme IA, car il est très vague. Dans l’esprit de certains, une IA est un système doué de conscience, avec des niveaux de compréhension et de raisonnement au moins similaires à un humain. Dans la réalité du quotidien, ce que l’on entend par IA s’étend depuis un système de décision automatique mais figé (comme une brosse à dents qui détecte si les dents sont assez propres) à des systèmes relativement autonomes, dans un domaine limité (comme des voitures).

Mettons que l’on s’occupe de tout ce scope-ci, les systèmes autonomes, en incluant tout ce qui permet d’automatiser tout ou partie d’un processus. Ces systèmes sont la plupart du temps très loin de l’IA et ne sont souvent que des robots capables de suivre des arbres de décision pré-établis. Mais certains sont plus complets ou autonomes.

Une fois l’incompréhension sur la terminologie posée, j’aime bien définir les différents cas d’utilisation de ces systèmes, dans le monde professionnel principalement.

Les typologies d’usages

En premier on retrouve les systèmes d’assistance, déjà très répandus. Ce sont les “robots” que l’on active à notre initiative, pour effectuer une opération complexe à notre place. Par exemple nous avons les systèmes de traduction automatique de génération précédente. Ils nous permettent de vérifier une traduction ou une compréhension de manière générale, en allant bien plus vite qu’avec un dictionnaire. Le contexte n’est pas forcément pris en compte, pas plus que les double-sens et les expressions locales (géographiquement ou liées à un jargon métier).

Ensuite nous avons les systèmes complémentaires. Ce sont des systèmes qui travaillent avec nous, en parallèle, et qui viennent nous proposer des suggestions pour nous aider dans notre travail. Leur capacité d’analyse est souvent assez large et profonde. Cela leur permet de suivre des opérations sur un spectre et une profondeur que nous ne pouvons souvent pas atteindre sans de très longs et couteux calculs. Dans le domaine de la surveillance vidéo, la reconnaissance faciale pour des systèmes de type CCTV permet de retrouver un individu dans des flux multiples, puis de reconstituer son parcours dans le temps et l’espace.

Enfin, arrivent les systèmes que je qualifie de remplacement. Dans les plus simples on retrouve les chatbots ou callbots qui permettent de traiter de nombreuses demandes de manière automatisée, sans intervention humaine. Pour les plus complexes, nos fameuses voitures autonomes sont de bons exemples.

Des inquiétudes et des réponses

Ce sont ces dernières qui inquiètent, pour plusieurs raisons:

  • La sécurité des personnes et des données, et donc la fiabilité des systèmes.  Cf les accidents de voitures autonomes,
  • L’emploi, si ces systèmes étaient à même de remplacer des emplois,
  • L’explicabilité, pour pouvoir décortiquer la chaine de décision lorsqu’une anomalie est signalée et pour détecter les biais.

Je ne vais pas pouvoir entrer dans des détails avancés pour répondre à chacune de ces inquiétudes, un livre n’y suffirait pas. Je peux néanmoins donner quelques pistes de réflexion.

En ce qui concerne la fiabilité des systèmes, il y a une chose qui me frappe dans toutes mes discussions au sujet des “IA” : tout le monde s’attend à ce que ces systèmes soient parfaits. Une voiture autonome ne devrait jamais avoir d’accident. Un système de prédiction ne devrait jamais se tromper. Un automate devrait toujours effectuer la bonne action.

Question naïve : à quoi compare-t-on ces systèmes?

Formulé autrement :

  • Est-ce qu’un conducteur humain est infaillible? Quelles sont les statistiques d’accidentologie des humains? Des “IA”?
  • Lorsque l’on demande à un système de traiter des formulaires de manière automatique, quelle est l’alternative? Si je demande à un modèle de reconnaître des écritures manuscrites pour faciliter mon travail, est-ce que je suis fiable à 100%?
  • Si je mets en place un système de caisses intelligentes qui reconnaissent le contenu d’un plateau repas, le système pourrait être fiable à 99% (par exemple). Connaissez-vous le taux d’erreur d’un opérateur humain? Indice : il est plus élevé que 1% 🙂

Quid des erreurs?

Petite note au sujet de la gestion des erreurs, l’idéal lors de manipulation de modèles est de bien gérer les seuils d’acceptabilité. En d’autres termes, un modèle d’IA vous indiquera toujours ce qu’il pense être la bonne information (prédiction, réponse, classification etc.) accompagné d’un taux de fiabilité de sa réponse. Il faut bien penser à fixer le seuil en dessous duquel le taux de fiabilité ne doit pas descendre pour que la réponse reste acceptable.

Et idéalement, signaler, à l’utilisateur final ou à l’administrateur de la solution, lorsque des écarts se produisent, afin de pouvoir identifier les cas limites et de pouvoir améliorer le système.

Quand on touche à l’emploi, le sujet est plus délicat. Je conçois et je comprends l’inquiétude générale de se voir remplacé par des automates. Je pense que le risque est majoritairement exagéré, ce qui n’empêchera pas de voir des victimes de ce mouvement. Mon espoir est que les systèmes vont remplacer des humains pour des tâches répétitives et de très faible valeur, ou bien pour des tâches qu’un humain n’aurait pas pu faire de toute façon. Et donc les humains pourront se concentrer sur des tâches à forte valeur, qui impliqueront des vraies sensibilités et compétences, plutôt qu’une simple capacité à copier des données entre différents systèmes informatique par exemple.

Enfin, de nombreuses publications et témoignage ont été rédigés au sujet de l’explicabilité. J’en ai fait un moi-même, je vais donc vous y référer, plutôt que de me répéter : https://cloudinthealps.mandin.net/2019/10/24/de-lusage-des-datas-et-de-lia/

J’ajouterais tout de même quelques remarques sur l’explicabilité. La plupart des modèles utilisés aujourd’hui souffrent de données d’origine qui sont biaisées. Ce n’est pas volontaire, et souvent même pas conscient. Les data scientist et techniciens qui préparent ces données et ces modèles travaillent avec leur propre contexte et ne sont pas forcément conscients des limites et conditions qu’ils se fixent.

Par exemple, il est connu que la plupart des banques d’images qui servent à entraîner les modèles de reconnaissance faciale ne bénéficient pas d’une répartition suffisante par rapport à la population générale. En termes bruts : la majeure partie des données utilisées concernent des gens à la peau claire, et occidentaux. De ce fait, les modèles seront de piètre qualité pour travailler sur des populations à la peau mate, ou aux traits asiatiques. Evidemment, les modèles fournis par Tencent, pour ne citer qu’eux, souffrent probablement du biais inverse.

Et une petite anecdote pour la route : les premiers projets de voiture autonome développés en Europe ont rencontré des problèmes lors des exportations. En effet, une fois les voitures livrées à elles-mêmes sur les routes australiennes, les chercheurs se sont aperçus d’un oubli majeur : la faune est radicalement différente entre l’Europe et l’Australie. Et les voitures ne savaient pas identifier des kangourous…

De manière plus sérieuse, c’est un des plus gros écueil pour la création de voiture réellement autonomes : être capable, comme un humain, de s’adapter à toutes les circonstances, mêmes totalement inattendues.

Et c’est ce qui distinguera les humains pour encore de longues années.

De l’usage des datas et de l’IA

Le buzz autour de l’IA semble se cristalliser autour de deux principaux sujets : les possibilités offertes par la technologie, et les risques liés à son utilisation.

La question des risques est un sujet de choix pour les détracteurs et les récalcitrants. Nombre d’articles et de livres listent les problèmes posés par l’IA et souhaiteraient nous voir jeter le bébé avec l’eau du bain, et la baignoire au passage.

Ce qui me trouble beaucoup dans cette démarche, en dehors du danger que l’on fait courir aux bébés qui prennent leur bain, c’est que l’IA focalise l’attention, alors que le problème est humain avant tout. L’IA ne fait rien de nouveau ou de plus que d’autres systèmes précédents. Et même le terme IA est galvaudé, particulièrement dans ces cas-là.

Prenons quelques exemples.

Le plus ancien me concerne directement. Il y a une dizaine d’années, j’ai déménagé au Royaume-Uni, et j’ai voulu ouvrir un compte en banque. Nous avons choisi une banque connue et répandue. Nous avons passé quelques heures à remplir des formulaires, puis avons attendu de recevoir nos moyens de paiement. Le jour où nous les avons enfin obtenus, nous avons aussi eu un lettre nous indiquant que notre compte allait être fermé car nous n’étions pas conformes à la politique de la banque. Aucune autre information n’était donnée. Ayant noté une erreur dans le nom auquel le courrier était adressé, j’ai voulu rentrer en contact avec la banque, pour savoir quelle était la raison réelle de ce refus et vérifier s’ils n’avaient pas suivi le dossier de quelqu’un d’autre (le credit score existant dans ce pays, j’aurais pu être confondu avec une personne ayant un mauvais score). Après de multiples emails et coups de téléphone, la seule réponse que j’ai obtenu a été “le système Phoenix nous indique que nous ne pouvons pas vous octroyer un compte”. Impossible d’en savoir plus.

Ce qui m’a dérangé, en bon français habitué à la CNIL, a été de me voir opposer un mur anonyme, sans avoir aucun moyen d’accéder aux données me concernant. La banque pouvait me refuser un service, sans aucune justification ni explication. Aucune IA à cette époque, quelques recherches m’ont montré que je n’étais pas le seul à avoir des problèmes avec Phoenix, et que celui-ci était un simple système de vérification qui pouvait se déclencher pour des raisons obscures. Et bien sûr impossible de faire corriger mon dossier d’application pour que le contrôle effectué corresponde bien à ma propre situation (il reste très probable que l’erreur de nom dans le courrier de refus prouve que les données de contrôle ne me concernaient pas).

Pour l’épilogue, nous sommes allés dans une autre banque, avec le même dossier. Nous avons expliqué la situation, et après quelques échanges avons obtenu notre compte.

Je peux utiliser d’autres exemples, comme les systèmes de logement aux US qui se basent sur des données plus ou moins publiques pour déterminer si vous êtes aptes à recevoir un logement. Je ne parle pas de système de logements sociaux, mais de sociétés privées qui fournissent des service de background check pour les bailleurs privés. L’expérience malheureuse de quelques-uns a montré que, comme dans le cas de Phoenix, il est impossible d’accéder à nos propres données, de savoir quel critère nous a rendu indésirable et encore moins de pouvoir corriger les données si jamais il y a une erreur.

Ou bien pensez au système de social scoring chinois. Si vous trouvez le credit score anglo-saxon désagréable, je n’ose imaginer les dérives possibles du social scoring.

Accessoirement cela peut créer des cercles vicieux, rappelez-vous l’épisode Nosedive de Black Mirror. Tant que vous êtes un blanc mouton, gentil et hypocrite, tout va bien. Au moment où un grain de sable vous fait dérailler, tout part de travers. Votre score se dégradant, vous vous trouvez dans des situations plus compliquées (difficultés à obtenir un prêt, un travail, un billet d’avion etc…) et le risque que votre score se dégrade augmente.

Bon il s’agissait de fiction, mais finalement très proche de la réalité. Revenons au credit score américain : si votre score est mauvais, vous aurez du mal à obtenir un prêt de bonne qualité. Mais vous finirez par en obtenir un à de très mauvaises conditions, ce qui signifie souvent qu’il vous coûtera cher et que vous augmenterez le risque de défaut de paiement, même temporaire. Ce qui va dégrader votre credit score, etc. etc etc.

Mais tout ceci n’est pas lié à de l’IA. Certes, parfois ce sont des algorithmes obscurs qui ne rendent pas d’explication sur leur décision. Et ce ci doit être combattu et corrigé. Mais la plupart du temps la sélection se fait sur des critères cachés mais très simples. La discrimination existe, avec ou sans IA.

Ce à quoi il faut être attentif reste l’accès aux données et l’explicabilité des modèles.

Pour la première, nous avons en Europe le règlement RGPD qui oblige à cette transparence (et à la protection de nos données). C’est un pas dans la bonne direction, au moins dans notre juridiction.

Pour l’explicabilité des modèles, il n’existe pas encore de règle, à ma connaissance, mais cela devrait être obligatoire pour tout ce qui touche aux besoins primaires, à minima.

NB : je vous conseille la lecture de Weapons of Math Destruction, de Cathy O’Niel. A lire avec un peu de recul, mais sa démarche pour identifier les IA/algorithmes/outils nocifs est intéressante.

Mon test d’Azure Bastion

Alors oui, c’est une fonctionnalité dont nous parlions peu mais qui va simplifier beaucoup la vie quotidienne.

L’annonce de la public preview est récente, mais la fonction marche déjà très bien, sous peu que vous utilisiez le portail Azure Preview (https://aka.ms/BastionHost).

Le principe est très simple : vous avez des VMs connectée à des Vnet isolés du monde extérieur, et vous ne souhaitez pas ouvrir les ports d’administration (SSH/RDP) de ces VMs vers l’extérieur.

Habituellement, vous montiez une VM dédiée, qui elle était configurée pour accepter les connexions extérieures, avec une stack spécifique lui permettant de servir de relais vers les VMs protégées.

Bonjour la complexité :

  • D’administration d’une solution dédiée, et parfois bancale (si quelqu’un aime sshgw, qu’il se jette la première pierre!)
  • D’utilisation au quotidien. Dans certains cas un logiciel particulier permettait une connexion relativement simple, dans d’autres il fallait s’authentifier plusieurs fois et faire des tunnels SSH pour arriver à sa destination…

Et là, libération avec Azure Bastion. Démonstration!

Mettons que vous ayez déjà une VM déployée sur Azure. Lorsque vous utilisez le portail Azure pour vous y connecter, en principe, vous n’avez qu’à cliquer sur le petit bouton qui va bien. Dans mon cas une VM Linux :

Mais je triche, cette VM possède une IP publique ouverte sur l’extérieur.

Si je dissocie la VM et l’IP publique, c’est une autre paire de manches…

Mais il me reste la jolie option Bastion.

Comme je n’ai encore rien déployé, il me propose de le faire à ce moment-là :

Quelques questions à compléter, surtout en termes d’adressage :

Le déploiement ne prend que quelques minutes.

Une fois tout déployé, j’ai accès à l’option Bastion, je n’ai plus qu’à indiquer mon user/password, et hop, j’ai un nouvel onglet qui embarque ma connexion. Honnêtement, je n’ai rien vu de perceptible en termes de performance.

(oui les lecteurs attentifs auront noté un léger détail, ma démo a été faite en deux fois, avec une VM Linux au début, et Windows à la fin 🙂

En termes de management du bastion, pour le moment, les options sont peu nombreuses, en dehors des menus standards de log/IAM/tags etc.

Nul doute que cela viendra avec les avancées de la Preview, puis la sortie en GA

Quelques petites notes malgré tout pour le déploiement.

Pour le moment, celui-ci nécessite la présence d’un subnet en /27 minimum nommé AzureBastionSubnet pour fonctionner.

Et la liste des régions possibles pour la preview reste limitée :

  • West US
  • East US
  • West Europe
  • South Central US
  • Australia East
  • Japan East

Et la doc complète est là : https://docs.microsoft.com/en-us/azure/bastion/bastion-create-host-portal

Alors vous en pensez quoi? Vous le déployez tout de suite?

The Remote Expert

I have to admit that I came into the Remote Expert topic by accident. A customer request on the subject prodded me into investigating a few possibilities. Once I had tested some solutions, I was quickly convinced, and able to run some demos, mostly unplanned. What helped a lot is the fact that the solutions are very quick to set up and have a fast benefit for the business. The feedbacks I got while demoing to our customers completed the convincing for me.

So what is Remote Expert  (or Remote Assist)?

Lets’ imagine that you have in your structure a fleet of onsite technicians for varied tasks. Those could not be expert in every domain, nor know in advance everything they might need when they intervene in a specific environment. On the other hand, you will probably have a domain expert which will possess the necessary knowledge. However he will not be able to be present on every site he would needed on in a single day, as breakouts and interventions would never be planned as we would liek them to.

What we need is a cloning solution to have multiple instances of said expert. As human cloning is not yet ethically accepted, we need something else. And this is Remote Expert.

This solution involves the use of a mobile device on site, to share the work environnement between the technician and the expert. But more useful is the possibility to anootate and give hints and indications on that environment.

The technician may use two options:

  1. He is equipped with a mixed reality headset. In that case he may use it to share his work space, and have in his field of vision a dialog window or a shared space with the expert. They would then be able to share indications, in addition to an operations manual, for example.
  2. He has a mobile phone, compatible with AR (most of them are). He will then be able to use that device to show his view and share the annotations, in a more restricted way, but without needing specific hardware.

In short, this would come down a videoconference, with whiteboard fonctionnalities.

It is important to note that thanks to spatial anchors technologies, every annotation and indication is anchored to a physical spot in the field of vision. This allows the technician to move arount without losing the indications.

As a demo is better than a long talk, here is a screenshot of a demo that I did with some LEGO bricks:

The complete demo is here, without comments for now :

In this demo, for practical reasons, I have used the product Chalk from PTC (https://chalk.vuforia.com).

The other solution I use is Dynamics Remote Assist from Microsoft (https://dynamics.microsoft.com/en-us/mixed-reality/remote-assist/)

If you have any question regarding the products, ask me!

Remote Expert

J’admets être venu au sujet du remote Expert par accident. Une demande client sur le sujet m’a amené à creuser quelques pistes. Une fois les quelques solutions utilisées et testées, j’avais en main de quoi effectuer simplement quelques démos, parfois de manière inopinée. J’ai été convaincu très vite du potentiel de cette solution simple à mettre en œuvre. Les quelques démos effectuées au détour d’une conférence ou d’une simple discussion montrent que les clients sont convaincus aussi.

Le Remote Expert  (ou Remote Assist), qu’est-ce que c’est?

Imaginons que vous ayez dans votre structure une flotte d’intervenants sur site pour des tâches très variées. Ceux-ci ne peuvent pas être experts dans tous les domaines, ni connaître par avance tout ce dont ils auront besoin avant d’être appelés en dépannage. D’un autre côté, vous aurez sûrement un expert du domaine, qui maitrisera parfaitement l’intervention à effectuer. Mais celui-ci ne sera pas en mesure d’être présent sur l’ensemble des sites au cours d’une journée, les pannes ne se planifiant jamais comme cela nous arrangerait.

Il faudrait donc une solution permettant à l’expert de se démultiplier. Comme le clonage humain n’est pas encore au point ni éthiquement accepté, il faut trouver autre chose. Et voici le Remote Expert.

Cette solution consiste à utiliser un appareil mobile sur le site de l’intervention, pour partager l’environnement de travail avec l’expert. Et surtout de pouvoir annoter et donner des indications sur cet environnement.

L’intervenant peut utiliser deux options :

  1. Il est équipé d’un casque de réalité mixte. Dans ce cas il peut l’utiliser pour partager son espace de travail, et avoir dans son champ de vision une fenêtre de dialogue ou de partager avec l’expert. Celle-ci permettra par exemple de montrer un schéma, ou simplement de voir le vidéo conférence.
  2. Il possède un téléphone mobile. Il pourra alors l’utiliser pour montrer ce qu’il observer, et voir partager les annotations avec l’expert. Il pourra lui aussi annoter sa vision.

En bref, cela revient à une vidéoconférence, couplée à un tableau blanc interactif.

Il est à noter que grâce à des technologies d’ancres géospatiales, toutes les annotations sont ancrées sur des objets physiques du champ de vision. Cela permet à l’intervenant de se déplacer sans perdre les indications.

Voici une capture d’écran de que cela donne, avec un petit circuit en LEGO :

Pour la vidéo complète, c’est ici :

Dans cette démo, pour des raisons purement pratiques, j’ai utilisé la solution Chalk de PTC (https://chalk.vuforia.com).

L’autre solution que j’utilise est Dynamics Remote Assist de Microsoft (https://dynamics.microsoft.com/en-us/mixed-reality/remote-assist/)

Pour les tarifs et les comparatifs, contactez-moi 🙂

La tranformation DevOps – deuxième étape

Bienvenue dans ce second épisode de ce qui menace de se transformer en série de posts sur DevOps et la transformation DevOps. Malheureusement pour vous, je dis souvent ce qui me passe par la tête, et il n’y a aucun plan génial visant à écrire un livre chapitre par chapitre. Le premier article parlait de choisir une stratégie lors de la transformation DevOps d’une équipe de services managés.

Ce second article ne vient pas nécessairement après le premier, vous avez toute liberté de choix 🙂

D’une certaine façon, mon sentiment est que DevOps est assez proche d’ITIL dans l’esprit : une boite à outils où vous pouvez prendre ce dont vous avez besoin, et décider comment l’utiliser.

Donc, sujet d’aujourd’hui : comment viser, ou construire l’équipe qui va initier le mouvement DevOps dans votre organisation?

Il existe plusieurs indicateurs sur lesquels s’appuyer pour faire ce choix. Aucun n’est absolu. Encore une fois, je ne vous donne que des indications pour sélectionner l’équipe qui va réussir à appliquer des principes DevOps. Il n’y a pas de

Remède miracle, ni de baguette magique!

Le critère le plus évident est de constituer une nouvelle équipe, en sélectionnant  des collaborateurs qui sont déjà au fait  de DevOps, et désireux de s’y mettre. Cr sont les personnes qui sont les plus susceptibles de vous aider à réussir ce premier pas, et montrer au reste de l’organisation que la transformation est possible, et qu’elle génère beaucoup de gains et bénéfices.

Le second indicateur à repérer est fortement lié au principal objet des méthodes DevOps : le software delivery. Si vous avez une équipe qui rencontre des difficultés à maintenir un processus de livraison de code fiable, et que cette équipe est prête à s’investir pour construire l’équipe et les outils nécessaires pour en arriver là, alors vous avez un très bon candidat. A l’opposé, si vous essayez de convaincre une équipe qu’elle doit s’intéresser à DevOps, alors qu’ils sont persuadés que leur processus actuel est fiable et de qualité, à tort ou à raison, vous allez vous heurter à un mur. Il ne semble pas pertinent de consommer du temps et de l’énergie dès le départ pour convaincre des gens qu’ils effectuent un travail de piètre qualité s’ils ne le réalisent pas. Ce n’est très probablement pas la bonne cible pour votre premier pas vers DevOps.

Le dernier critère nous ramène à mon sujet favori, en dehors de la technique : les bénéfices business!

Cela paraît évident, mais une transformation dans votre organisation doit toujours être sensible aux objectifs business, à la cible de l’entreprise dans son ensemble. Imaginons que vous choisissiez une équipe qui travaille sur un produit en fin de vie sur lequel aucune évolution n’est prévue, et dont les clients sont satisfaits. J’ai bien peur que vous n’ayez aucun soutien, ni aucun résultat évident si vous démarrez votre transformation DevOps par cette équipe. D’un autre côté, si vous arrivez à commencer par une équipe travaillant sur le produit phare de l’organisation, sur lequel les yeux des plus hautes instances sont rivés, et qui doit démontrer une capacité de livraison de code moderne et fiable… vous avez votre champion. (petit bémol, c’est aussi probablement le candidat sur lequel vous n’aurez pas le droit à l’erreur… mais on ne vit pas sans se mettre un peu en danger régulièrement 🙂 )

Une fois cette équipe choisie, ou construite, commencez à travailler. Gardez à l’esprit, tout le temps, que le cœur de DevOps, comme toujours, est l’humain et non uniquement les outils.

Le bon sens va dicter la seule chose à retenir de cet article . Je vais paraphraser quelqu’un qui a implémenté des organisation Agile/DEvOps multiples : “Nous avions démarré avec une population difficile, et nous leur avons donné des outils et méthodes modernes et intelligents. Ca n’en a pas fait une population moderne et intelligente.” Je dois admettre que la citation d’origine était plus… rude, mais je ne peux l’écrire ici 🙂

PS : J’essaye de garder ces articles à une taille raisonnable, et je ne fais pas de deep dive sur chaque sujet évoqué. Croyez-moi c’est volontaire, ce n’est pas uniquement de la flemme. Si vous voulez en savoir plus sur un sujet particulier, demandez-moi, ou bien trouvez un bon livre/article de référence!

A très bientôt!

DevOps transformation – choose your target wisely

This is a second post in what might become a series regarding DevOps, and DevOps transformation. Unfortunately for you, I speak my mind when I feel like it, so there is no master plan behind my ranting. First post was about choosing a strategy when transforming a managed services team towards DevOps.

This second step may not come necessarily after that first step 🙂 You get to choose.

In a way, I have the feeling that DevOps is close to what ITIL is : a toolbox where you can select which parts you would like to apply, and the way to implement them.

So new topic : how to target or build the team which will start the DevOps initiative in your organization?

There are several indicators that you can use to make this selection. None is an absolute, once again, these are pointers to which team would better succeed in applying DevOps principles. There is no sure shot, no magic finger method 🙂

The obvious criteria is to pick a team, of future team members that are already aware of DevOps, and willing to make the move. Of course these would be the people that will help you succeed in the first move, and show the rest of the world that it can be done, and bring very positive outcomes.

The second flag that should be raised is tied to one of the main outcome of DevOps : software delivery. If you have a team that is already struggling to get a reliable software delivery in place, and is willing to put the effort into building the organization and tools to get there, then you have a probable winner 🙂 On the opposite, if you try to convince a team that they need to move to DevOps when they are convinced their software is delivered efficiently and reliably, you’re going to hit a wall. Basically it would come down to convincing them that they are doing a poor job and are not even aware of that. Maybe not the right target for your first DevOps project.

The last one brings us to my favorite topic, outside of tech stuff : business outcome!

Of course, the aim of a transformation within your organization should always be mindful of the business outcome. Imagine you pick a team that is working on a neglected piece of software that no one cares about, and of which customers are just happy of the current situation. I do not think you would get the visibility and traction, not to mention willingness if you try to initiate your DevOps transformation in there. On the other hand, if you manage to get a team working on a new flagship product, that gets the attention of the CxOs, and has a need to show modern and reliable software delivery… you have a winner!

Once you’ve chosen your dream team, and start working, remember that DevOps, as always, is about people, not just tools.

The key thing to take away stems from common sense, and has been given by someone who did try and implement multiple Agile/DevOps organizations: “if you start with bad people and give them a smart way to work together, they won’t become smart by themselves”. Alright, I must admit the original quote was much harsher, but I cannot write it here 🙂

PS : I tend to keep these article short, and do not dive into each topic. This is done on purpose, not just by laziness. If you need to go deeper in each topic, just ask, or get a good read 🙂

La transfo DevOps – étape 1

Je sais, tout le monde parle de DevOps, à tort et à travers, mais parfois à raison. C’est un terme souvent utilisé pour redorer une image d’équipe ou de practice, et donner une touche sexy sur un jeu de diapositives. Je le vois souvent utilisé pour décrire ce qui n’est essentiellement que de l’automatisation dans une équipe Ops/infrastructure. C’est un bon début, mais ce n’est qu’un début, pas le voyage complet.

Néanmoins, ayant été acteur, parfois majeur, et témoin de plusieurs de ces transformations vers le DevOps, je voulais donner mon avis, à qui veut bien l’entendre. Ce que je vais dire va sûrement paraître trivial à certains d’entre vous, mais pourrait donner quelques indices à ceux qui se demandent où va le métier d’infogéreur.

Je parle de transformation DevOps, spécifiquement lorsque cette transformation touche une équipe de Managed Services/infogérance. C’est un sujet difficile dans ce contexte, car ces équipes doivent fournir un support moderne à leur client, qui sont parfois déjà organisés en mode DevOps, et même les aider à vivre cette transformation.

Je ne vais pas entrer dans les sujets contractuels et SLA, c’est un point très sensible et complexe. En tout cas, pas aujourd’hui.

J’ai pu observer deux façons d’approcher ce sujet. La première est une transformation complète et radicale de l’existant, pas de quartiers. La seconde est de construire une nouvelle équipe dédiée DevOps, en parallèle de l’existant.

J’ai seulement vécu la seconde méthode personnellement. Il s’agissait d’une opportunité car nous amenions tout un panel de nouvelles technologies et de clients dans une équipe d’infogérance existante. J’ai pu faire le choix de repartir d’une feuille blanche et de bâtir un ensemble d’outils et de méthodes pour desservir des nouveaux clients dans un nouveau modèle, en ne m’appuyant qu’au strict minimum sur l’existant. Cela nous a donné la possibilité d’être créatif et de démontrer la viabilité des nouvelles méthodes de travail et d’interaction avec nos clients.

La partie difficile a été l’adaptation aux services existants. Par exemple, nous avons du commencer en conservant les outils de supervision existants, car nous ne pouvions pas demander aux équipes de monitoring 24*7 de surveiller des outils et dashboards multiples. Notre succès sur les autres domaines (infrastructure as code, focus sur l’applicatif) nous a permis ensuite de driver un changement de plate-forme de supervision, quelques mois après les premiers pas. Et le mouvement, une fois lancé, a continué.

L’autre méthode, aka Big Bang, j’en ai été témoin. C’est une approche très disruptive, et qui ne peut pas être portée par n’importe qui. Il faut avoir un soutien de sa hiérarchie, jusqu’aux plus hauts niveaux, car l’implémentation va avoir des répercussions. Tout d’abord sur les équipes elles-mêmes, car tous les profils ne sont pas prêts à changer du jour au lendemain, même avec un accompagnement personnalisé. Ensuite sur le delivery et les clients, car eux non plus ne sont pas forcément convaincus, ou enchantés de subir les effets de bord de vos transformations internes.

Le côté très positif est par contre d’éviter d’avoir à gérer deux équipes en parallèle pour le même service au client. Et surtout de ne pas conserver de legacy très longtemps.

Je ne peux que vous suggérer deux lectures pour en savoir plus sur les enjeux de cette transformation : Phoenix project, qui est une version romancée d’une évolution DevOps, et The DevOps Handbook, qui donne les clés concrètes pour mener cette transformation.

La prochaine fois, je parlerais de comment il faut choisir la bonne cible, interne ou externe, pour démarrer ce voyage vers le monde merveilleux du DevOps.

DevOps transformation for Managed Services

I know, DevOps is still a buzzword. IT is often used to rebrand an old team or practice, and give more sexiness to a marketing slideset. I have seen it used to describe what is essentially an automation team within an Ops team. Good start, but missing the point.

Anyway, having been a major actor in a devops transformation, and witness to many, I wanted to give some advice to anyone out there patient enough to listen to me. I think most of what I am going to say will seem trivial, but it would help a few of us to put some words on what is happening to good ol’ outsourcing.

I am talking right now about DevOps transformation, but specifically when it happens to a Managed Services team, as in an outsourcing company, or an MSP. This is a difficult spot, as such teams should be able to provide support for DevOps organizations form their customers, and even help them.

I will skip the contract and SLA part, as it is a very tricky subject, at least for now.

I have seen two ways of approach the subject. First is full ahead transformation, no quarters, no mercy. The second is building a new team dedicated to DevOps, in parallel of the existing one.

I have only experienced the second first hand. It was an opportunity as we were bringing a new set of skills and customers into an existing managed services org. I chose to break from the past, and build a new set of tools and processes almost outside of the existing system. This creates the possibility to create and prove the viability of these new ways of working and interacting with your customers.

The difficult part is where you have to merge with the existing tools and processes. For example, we had to start with the monitoring tools we had, as we could not ask our 24*7 monitoring team to have multiple dashboards and tools. The fact that we were successful with the other tools and habits we developped allowed us to push for a new monitoring solution a few months after the initial move. And we kept the momentum after that 🙂

The other way I have witnessed, to transform the whole team at once, is challenging and cannot be carried by anyone on the team. I would advise that you start this path if you have a sufficient executive weight, or support from the executive team, because it will be a disruptive path. This is good, but the cost might be high, both in terms of people inside the team being disgruntled and maybe leaving, and in termes of your existing customers (and prospects) who might not understand what you are undetaking. The uptake is that you avoid having two different teams working with different mindsets and toolsets.

Obviously I would recommend reading the Devops Handbook, and the Phoenix Project, to get a basic understanding of what you are getting yourself into 🙂

Next up, I will try and help you target which team and/or customer would be a best fit to start your devops journey, stay tuned!

Le retour des chercheurs

Ce qui suit est une opinion personnelle, un ressenti de mon expérience, et peut ne pas refléter la réalité ou même le ressenti de l’ensemble de mes camardes, merci de ne pas leur en tenir rigueur 🙂

Lorsque j’ai débuté mon parcours professionnel, voire depuis mes études, nous avions une image assez négative des chercheurs en informatique. Ils étaient certes très intelligents, et avaient des connaissances approfondies, mais inutiles pour le quotidien. Savoir comment fonctionne un compilateur pouvait être passionnant,et servir dans quelques cas d’optimisation. De là à dire que c’était ce qui allait nous servir au quotidien…

Durant les 15 premières années de ce siècle, la tendance a perduré. Ce que j’ai pu observer autour de moi n’était pas très glorieux pour les chercheurs et universitaires.Nous les trouvions déconnectés de la réalité, perdus dans des théories ou sur des problématiques très éloignées des nôtres. Quelques frémissements se sont faits sentir dans certains domaines avec la montée en puissance des grands acteurs actuels, Google en tête. Les questions d’analyse sémantique et de volumétrie de données à traiter ont amené ces acteurs à travailler directement avec la recherche scientifique, car aucun produit sur étagère n’était prévu pour ce genre de cas.

Vu de mon fauteuil,cela aura été le début discret du changement que nous pouvons observer aujourd’hui. Les chercheurs sont sollicités, approchés, séduits. Nous avons besoin de leur vision en pointe, voire en avance sur la pointe, pour résoudre des problématiques spécifiques.

Ce qui a changé,selon moi, est l’état d’esprit, probablement poussé par les start-ups et la digitalisation massive. Nous sommes passés d’une approche “produit”(qu’est-ce que je peux faire avec ce que je connais) à une approche”solution métier” (que faut-il pour résoudre le problème posé par le business).

Et cela change tout.

Là où nous nous limitions à utiliser les capacités de quelques produits et à les mettre en service pour des fonctions prédéfinies, désormais nous sommes en mesure de creuser la problématique métier, qui n’a souvent rien à voir avec un problème IT. Cette problématique, nous la traduisons ensuite en critères techniques, et nous allons à la recherche du meilleur compromis pour résoudre la dite problématique. Et s’il le faut nous nous tournons vers les chercheurs.

Du côté des laboratoires, encore une fois selon moi, ce qui a changé en France est que ces équipes doivent maintenant aller chercher la plus grande part de leur budget dans des financements extérieurs. Et l’issue positive est que nous nous sommes rapprochés. Comme dans une belle histoire Disney de Noël (c’est de saison !),chacun a fait un pas vers l’autre et ensemble nous sommes plus forts. 😉

Le marché privé se rend compte que le mode de fonctionnement et de financement de la recherche publique est particulier. Le privé est capable d’entendre cela et de s’y adapter, car cela permet de créer des nouvelles solutions, avec l’appui des meilleurs cerveaux et technologies, même si elles n’existent pas encore.

Et la recherche publique a admis qu’elle devait travailler avec des projets peut-être plus précis, en termes de planning et d’objectifs, et surtout de ROI.

En bout de chaîne,on retrouve l’émergence des startups de type Deep Tech. Ces dernières sont des sociétés en cours de création qui associent un ou plusieurs chercheurs sur un sujet qui est très avancé et loin d’être industrialisé, et des gens business, qui sont capable de projeter les possibilités de cette technologie et d’en imaginer des usages. C’est l’association ultime de la recherche et du business !

Je l’ai beaucoup répété, cette analyse est issue d’un point de vue restreint, le mien, et ne reflète qu’une perception biaisée de la réalité. Je ne suis pas chercheur, je ne suis qu’un (presque) ingénieur infrastructure IT.