Je suis pas mal les nouveautés autour de l’IA et des agents. Parfois via le canal créateurs de contenu qui expérimentent beaucoup avec les agents. Ils testent les outils, partagent ce qui fonctionne, leurs use case, et ils inventent parfois de nouveaux mots pour décrire leurs façons de faire.

Et puis je suis tombé sur ce tweet de Peter Steinberger, le créateur d’OpenClaw :

Are we still talking loops or did we shift to graphs yet?

Peu de temps avant, je voyais du loop engineering partout. Maintenant, c’est le graph engineering qui commence à faire son apparition.

J’ai voulu comprendre un peu mieux ce qui se cachait derrière. Et je me suis dit : « Ah oui. On est en train de remettre des noms sur des choses que l’on connaît déjà assez bien. »

Pas exactement les mêmes choses, évidemment. Le contexte est nouveau, les outils aussi. Mais il y a comme un air de famille avec pas mal de pratiques tech et produit qui elles sont déjà ancrés depuis bien longtemps.

Avancer par petites étapes, encore et toujours

Le loop engineering, on pourrait dire que ça consiste à donner un objectif et des critères de réussite à un agent plutôt que de lui expliquer comment faire tout son travail. On lui donne un but à atteindre, pas une liste d’étape version notice IKEA. L’agent essaye, observe le résultat, corrige et recommence.

La première chose qui me vient, ce sont les tests d’acceptances. Forcément, il faut donner de bons critères de succès pour que l’agent sache de lui-même quand c’est est-ce qu’il a bien atteint son objectif.

Ça me fait penser aux boucles de feedback que l’on recherche partout quand on fabrique un produit ou du logiciel. On fait une petite chose, on vérifie si elle répond au besoin, on ajuste. Un test automatisé, une démo, un retour utilisateur, une revue de code, autant de façons d’apprendre avant d’avoir construit un gigantesque truc impossible à déplacer.

Ça me fait penser au quoi versus comment. Un PO ne va pas expliquer aux développeurs comment fabriquer la page de connexion. On explique autrement vers où on veut arriver, les collaborateurs ne sont pas de simples exécutants. On va donner de l’autonomie pour que l’équipe décide comment faire. Tiens, on pourrait penser aux OKR aussi.

Même idée avec le graph engineering. Au lieu de demander à un agent de réaliser une immense tâche dans son coin, on la découpe. On confie des responsabilités plus petites, on explicite ce qui dépend de quoi, on peut vérifier chaque morceau plus facilement.

Ça rappelle forcément le découpage d’un problème, les responsabilités bien séparées, les incréments livrables, les petites pull requests, … Bref, tout ce que l’on essaie de faire quand on veut garder un projet compréhensible et qui peut facilement évoluer.

On dirait que les agents aussi préfèrent qu’on évite de leur donner une mission du type : « Refais-moi toute l’application, et si tu as le temps pense aussi à la stratégie marketing. » Qui aurait pu prédire ? :)

Donner le bon contexte

Autre sujet que je vois revenir en permanence : le contexte.

Pour qu’un agent fasse correctement son travail, il faut lui donner les bonnes informations. Les objectifs, les contraintes, les exemples et contre-exemples, les fichiers utiles, la façon dont le projet est organisé, ce qui est acceptable ou non, des critères de succès, etc. Sinon, il devra deviner. Et quand une IA devine, elle le fait souvent avec une confiance assez impressionnante (les fameuses halucinations).

Là encore, ça me semble plutôt familier, et peut-être vous aussi.

Un nouveau développeur qui arrive dans une équipe, un collègue qui reprend un sujet, une personne à qui l’on délègue une tâche : tout le monde a besoin de contexte. Les décisions passées, le vocabulaire métier, les contraintes implicites, la définition de « c’est terminé ». Plus on explicite, plus on s’aligne, plus on travaillera efficacement ensemble.

Les fichiers d’instructions pour agents, les dossiers de contexte et les exemples de livrables sont peut-être de nouvelles façons de faire, mais le besoin qu’ils adressent est bien plus vieux : permettre à quelqu’un — ou quelque chose — de comprendre avant d’agir.

Rien de très neuf au final

Mon propos n’est pas de critiquer les personnes qui parlent de ces sujets, ou dire qu’elles n’inventent rien. Personne n’a la même histoire, le même… contexte. Je trouvais juste cette observation amusante, et j’avais envie de la partager.

Notre usage de l’IA et des agents nous faire (re)découvrir des partiques tech et produit, déjà existante. Sous une forme légèrement différente. Est-ce que l’IA remplacera nos jobs ? J’en sais rien. Mais on dirait que pour le moment, certaines façons de faire reste utile même si l’outil change. Et ça, c’est intéressant.

La culture tech et produit n’a pas pris un coup de vieux. Et c’est peut-être pour ça qu’elle était (et est toujours) pertinente.

On a envie d’associer les deux, d’avoir notre IA de poche. En tant que créateur d’applications mobiles (Product Owner, Développeur, Designer), on peut y participer !

J’en profite pour expliciter les différentes interactions qu’il peut y avoir avec l’IA sur un smartphone :

• Un utilisateur peut jouer avec l’IA du système qui est intégré dans divers composants pour par exemple reformuler une phrase, générer une image, faire une action, etc. Le développeur n’a pas la main dessus, c’est le système qui gère.
• Le développeur peut apprendre à l’IA du système comment interagir avec son application, en exposant certaines données et intentions. L’utilisateur pourra par exemple lancer une action réalisée par l’application via Siri.
• Le développeur peut créer des fonctionnalités boostées à l’IA au sein de son application. L’utilisateur pourra s’en servir depuis l’application.

Aujourd’hui, on va se concentrer sur le dernier cas : créer des fonctionnalités augmentées par l’IA. On va se donner un aperçu de ce que l’on pourrait faire dans nos applications et des options pour y arriver.

Quelques exemples d’usages

Ce que l’on voit le plus souvent, ce sont des fonctionnalités qui manipulent un contenu textuel déjà présent. On propose de résumer l’article actuellement affiché dans une application de news, par exemple. On pourrait aussi sélectionner un paragraphe et demander plus d’explications. Ou même traduire. On peut également proposer à l’utilisateur d’améliorer le contenu qu’il a créé - il pourrait reformuler, corriger, compléter.

Générer du contenu grâce aux données personnalisées est un autre usage intéressant. Une application de liste de courses pourrait par exemple proposer des idées de recette en fonction des aliments ajoutés par l’utilisateur. Peut-être même que des recommandations pourraient apparaître autour de la nutrition.

Et pourquoi pas un champ de texte voire un chat pour trouver et utiliser des fonctionnalités existantes dans l’application ? Sur une application complexe avec beaucoup de pages et de profondeur, ce pourrait être pratique. L’utilisateur pourrait demander de “réserver un aller-retour à Valence pour demain” ou “envoyer 100€ à ma mère” avec ses propres mots.

De nombreuses possibilités existent aussi du côté des jeux. En faisant varier des dialogues, ou en les créant pleinement. En générant des niveaux, des parties, des quiz. Peut-être même que l’utilisateur pourrait indiquer un thème, non prévu initialement, et le modèle d’IA ferait le reste. On commence tout juste à gratter la surface, à imaginer de nouveaux usages.

État des lieux

Les innovations et les possibilités qui tournent autour de l’IA vont vite (sauf chez Apple, qui a à la fois du retard et un cycle de release long - petite balle perdue gratuite :)). Où en est-on aujourd’hui ?

Commençons du côté de la pomme. Le flagship actuel est l’iPhone 16 Pro. iOS est en version 18.2.1. Apple Intelligence est disponible à partir de iOS 18.1 sur l’ensemble des modèles d’iPhone 16, ainsi que le 15 Pro et le 15 Pro Max. En Europe, on doit cependant attendre le mois d’avril pour accéder au système Apple Intelligence.

Sur Android, la dernière version est actuellement la 15 (API 35). Gemini est l’actuel modèle d’IA de Google, et d’autres constructeurs comme Samsung ajoutent aussi leur propre couche d’intelligence (Galaxy IA). Certains smartphones récents ont le droit à Gemini nano pour une exécution locale : c’est à partir du Google Pixel 8 Pro et Samsung S24, et d’autres appareils s’ajoutent progressivement.

Les deux systèmes proposent bien aux utilisateurs des fonctionnalités augmentées par l’IA. Mais côté développement, on est très limité pour créer. iOS ne propose que les App Intents pour faire découvrir nos applications à Siri et Spotlight. Et sur Android, Gemini nano est au stade expérimental. Il y a très peu d’appareils compatibles et les possibilités sont limitées.

À côté de cela, on voit d’autres solutions légères qui émergent pour être exécutées sur un smartphone. On trouve par exemple les ensembles de modèles Gemma de Google, Phi de Microsoft ou encore Llama de Meta. Ces trois familles de modèles sont d’ailleurs open-source. Plus étonnant, on trouve également des outils comme PicoLLM qui permettent de compresser les modèles !

Évidemment, tout ce que je raconte au-dessus changera avec le temps. Il y aura de nouveaux appareils, des nouvelles versions d’OS, des LLMs, etc. Un prochain rendez-vous que l’on peut prévoir : mai et juin pour les keynotes d’Apple et de Google, puis quelques temps après la sortie des nouvelles majeures d’OS.

Comment avoir accès à un modèle ?

Actuellement, pour créer des fonctionnalités augmentées par l’IA dans une application mobile, il faut interagir avec un modèle. On va créer des prompts adaptés à nos cas d’utilisations puis interpréter la réponse. Une réponse que l’on aura forcée dans un standard (du JSON par exemple).

Pour que notre application communique avec un modèle, nous avons plusieurs options.

Via notre serveur et une API tierce

C’est actuellement un des choix les plus répandus et les plus efficaces. Les applications mobiles ont déjà l’habitude de discuter avec des serveurs - on aura simplement de nouvelles routes pour obtenir des inférences. Notre serveur fait la passerelle vers OpenAI par exemple, et ce sont ces derniers qui hébergent le modèle.

Les intérêts sont multiples. On peut cibler tous les appareils (puissant ou entrée de gamme, récent ou vieux) et tous les systèmes (Android, iOS) peu importe la version (la toute dernière comme la plus vieille). Eh oui, il ne s’agit là que de requêtes HTTP et de stream de données.

On s’assure au passage d’avoir le même comportement entre les différents appareils et systèmes, puisque c’est le même modèle qui est utilisé en bout de chaîne. Les règles métiers et prompts sont aussi partagées. On pourra facilement et rapidement les modifier à distance sans mettre à jour les applications mobiles.

D’ailleurs, on peut aussi changer le modèle utilisé par un autre (une nouvelle version ou un concurrent) sans devoir redéployer notre application. Tout comme on pourrait utiliser plusieurs modèles en parallèle.

Le coût sera cependant élevé. La charge principale viendra de l’utilisation d’un service tiers comme OpenAI. Le coût augmentera selon deux vecteurs : le nombre d’utilisateurs et le nombre d’usages. En effet, les API tiers facturent au nombre de token généré pour l’utilisation de leurs LLMs.

C’est d’autant plus important que notre serveur agisse en tant qu’intermédiaire : une communication directe entre les applications et le service tiers impliquerait d’exposer en public nos clés d’APIs. Il serait alors très facile pour une personne d’utiliser nos clés, augmentant ainsi notre facture.

Quelques solutions : OpenAI, Anthropic, Gemini. On peut ajouter Firebase qui est une rare solution à proposer un accès direct (sans serveur) sécurisé à une LLM (Gemini en l’occurrence).

Via notre serveur qui héberge un modèle

Le second choix qui est également très répandu est celui d’héberger soi-même un modèle sur nos serveurs. On garde ainsi les avantages de passer par notre serveur (compatibilités avec tous les appareils, facilité de changement du modèle, utilisation de plusieurs modèles, …) tout en ayant plus de contrôle.

Un des aspects les plus intéressant concerne les données. En hébergeant un modèle open-source, on s’assure un meilleur contrôle sur nos données et la manière dont elles sont utilisées, et surtout par qui.

Le coût sera aussi maîtrisé différemment. Exit un prix au token via une API tierce, cette fois on paie l’hébergement du modèle.

Maintenant, comment choisir entre utiliser une API tierce et héberger un modèle ? Quelques insight possibles pour décider :

• passer par une API tierce pour prototyper rapidement, quand on est une petite entreprise, qu’il n’y a pas de données confidentielles.
• héberger un modèle quand on est une plus grande entreprise, quand on veut mieux contrôler l’usage des données.

Quelques solutions : Mistral qui est open-source et français, se balader sur le marketplace de Hugging Face.

En local avec les solutions natives

Il existe aujourd’hui des modèles plus légers qui peuvent fonctionner sur nos ordinateurs et nos téléphones, et certains appareils les intègrent par défaut. On peut donc les utiliser directement pour faire des inférences « on-device ».

Il y a plusieurs avantages à cette exécution locale. Premièrement, le coût. Il n’y en a tout simplement pas. Pas besoin de payer un service tiers ou d’héberger une solution existante, le modèle est déjà présent sur le téléphone. En fait, c’est l’utilisateur qui porte le coût : c’est la puissance de son smartphone, via sa puce et sa batterie, qui réalisera toutes les opérations. On pensera alors à ménager sa batterie.

Deuxièmement, la confidentialité. Le modèle étant sur l’appareil, les données sensibles n’ont pas besoin de transiter sur internet ou d’être lues par un serveur tiers. C’est une des promesses phares de ces modèles. On restera méfiant tout de même s’il faut utiliser des données très sensibles - l’inférence est peut-être locale, mais des logs et données pourraient très bien remonter à des serveurs.

La rapidité est un potentiel troisième avantage. L’inférence locale s’oppose à une inférence sur un serveur distant qui nécessite des aller-retour sur internet. La communication réseau prenant du temps, on tient là un gain intéressant. Je parlerais d’ailleurs plutôt de meilleure latence de réponse. D’une certaine manière, les serveurs d’OpenAI (par exemple) sont bien plus puissants que les puces de nos smartphones. Ce n’est pas l’inférence qui est plus rapide, mais plutôt le délai pour obtenir les réponses (grâce à des étapes en moins). À condition bien sûr d’avoir un smartphone haut de gamme.

Tient-on alors la solution parfaite ? Aujourd’hui en tout cas, on en est loin. On est très limité en termes de cibles compatibles. Il n’y a rien sur iOS, Apple ne permet pas de prompter avec son Apple Intelligence. C’est réalisable seulement sur Android, et même là, les smartphones disposant d’une solution intégrée (Gemini Nano) sont peu nombreux, récents, et chers. Le pourcentage d’utilisateurs que l’on pourrait atteindre est faible.

C’est également toujours marqué par Google comme expérimental, et selon les smartphones, le modèle n’est pas pleinement intégré par défaut, il faut effectuer quelques actions.

Un point d’attention qu’il faudra garder en tête le jour où les modèles embarqués seront plus répandus : leurs différences. Apple et Google proposeront chacun leurs solutions, et il sera difficile (impossible ?) de reproduire avec certitude les mêmes comportements.

scope.launch {
  // Single string input prompt
  val input = "I want you to act as an English proofreader. I will provide you
    texts, and I would like you to review them for any spelling, grammar, or
    punctuation errors. Once you have finished reviewing the text, provide me
    with any necessary corrections or suggestions for improving the text: These
    arent the droids your looking for."
  val response = generativeModel.generateContent(input)
  print(response.text)

  // Or multiple strings as input
  val response = generativeModel.generateContent(
  content {
    text("I want you to act as an English proofreader. I will provide you texts
      and I would like you to review them for any spelling, grammar, or
      punctuation errors.")
    text("Once you have finished reviewing the text, provide me with any
      necessary corrections or suggestions for improving the text:")
    text("These arent the droids your looking for.")
    }
  )
  print(response.text)
}

En local avec un modèle à intégrer

En attendant qu’une grande majorité des appareils Android et iOS embarquent au sein de leurs systèmes des modèles accessibles aux développeurs, une solution pour avoir une exécution locale serait d’intégrer soi-même un modèle existant dans l’application.

Ainsi, on peut théoriquement cibler bien plus d’appareils et de systèmes / versions ; tant que ceux-ci sont assez puissants. On garderait alors la plupart des avantages d’une inférence locale : la rapidité sur les bons appareils, la confidentialité, et le coût réduit.

Réduit, mais pas inexistant. Le modèle n’étant pas embarqué dans le système de l’appareil, il faut le rendre téléchargeable… et donc l’héberger. On aura un coût de stockage et de bande passante. La bonne nouvelle, c’est que le téléchargement ne doit se faire qu’une seule fois par l’utilisateur au moment où l’application en aura besoin. Chaque usage sera ensuite totalement local et n’aura pas d’impact sur les coûts.

Cette contrainte a un second désavantage : elle requiert un effort pour l’utilisateur. Il devra télécharger un modèle. Même si l’application fait tout le travail, l’utilisateur va devoir patienter - un modèle étant lourd. Il devra aussi réserver de la place sur son appareil pour stocker ce modèle. Modèle qui ne fonctionnera que sur cette application.

Imaginons que plusieurs applications optent pour cette solution, cela représenterait des gigaoctets de téléchargement et de stockage. Ce n’est pas viable.

Quelques solutions : Gemma de Google, Phi de Microsoft, Llama de Meta. PicoLLM pour la compression.

final gemma = FlutterGemmaPlugin.instance;

// Async response
String response = await gemma.getResponse(prompt: 'Tell me something interesting');
print(response);

// Stream response
gemma.getAsyncResponse(prompt: 'Tell me something interesting').listen((String? token) => print(token));

En bref

Les LLMs ne sont plus seulement utilisés à travers des applications de chat où l’utilisateur écrit des prompts. On est dans une phase d’exploration où beaucoup de possibilités restent à être imaginée et testée, mais des premiers usages existent déjà au sein d’applications mobiles.

Et cela va très vite. Les idées fusent, les PoC se multiplient, et les appareils avec des modèles on-device vont se répandre. Les fonctionnalités augmentées par l’IA pourraient devenir un incontournable. Il nous est déjà possible d’en créer, il ne tient qu’à nous d’explorer.

Je pense par exemple au flux que la story doit traverser, aux process, aux pratiques tech et produit, à la façon de communiquer et de collaborer, etc. On n’a peut-être pas besoin de faire constamment du discovery, des cadrages, des Event Storming. Peut-être que parfois les experts ont besoin de travailler tous ensemble alors que d’autres moments non.

C’est une idée qui m’est venu spontanément en route vers Reims pour visiter la cave aux coquillages - il n’y a aucun rapport, mais mon cerveau en avait décidé ainsi. J’ai divagué une partie du trajet dessus, j’aimais bien le cheminement que je faisais dans ma tête et les possibilités qui s’ouvraient. J’ai envie de partager ces réflexions pour continuer à les faire mûrir. Merci Nils pour nos premiers échanges ;)

Note : je parle de « user story » tout le long de l’article, par simplicité pour l’écriture, mais l’idée peut s’appliquer à d’autres unités ou éléments de travail comme une epic par exemple.

Un mot sur Cynefin

Derrière les 4 lieux que je citais (simple, compliqué, complexe, chaos) se cache Cynefin. C’est un modèle qui permet d’adapter la manière d’aborder un problème selon sa complexité pour mieux y répondre. Pour chacun des lieux, le modèle propose différentes manières de réagir, de décider, de communiquer. En se posant quelques questions « Est-ce qu’il y a une réponse ? Est-ce qu’on va réussir ? », en regardant où sont les inconnues, on peut situer la problématique dans un de ces lieux.

Je me souviens de la première fois que j’ai vu Cynefin en action. C’était lors d’un point sur la stratégie de notre communauté tech à BENEXT, il y a plusieurs années. Nils lança soudainement : « OK, on est en train de se dire qu’on ne sait pas si on y arrivera. Je pense qu’on est dans le domaine du complexe. Donc ça veut dire qu’il faut qu’on teste. On va arrêter de réfléchir et on va essayer des choses. ». J’ai trouvé ça génial.

Adapter sa manière de traiter les stories

Maintenant, regardons ce que ça pourrait donner avec la fabrication de logiciels, au moment où l’équipe se retrouve devant des user stories de différentes complexités - ce que veulent dire ces complexités, les comportements que l’équipe pourrait adopter, les pratiques.

Simple

Est-ce qu’il y a une réponse à ce problème ? Oui. Est-ce que nous la connaissons ? Oui. Dans le simple, on n’a pas d’inconnue. On sait comment on va faire cette story, techniquement et fonctionnellement. Faisons.

J’imagine une story qui a peu de règles métier, peu de particularités de design. Donnez-moi une story avec seulement un titre et une phrase en description, ça me suffit. Pas besoin d’un long cahier des charges, peut-être pas besoin de créer des maquettes non plus ; je privilégierai les discussions et l’instant présent.

Il y a principalement une collaboration entre le demandeur et le faiseur. PO et dev, par exemple. On communique beaucoup ensemble. Peut-être que le PO pourrait s’asseoir à côté de moi pour développer en direct ce morceau. On n’a pas besoin d’impliquer tous les autres devs, ou tout le produit, ou tous les designers.

Le “comment”, on sait faire. Il n’est pas nécessaire de réunir tous les experts (techniques, design, …) pour faire de la conception en amont, ou de multiples relectures et validations en aval. Je pourrais partir seul sur ce sujet, et il pourrait y avoir plusieurs sujets simples qui avancent en parallèle dans l’équipe sans problème.

Ça ne nécessite donc que peu de process et de pratiques en place. On est sur du léger. Après tout, c’est simple alors faisons simple aussi.

Compliqué

Est-ce qu’il y a une réponse ? Oui. Est-ce que nous la connaissons ? Non. Cette fois, il y aura besoin d’analyser et de chercher des réponses pour réaliser cette user story. On a des inconnues mais on trouvera.

Là, peut-être que les règles sont compliquées, nombreuses. Peut-être que j’ai besoin d’un jeu de données plus fourni, d’un environnement dédié, de maquettes. Peut-être que l’on peut découper ; sûrement même ! On va regarder. L’Example Mapping pourrait être une bonne pratique à intégrer pour à la fois bien comprendre les règles et découper.

Si la technique est compliquée, j’aurai davantage envie de travailler en groupe. Du pair-programming voire mob-programming. Peut-être qu’on fera une phase de conception technique ensemble, qu’on dessinera sur un tableau, qu’on déterminera des contrats d’interface.

Toute l’équipe se parle, on a besoin de beaucoup d’échanges et il faut que le cadre, l’organisation le permette. Je pense au passage à l’Event Storming, pour réunir toutes les bonnes personnes, pour s’aligner, pour comprendre notre système.

On va peut-être trouver plusieurs solutions. Et si on faisait de l’A/B testing ou du Feature Flagging ? Ça permettrait au passage d’éviter de se paralyser dans l’analyse - c’est le risque quand on est dans le compliqué, il faut en sortir à un moment et répondre au problème, livrer de la valeur. On pourrait aussi se timeboxer.

Complexe

Est-ce que c’est faisable ? Est-ce qu’on va réussir ? Probablement. Dans le complexe, l’incertitude est présente. Il y a des inconnues et on ne sait pas si on trouvera. C’est différent du compliqué où l’on sait qu’il y a une réponse - là, on a besoin d’explorer et de tester.

Peut-être qu’il y a trop de choses qui s’entremêlent, fonctionnellement ou techniquement, chez nous et/ou avec une autre équipe, un partenaire externe. On ne peut pas prédire les choses. On ne peut pas analyser ou découper non plus. Chercher à estimer le temps que prendrait cette story serait un non-sens. On est dans le complexe ! Les incertitudes et les inconnues nous entourent. Ici, il n’y a pas de liens de cause à effet clairs.

On veut explorer. Je pense à une phase de product discovery, des ateliers avec des utilisateurs, des user journeys. À l’Event Storming pour découvrir des domaines métiers.

On veut tester. Je pense à un Design Sprint. Je pense à toutes les techniques de développement pour tester en production également - A/B Testing pour essayer des variantes, Canary Release pour avoir un petit groupe d’early adopters, Feature Flag pour activer/désactiver facilement et rapidement. Une équipe capable de faire du déploiement en continu (CD) sera plus à l’aise pour lancer des expérimentations et s’adapter aux changements.

On va découvrir une partie des éléments seulement en faisant. On ne peut pas tout prévoir, il y a des choses qui n’apparaîtront que lorsque l’on fabriquera, qu’on aura les mains dedans. On peut se poser la question de ce que l’on peut essayer de faire maintenant, pour se mettre en marche. On a des dépendances externes et des inconnues ? On ne pourra pas tout planifier parfaitement, découvrons en chemin. C’est quoi les petites choses que l’on peut démarrer maintenant ?

Il faut de l’émergence. On va multiplier les expérimentations et on va se détacher du donneur d’ordre (on veut faire émerger !). Peut-être qu’on pète l’équipe, peut-être qu’on fait trois trios par exemple. On est lundi matin, mercredi on regarde ce que chaque trio a fait, ce qu’on a appris, ce qu’on teste ou met en prod.

Chaos

Un événement critique survient. Il surprend l’équipe, il déstabilise. Il était imprévisible. On est dans l’inconnu et on a peu de temps pour répondre, on a besoin d’agir maintenant.

Ce pourrait être le crash des applications, le serveur qui tombe, une fuite de données, une intrusion. Ça devient la priorité et on ne veut pas perdre de temps. On ne part pas en exploration ou en analyse.

D’abord, on règle le problème. On cherche une réponse rapide, pas parfaite. Quelques exemples d’options : on désactive la fonctionnalité grâce aux Feature Flags que l’on a mis en place. On redéploie la dernière release stable, on rollback. On corrige et on déploie un patch.

Après, une fois que le problème est réglé, on peut améliorer. Selon l’action que l’on a prise. Le correctif nécessite peut-être du refactoring, il nous faut peut-être une solution moins bricolée. Ou il faut réparer la release / la fonctionnalité, parce qu’on a juste rollback / désactivé via le feature flag.

On peut également analyser. Je pense à une rétrospective, un post-mortem. Qu’est-ce qu’on a appris ? Quelles pratiques sont apparues ? Qu’est-ce qu’il nous manquait ? Comment s’améliore-t-on pour la prochaine fois ?

On est plutôt sur un canal directif à l’apparition du problème. La personne qui fait le plus sens va donner la direction, l’action. « On fait ça maintenant et on fonce ». Mais on ne reste pas éternellement dans le command & control - le chaos se termine, on y sort.

Pour se préparer au chaos, on peut ajouter des pratiques pour réagir rapidement (pouvoir déployer une précédente release, désactiver les nouvelles fonctionnalités à distance, …) et pour mieux voir venir (monitoring, alerting, …). Et on peut aussi se plonger soi-même dans le chaos.

Je fais référence au Chaos Engineering. On provoque un chaos contrôlé pour s’immuniser (une notion dans Cynefin d’ailleurs !). L’équipe va apprendre à réagir en étant dans ce chaos et des pratiques émergeront pour mieux y faire face les prochaines fois. Un exemple connu est Netflix qui a testé sa résilience en faisant tomber volontairement ses serveurs. Le Chaos Monkey est né.

Pour autant, il reste difficile de prévoir le chaos. Il peut avoir plusieurs formes, il peut venir de partout. Je peux tester la résilience de mon infrastructure face aux serveurs de streaming qui tombent, mais, et si c’était les bases de données qui lâchaient ? Ou si le chaos était la fuite des utilisateurs, comment s’immuniser ? Quand est-ce que ça va arriver ? On ne sait pas.

Réflexions générales

Ce que j’aime beaucoup, c’est que ça aide l’équipe à réfléchir à comment elle va traiter les choses. Elle prend du recul et se pose des questions. Ça la pousse à s’adapter et à adapter ses processus - aucune raison de suivre toujours le même chemin, de sortir le bazooka pour tuer une mouche ou l’inverse d’aller en tong à la guerre.

Je parlais de user stories, mais on pourrait aussi bien faire l’exercice avec une granularité plus grande, comme une epic. On s’enlèverait des douleurs encore plus tôt. On pourrait voir qu’on a besoin d’explorer ce gros morceau par exemple, donc ne perdons pas de temps à spécifier maintenant. Ou quelque chose de plus vague comme une idée. Ah, c’est du simple, fonçons et testons en prod !

J’ai en tête des situations antérieures où l’équipe apportait une réponse inadaptée.

• Faire du compliqué et du complexe sur des sujets qui relevaient du simple. Ce qui donnait un mois de préparation (avec une longue discovery et beaucoup d’analyse, de prévision, de synchro) pour au final une après-midi de développement. Des frustrations sont nées de ce décalage entre le temps en amont et le temps utile à fabriquer.
• Faire du compliqué sur un sujet complexe. Malgré beaucoup d’analyses et de réunions techniques, il y a eu surprise sur surprise (ou découverte sur découverte ;)) à mesure que l’équipe avançait. De nouveaux imprévus chaque semaine qui remettaient en cause les prévisions. L’estimation de temps a explosé, le découpage ne convenait pas puisque c’était trop entremêlé, les spécifications tech changeaient. Beaucoup de douleurs à cause de choses virtuellement figées par l’équipe alors que dans le complexe, on découvre pendant qu’on fait. On ne peut pas être parfait et tout prévoir.

Je me dis que ça peut aider des équipes à essayer d’autres choses.

• Une équipe où tout le monde travaille toujours dans son coin pourrait repérer des sujets où il serait intéressant de se grouper, de faire du pair, de dessiner, de montrer, de partager, etc.
• Une équipe qui a un long flux de conception, beaucoup de travail de préparation et d’analyse, pourrait repérer progressivement des sujets simples pour alléger ses processus.
• Une équipe qui passe beaucoup d’énergie à estimer, seulement pour avoir le bon chiffre, pourrait se ramener à des questions plus utiles - est-ce qu’on peut découper ? Comment ? Faut-il explorer ?

J’aime bien toutes ces questions que le modèle peut ouvrir, les discussions et les changements qui peuvent en découler. L’étiquette au final, on s’en fout. C’est ce qu’on fera qui sera intéressant.

Je suis très preneur d’avoir des retours si vous l’essayez ou le challengez, pour savoir comment vous vous l’approprierez, ce que vous adapteriez, ce que ça provoque dans l’équipe, etc.

Je remercie à nouveau Nils pour nos discussions et j’en profite pour recommander son article et son meetup à ceux qui voudraient creuser le modèle Cynefin.

J’ai été invité par Fleur Saillofest à speaker dans le meetup Beyond Scrum Mastering. Très rapidement, une trame intéressante a émergé lors de nos échanges : celle de reconnaître des problèmes au sein de l’équipe et y associer certaines pratiques tech qui pourraient aider.

Observer ce qu’il se passe dans l’équipe, entendre les râlements, les plaintes, noter les douleurs, c’est à la portée de tout le monde. J’ai pris un fil rouge avec des problèmes qu’une équipe peut rencontrer à diverses étapes de la conception du produit pour introduire certaines pratiques techs. Autour du besoin, du code, des tests, de la livraison, de l’existant, etc.

Est-ce que ce sont les seules possibilités ? Non. Mon but n’est pas d’être exhaustif ni sur les problèmes ni sur les solutions et les pratiques. Mais plutôt d’entrevoir des possibilités, de donner des billes pour ensuite aller creuser plus en profondeur avec l’équipe. Je dépose quelques brides de réflexion dans cet article qui m’ont permis de créer mon talk (slides ici).

Collaborer sur le besoin

• Les refinements sont chiants.
• On se rend compte pendant le sprint que les besoins ne sont pas clairs. Les développeurs demandent au PO des spécifications hyper détaillées avant de commencer.
• Le PO change d’avis, on fait ce qu’il y a écrit dans la story mais il dit que ce n’était pas ça qu’il voulait.

Les premiers problèmes peuvent arriver très tôt, dès l’expression du besoin, avant même d’être purement dans la tech, dans le code. On peut noter qu’il semble y avoir de l’incompréhension, qu’il y a probablement des choses implicites, des modèles mentaux différents. Que tous les membres de l’équipe ne sont pas vraiment impliqués.

Example Mapping

Une piste d’amélioration serait de faire collaborer toute l’équipe, ensemble, sur la rédaction du besoin. Je pense naturellement à l’Example Mapping. C’est un atelier qui réunit l’ensemble de l’équipe (PO, QA, Dev front/back). Le PO vient avec ses règles métiers et toute l’équipe œuvrera à créer des exemples précis pour chaque règle.

Tout le monde est impliqué, participe, et s’approprie le besoin. Les règles sont éclaircies, les exemples sont concrets et parlent à tous. L’implicite est rendu explicite, on sort ce qu’il y a de la tête du PO. Des questions peuvent émerger, avec des points à éclaircir avant de commencer le développement. On peut aussi trouver un découpage plus fin de la story.

Ce n’est plus à la seule charge du PO d’écrire un immense cahier des charges qui sera de toute façon probablement imparfait et jamais satisfaisant. Les développeurs ne restent pas passifs avec des pavés à avaler. On fait jouer l’intelligence collective en amont pour co-créer quelque chose de meilleur.

Collaborer sur le code / Git

• J’entends parler de branches, merge, commit, conflits, … Je suis perdu.
• C’est quoi ce git machin chose ?

Je dédierais un article pour vulgariser l’utilisation de git qu’en ont les développeurs. Je me limiterais à quelques lignes ici pour comprendre l’origine de certains problèmes. Git est un outil pour gérer les versions du code source.

Un développeur va créer un commit avec des changements ; c’est une copie à un instant T du code. Il va travailler sur une branche ; c’est un espace indépendant, avec ses propres copies.

Au bout d’un moment, lorsqu’il aura terminé, il va vouloir merge ; il veut réunir son travail réalisé sur sa branche (dans son espace indépendant) vers la branche principale (l’espace commun). Pour cela, il va ouvrir une Pull/Merge Request et demander à quelqu’un de faire de la revue de code ; une personne va relire toutes les modifications, pour approuver ou faire des retours.

Au moment de réunir, il peut y avoir des conflits ; dans son espace, il a modifié des zones qui ont aussi été modifiées sur l’espace commun. Il faudra résoudre ces problèmes afin de pouvoir rassembler les travaux. Qu’est-ce qu’on garde ? Qu’est-ce qui n’a plus de sens ? Qu’est-ce qu’il faut adapter ?

Plus longtemps on travaille sur une branche (dans son coin) et plus on attend pour réunir avec la branche principale (avec les autres), plus on augmente les problèmes. Par exemple, la quantité de changements et le temps qui s’allonge augmentent le risque de conflits et demandent une plus longue revue de code.

Collaborer sur le code / Revue de code

• J’en ai marre de devoir refaire plusieurs fois mon code après des aller-retours sur la code review.
• Les développeurs se plaignent que les revues de codes sont longues à faire et pas intéressantes.
• On attends longtemps avant qu’un autre développeur fasse la revue de code.

Ahhh, la revue de code, serait-ce le mal du siècle des développeurs après le mal de dos ? J’exagère un peu - j’avais envie d’écrire cette tournure humoristique - mais j’ai tout de même souvent observé des symptômes autour de la revue de code. Il faut dire aussi que c’est une pratique qui s’est très largement répandue dans les équipes. Pour autant, elle n’est pas toujours bien appliquée et elle vient avec son lot de contraintes.

Par nature, la revue de code via une Pull/Merge Request est asynchrone - la relecture arrivera un temps après la demande, qui nécessitera des changements qui seront faits un autre temps après, et ainsi de suite. Il y aura des changements de contexte, de la part du relecteur et de l’auteur. Et on sait que les changements de contexte nuisent à la productivité. On est interrompu, on sort constamment du flow (qui est long à trouver).

Le feedback est tardif. La revue est très souvent ouverte lorsque la story est entièrement terminée (rappel git : quand on veut réunir nos changements avec la branche principale). Les changements seront plus coûteux. La revue est parfois bâclée. Certains lisent rapidement en diagonal parce qu’ils n’ont pas le temps ou que ça ne les intéressent pas. D’autres vont pinailler, mais seulement sur des points insignifiants.

Ce peut être un goulot d’étranglement qui allonge la durée nécessaire pour livrer une fonctionnalité. C’est marquant lorsqu’il y a beaucoup de développeurs ou lorsque la responsabilité de la revue n’est donnée qu’à une poignée de personnes (par exemple, seul le lead/référent/manager).

Bien sûr, ce n’est pas tout noir. La revue de code peut être bien faite et a pour sa défense deux principaux bénéfices : c’est une occasion de donner du feedback pour améliorer le code et réduire les bugs, et c’est une façon de partager de la connaissance en lisant le code d’un autre.

Ok, on parle de feedback et d’apprentissage, comment pourrait-on faire mieux ? Avec un échange direct, temps réel. Avec de la mise en pratique plutôt que de la lecture passive. Avec du Pair Programming et du Mob Programming. On forme une équipe, on est ensemble, on peut faire mieux sur la collaboration. Les process de Pull/Merge Request ont davantage de sens dans le monde de l’open-source où les personnes ne se connaissent pas, ne travaillent pas ensemble, où il faut contrôler.

Pair Programming

Le Pair Programming est une pratique qui va permettre une réelle collaboration de deux personnes. On se met ensemble, sur un même problème, avec un seul ordinateur, en même temps. On échange pour trouver la solution et écrire du code. On échange pour s’améliorer en continu. Il y a une réflexion commune, deux cerveaux qui vont se challenger.

Ici, le feedback est immédiat. Je propose au plus tôt une autre approche de conception à mon pair. Je découvre une fonction plus performante au moment où j’écris ma ligne de code grâce au conseil de mon pair. On repère ce bug pendant qu’on développe la fonctionnalité ensemble. Maintenant tout de suite, pas après 5 jours de travail.

La transmission de connaissances, autant technique que fonctionnelle, est forte. Les deux développeurs travaillent ensemble au même moment. Ce meilleur pattern pour faire le traitement, je le découvre en direct voire je le mets en place moi-même. On donne en effet le clavier au non-sachant, afin de le faire pratiquer tout en le guidant. Ce scope fonctionnel, on l’aura co-créée, je le comprendrais, mon pair n’est plus le seul de l’équipe à pouvoir y travailler. C’est très efficace pour onboarder un nouvel arrivant aussi.

C’est en ça que la pair programming est puissant et ne divise pas l’efficacité par deux, il faut voir au-delà de “deux ressources qui travaillent sur un seul problème”.

Mob Programming

Le Mob Programming se trouve un cran après le Pair Programming : c’est tout un groupe qui va collaborer, en même temps, sur un seul et même problème, avec un seul ordinateur. L’intelligence collective va mener à une meilleure compréhension du problème et à une meilleure conception de la solution. Encore une fois, ce n’est pas simplement grouper un tas de personnes pour qu’elles regardent un seul développeur tout faire.

Le problème et les solutions sont discutés et challengés. Le groupe entier s’approprie le code et la fonctionnalité, tout le monde avance ensemble. On peut arriver à tacler des problèmes très complexes. Il y a une très forte transmission de connaissances et de compétences. C’est tout un groupe qui apprendra, en pratiquant, cette nouvelle technique ou cette fonctionnalité.

Note : on parle d’avoir un seul ordinateur, un seul clavier en pair et mob programming. C’est parfaitement compatible à distance avec des solutions de partage d’écran, de contrôle du clavier, de code collaboratif.

Collaborer sur le code / Conflits

• Le dev est terminé localement mais ça met beaucoup de temps à être livré car on a plein de conflits.
• La fonctionnalité marche sur ma branche mais maintenant que c’est mergé c’est cassé.

Intégration Continue

Parfois, quand on parle d’Intégration Continue, on entends Jenkins, gitlab-ci, pipelines, machine de builds, etc. Ce n’est pas ça, l’Intégration Continue. Tout ça, ce sont des outils. C’est du comment.

L’Intégration Continue, c’est d’abord un principe, une attitude. C’est rassembler très souvent les changements sur la branche principale (intégrer continuellement). On partage à tous nos changements plusieurs fois par jour ; plutôt que d’attendre de tout finir et de rassembler après 8 jours de travail intense.

Qu’est-ce que ça apporte ? Un cercle vertueux. On va faire de plus petites étapes pour rassembler plus souvent. On va faire de meilleurs tests automatisés pour s’assurer que tout est bon. Naturellement, on aura moins de conflits et de problèmes avec de petites modifications ayant une durée de vie courte.

Pair/Mob Programming

On l’a vu précédemment, le Pair et le Mob Programming permettent une réelle collaboration de plusieurs personnes. La communication est meilleure, puisqu’elle est immédiate et continue. Il y a moins de travaux simultanés en cours, puisque les développeurs se réunissent pour travailler sur le même sujet. Tout ça contribue à diminuer les risques de conflits et de problèmes de merge.

Écrire le code

• On a fait évolué l’écran recherche, et on a vu plus tard en prod que la logique métier du compte est complètement KO.
• On planifie de passer une après midi sur l’écriture de tests, on fait comment pour le prendre en compte dans la vélocité ?

Tests Unitaires

Il est important de clarifier ce que sont les tests unitaires et pourquoi on en écrit. Très simplement, un test unitaire est un test automatisé d’un scénario fonctionnel. C’est quelque chose qui vérifie que du code se comporte comme prévu, automatiquement, sans intervention humaine. C’est un programme qui lance un autre programme pour vérifier ce qu’il se passe dans différentes conditions.

On parle de comportement, de scénario fonctionnel : quand on écrit un test unitaire, on veut s’assurer de bien retranscrire le métier. C’est en ça qu’il est très important et utile pour le business, et que ce n’est pas seulement un élément technique.

Progressivement, on créé un filet de sécurité pour éviter certaines régressions. On diminue le risque d’avoir des bugs en production : on aura un feedback immédiat, pendant le développement, si une règle métier est cassée après un changement dans le code.

C’est au moment où l’on change le code que l’on sait si on altère involontairement le comportement, pas plusieurs jours après. Ce qui fait que les tests unitaires jouent un rôle essentiel au Refactoring, pour améliorer le code sereinement.

Test-Driven Development

Quand on écrit un test, une bonne pratique est de le faire au plus près du moment où l’on a écrit le code, et non pas bien après une fois que tout est terminé. Pourquoi ? Parce que c’est plus coûteux et difficile de le faire après ; le code n’ayant pas forcément été conçu pour être testable. Et parce qu’on passe à côté d’un bénéfice important : se faire guider par le test.

Et c’est la philosophie du Test-Driven Development. Ce n’est pas “écrire le test en premier” (c’est du comment). C’est se faire guider par les tests et par le métier. On définit le comportement que l’on veut obtenir (le test) puis on fait émerger la solution et on l’améliore.

On a une boucle de feedback extrêmement rapide. Quand on développe la solution, le test nous indique en quelques millisecondes si le comportement voulu est bien retranscrit.

À noter que l’écriture des tests unitaires et la pratique du TDD font partie intégrante du job de développeur et que ce n’est pas forcément plus long de tester. Au contraire, ça nous aide. C’est à faire dès qu’il y en a le besoin, en continu, il n’y a pas de permission à demander, de journées à dédier.

Livrer

• C’est douloureux de livrer, c’est long, il y a un tas de process et d’actions à faire…
• On va s’assurer d’avoir suffisamment de choses dans la release pour livrer. C’est long alors il faut que ça vaille le coup.
• On ne livre pas le vendredi. On ne peut rien modifier en août et fin décembre. On a un code freeze pendant les périodes avec beaucoup de vacances.

Automatisation

Créer une archive de l’application et l’envoyer sur un serveur, générer le fichier de traduction à partir d’une feuille Excel, remplacer toutes les majuscules d’un fichier brut par des minuscules et le transformer en JSON, … Ce sont des exemples de tâches manuelles qui gagneraient à être automatisées.

La bonne nouvelle ? Un développeur est bien placé pour automatiser, il est capable d’écrire du code pour créer un programme qui va effectuer ces tâches. Une fois créé, il n’y a plus qu’à exécuter ce programme et la tâche sera réalisée (souvent) immédiatement plutôt que de prendre trop de temps à une personne. On s’enlève au passage le risque d’erreur humaine : le programme fera toujours la même chose, il ne va pas oublier une ligne, il ne va pas se tromper de caractère, etc.

Outre l’efficacité, je trouve que c’est bien plus intéressant à faire. On conçoit un programme, on réfléchit plutôt que de répéter des tâches rébarbatives.

Livraison Continue

Le principe est simple, chaque changement sur la branche principale est livré. C’est livré dans un environnement de staging/test/preprod, ou même de production, mais ce n’est pas déployé. Ce n’est pas encore dans les mains des utilisateurs.

Autrement dit, avec la Livraison Continue, il suffit d’un simple bouton pour déployer aux utilisateurs, il n’y a pas besoin d’autres interventions. Tout est déjà prêt, on est capable de déployer sur demande. Plusieurs fois par semaine, jour, heure, etc.

Ça ne veut pas dire qu’on va forcément livrer chaque heure. Si on est capable de livrer toutes les heures, on est capable de livrer quand on veut. Et c’est ça que l’on recherche. Le déploiement devient un non-sujet. On pourra bénéficier des avantages de livrer souvent et rapidement de petits incréments, dès que cela fait sens.

Pour livrer en continu, on va mettre en place certains outils, on va automatiser des tâches, et on va s’atteler à toujours avoir un code dans un état déployable.

Déploiement Continu

Ici, on va un cran plus loin : tout est automatisé, il n’y a plus aucune intervention humaine. Chaque modification sur la branche principale est déployée en production et arrive directement dans les mains des utilisateurs.

En mettant en place la Livraison Continue ou le Déploiement Continu, on entre dans un cercle vertueux de pratiques. On se concentrera davantage sur la qualité, sur les tests automatisés, sur la création de petits incréments, sur l’activation à distance de fonctionnalités, … plutôt que sur des pratiques contraignantes comme mettre un freeze de code, avoir une semaine de tests de non-régression, avoir 4 niveaux de validations de chefferie, etc. Ce qui fera livrer moins souvent, donc il faudra faire encore plus attention, donc livrer moins donc faire plus attention, et ainsi de suite, un cercle vicieux de peur et de contrôle.

Améliorer un existant

• *On a des problèmes de qualité dont on n’a jamais le temps de s’occuper. *
• Mon équipe veut négocier un sprint ou deux de refactoring mais je ne sais pas quelle valeur ça va apporter.
• J’ai un développeur qui fait du refactoring depuis 3 mois, c’est pas encore fini mais il avance.

Refactoring

Faire du Refactoring, c’est changer le code sans casser son comportement observable. On améliore le code dans le but de mieux le comprendre ou de faciliter le changement, par exemple. Le code fera toujours la même chose. Si je fais du refactoring sur une fonctionnalité de recherche, elle fera toujours de la recherche, ni plus, ni moins.

Autre aspect très important du refactoring : on avance par petites étapes. On enchaîne une série d’améliorations, de petites étapes que l’on peut partager régulièrement. Le projet est toujours dans un bon état, on peut s’arrêter à tout moment.

C’est différent de “tout refaire”, à ne pas confondre avec la réécriture. Ce n’est pas ce fameux chantier de 3 mois en tunnel où rien ne fonctionne entre temps. Le refactoring demande de la discipline et des compétences.

Refactoring opportuniste

On fait du refactoring quotidiennement, toutes les occasions sont bonnes. J’ouvre un fichier où je vais devoir travailler, mais le changement est difficile ? Le code est legacy ? J’en profite pour faire un petit refactoring en amont plutôt que d’empirer. On peut évoquer la règle de Boy Scout :

Toujours laisser le code dans un meilleur état que celui dans lequel vous l'avez trouvé.

On préférera agir régulièrement et de manière opportuniste plutôt que de bloquer des jours/semaines dédiés au refactoring. Tout comme les tests, ça fait partie intégrante du job de développeur. Il est important de faire du refactoring régulièrement et de se former. D’ailleurs, au lieu de bloquer des jours pour faire du refactoring, peut-être le transformer en un temps pour se former et s’améliorer dans les techniques de refactoring ?

Théorie de la vitre brisée

On veut faire du refactoring régulièrement pour améliorer le code continuellement. On veut éviter que la situation ne s’empire, on veut y remédier au plus tôt. La théorie de la vitre brisée est intéressante pour expliquer pourquoi on veut agir vite et régulièrement.

Prenons par exemple une maison avec une fenêtre brisée. La théorie nous indique que si on ne fait rien, on laisse penser que la maison est à l’abandon. On va alors attirer et cumuler d’autres problèmes, des graffitis, de nouvelles fenêtres brisées, etc. Un cercle vicieux démarre et qui ira au-delà de la maison, apportant plus de criminalités dans le quartier.

Il faut remédier aux problèmes au plus vite, avant qu’ils ne soient trop nombreux. Un quartier où les maisons sont constamment bien entretenues attirera moins les problèmes. C’est la même chose avec le code, on va vouloir rester dans un état d’esprit de qualité.

Méthode Mikado

La méthode mikado est très utile pour faire du refactoring. C’est une méthode pour effectuer de grands changements avec de petites étapes. On veut atteindre un objectif, qui peut être ambitieux, on ne sait pas encore comment y aller, mais on va construire ce chemin progressivement.

On va effectuer une suite de petites expérimentations. Quand une expérimentation réussie, on a avancé vers notre objectif, avec une petite étape. Quand une expérimentation échoue, on revient en arrière, on a appris quelque chose, et on découvre qu’il faut effectuer une autre petite étape nécessaire en amont. On dessine d’ailleurs un graphe pour visualiser notre progression et nos pré-requis.

De fait, on est toujours dans un état fonctionnel, on peut s’arrêter à tout moment. On n’aura peut-être pas atteint l’objectif, mais ce sera mieux, on sera plus proche de la fin, on aura réalisé quelques petites étapes, et ça fonctionnera toujours.

Bref

On a vu un ensemble de pratiques tech reconnues dans l’industrie. On a vu comment elles peuvent aider dans certains problèmes. Et même au-delà. Ce sont des pratiques pour améliorer le quotidien de l’équipe et devenir meilleur dans la technique et dans le business.

On a aujourd’hui le recul nécessaire et les études pour voir la corrélation entre la performance technique et business. Pour répondre rapidement aux besoins de l’utilisateur, on a besoin de pouvoir livrer rapidement. Changer facilement le code permet de changer facilement de direction fonctionnelle.

J’ai présenté certains éléments dans mon précédent article, ici je ferais une liste plus complète afin d’avoir une vision globale et rapide de ce qu’on peut utiliser. On pourra ensuite voir les interactions entre les éléments. Individuellement, chaque ingrédient apporte un type d’information, mais ensemble, ils forment un tout et agissent sur les autres.

Les différents éléments

Domain Event / Événement

Avec les événements, on construit la colonne vertébrale. C’est ce qu’il se passe dans notre système. Les événements sont décrits par un verbe au participe passé. « Facture générée », « Commande livrée ». C’est quelque chose qui a eu lieu. C’est très important. On veut forcer les participants à penser avec des actions achevées, des changements d’état, des choses qui peuvent agir comme un déclencheur pour une autre action.

Les événements forment la base de l’Event Storming, tout tourne autour des événements. C’est compréhensible par le métier, par tout le monde. On peut raconter une histoire avec. On aura forcément les événements dans cet atelier, et on commence d’ailleurs par cette étape.

Actor / Acteur

Les acteurs interagissent avec le système, ils déclenchent des commandes. Ils initient une action qui va produire un événement. Ce peut être un utilisateur ou une partie d’un logiciel, un système. On essaie d’être assez précis avec la dénomination de l’acteur, de représenter ce qu’il est vraiment, son nom, son rôle. « Le client », « Le livreur », « Le système Y ». On utilise très souvent les acteurs car on veut visualiser qui fait quoi.

External System / Système Externe

Ce sont les dépendances. On veut visualiser ce qui est à l’extérieur de notre système, ce qu’on ne gère pas. On veut aussi voir apparaître les adhérences auxquels est soumis le système, ce qui le contraint, les goulots d’étranglement. « Le fournisseur », « Service Z ». Tout comme les acteurs, on veut voir qui fait quoi, et cette fois-ci, on a une information supplémentaire - c’est quelque chose d’extérieur.

Command / Commande

La commande est le déclencheur d’un événement, souvent une conséquence d’une action utilisateur, une prise de décision d’un acteur ou d’un système externe. On parle de l’action réalisée qui sera le déclencheur d’un ou plusieurs événements avec un verbe à l’infinitif. « Ajouter au panier ». Il n’y a pas forcément une commande sur chaque événement.

Avec les commandes, on commence à être plus précis sur le processus et on se projette également un peu dans le code.

Policy / Règle

Une Policy permet de rendre explicite une règle métier. C’est la glu qui lie un événement et une commande. Avec une Policy, on représente des commandes qui sont exécutées suite à un événement et selon une condition précise. En général, on décrit une Policy avec Lorsque ... alors ... : « Lorsque le paiement dépasse 500 €, alors il faut envoyer un SMS à l’utilisateur ».

Les Policies peuvent être présentent dans un système, qui gère cette règle lorsque l’événement correspondant se produit. Ce peut également être un humain qui agit lorsqu’un événement se passe. Par exemple, « Lorsqu’une fraude est détectée, alors il faut appeler le client ». C’est un processus humain. Dans ce cas-là, on peut ajouter un post-it acteur sur la Policy pour représenter la personne.

Read Model / Données

Il y a une nuance importante dans le nom anglais, Read Model. On va parler des données que l’on affiche et qui vont aider les acteurs à prendre des décisions. On ne parle pas des données que l’on écrit (écriture dans une base, un registre…), ces informations sont déjà indiquées dans les commandes comme « Ajouter (l’article) au panier ».

On y écrit les données principales. « Nom, Prénom, Email ». On se limite pour mettre en valeur ce qui compte réellement.

Aggregate / Agrégat

Les agrégats vont apporter une vision bien plus micro et être très proche du code. Pour paraphraser Martin Fowler, un agrégat est un regroupement d’objets du domaine qui peuvent être manipulés comme un seul objet. C’est un pattern qui vient du Domain-Driven Design.

Ce regroupement a du sens pour le métier. On préfèrera manipuler l’agrégat plutôt que chaque objets individuellement - ces objets sont cohérents s’ils sont manipulés ensemble. Dans l’exemple du e-commerce, on peut imaginer un agrégat « Panier » qui contiendrait plusieurs objets « Article » et un objet « Promotion ».

L’intérêt en faisant émerger les agrégats avant de se plonger dans le code va être de visualiser où ils se retrouvent, s’il n’y a pas trop d’événements ou commandes autour d’un même agrégat.

Hot Spot / Point d’attention

Tout au long de l’atelier, on peut marquer les désaccords, les questions, les risques, etc. Ça fait partie du modèle. On peut marquer tout ce qui s’éloigne du scénario nominal pour rester concentré. Ce seront des éléments à creuser plus tard. « Attention RGPD », « Que fait X ? », « Risque de fraude de paiement ». On veut également les visualiser pour mettre en lumière les zones d’ombres, les questions, les problèmes. On agira peut-être là-dessus suite à l’atelier.

Déclencheur temporel

Le temps est parfois aussi un déclencheur d’action. Par exemple, une sauvegarde qui doit être réalisée toutes les heures. On marquera alors simplement « Toutes les heures » sur le post-it. Ce sera le déclencheur d’une commande ou d’un événement visant à créer une sauvegarde.

Bounded Context / Contexte borné

Une fois la modélisation du système bien avancé, dessiner les Bounded Context va permettre de définir les contours des domaines et sous-domaines métiers. En les identifiant, en les explicitant, on veut faire émerger des périmètres métier cohérent, des services, des ensembles de fonctionnalités, des contextes à l’intérieur desquels les objets, les mots, le vocabulaire auront un sens important. On peut aussi visualiser comment ils interagissent entre eux.

Dans une plateforme d’e-commerce, on pourrait imaginer plusieurs contextes : le service client, le service achats, le service livraison. Le terme « client » n’a peut-être pas la même signification au sein des trois services. Peut-être même que le terme est différent, le service livraison pourrait parler de « destinataire ».

Les interactions entre les éléments

Individuellement, tous ces éléments sont simples et apportent un niveau de compréhension différent. L’acteur informe sur qui prends la décision, l’événement indique ce qu’il s’est passé.

Ensemble, ils forment un tout. Ils se complètent, et certains ont une interaction directe entre eux. Quand un acteur agit, il déclenche une commande. Quand une commande est exécutée dans un système, un événement se produit.

Je trouve intéressant de voir comment chaque élément se comporte avec les autres et ce schéma (venant d’Alberto Brandolini, le créateur), le représente bien. C’est intéressant pour la compréhension de l’Event Storming, pour modéliser, et aussi pour concevoir plus tard le logiciel.

Une commande est exécutée. « Ajouter l’article au panier ». Une décision a été prise, il y a une action, quelque chose doit se passer. Cette commande se produit dans un système. Ce peut être le nôtre, auquel cas elle agira sur un agrégat. « On ajoute un Article au Panier, on applique éventuellement une Promotion, on recalcule un prix total ». Ou ce peut être dans un système externe.

Par l’action de cette commande, le système en question génère un événement. « Article ajouté ». Cette fois-ci, ça a eu lieu, l’histoire a évolué. Il s’est passé quelque chose dans le système.

Avec cet événement, un état a changé. On peut projeter de nouvelles données « il y a 5 articles dans le panier, le nouveau prix total est de 343 euros » et les afficher dans une nouvelle interface graphique.

L’événement peut déclencher une règle, une Policy. Le système réagit à cet événement si une condition particulière est rencontrée. « Lorsque le panier contient 5 articles, alors une réduction de 20% est appliquée sur l’article le moins cher ». Une commande est alors exécutée. « Appliquer la promotion ».

Qui d’autre peut être à l’origine d’une commande ? Un acteur. « Le client » a lancé la commande « Ajouter l’article au panier ». C’est lui qui a pris la décision, qui a agi.

Une commande est donc exécutée par un acteur ou par une règle provenant d’un système. Qui produira un événement. Et ainsi de suite. La boucle est bouclée.

C’est un atelier qui peut s’utiliser dans n’importe quel domaine et pas seulement dans le monde du logiciel (même si son créateur, Alberto Brandolini, est un développeur). On pourrait modéliser le fonctionnement d’une équipe de RHs tout comme le parcours d’achat d’une application.

Les événements forment la colonne vertébrale de L’Event Storming. On parle de ce qu’il se passe dans le processus, dans le système, sur une ligne de temps. On peut le raconter, c’est une histoire. Le storytelling est un aspect très puissant de cet atelier.

C’est en plus modulable : on peut ajouter différentes étapes qui feront naître de nouvelles conversations selon le besoin. On pourrait par exemple introduire les acteurs qui agissent sur le système ou les dépendances externes. On peut s’adapter en fonction du niveau d’abstraction que l’on souhaite avoir, d’une vision très macro à une vision très micro sur un bout de logiciel.

Pour autant, l’Event Storming reste simple, ce qui le rend d’autant plus efficace - on va en retirer quelque chose à la fin. Le cadre est léger. C’est très libre, voire parfois chaotique. Et c’est très bien. Ça donne de l’espace aux participants pour faire émerger une compréhension commune.

Quand déclencher un Event Storming ?

Dès lors qu’il y a de l’incompréhension ou un besoin de s’accorder. La force de l’Event Storming est de rassembler de nombreuses personnes et de tout mettre à plat sur un mur. On va rendre l’implicite explicite et harmoniser les modèles mentaux de chacun.

Quelques autres signaux intéressants pour déclencher : on a trop de bugs, on a des zones de floues, on veut s’aligner avec un existant, on veut cartographier de la connaissance.

Plus axé conception logiciel, l’Event Storming aura également son utilité associé au Domain-Driven Design lorsque l’on souhaite découvrir des Bounded Contexts ou des agrégats, ou associé à de l’Event Sourcing pour identifier les événements.

Une animation d’Event Storming

Il y a plusieurs recettes pour animer un Event Storming. Alberto compare l’atelier à une pizza. Il y a une base avec de la tomate et de la mozza (notre ligne de temps avec nos événements). Et ensuite, on y ajoute différents ingrédients au choix (des acteurs, des commandes, des données, des règles, …), sauf quelques exceptions (ni ananas, ni table de base de données :p). Je parle de tous ces éléments et leurs interactions dans cet article.

Selon le besoin, on va donc ajouter des étapes supplémentaires. En général, on veut au moins voir qui fait quoi. On veut identifier les acteurs et les systèmes externes qui nous ajoutent des contraintes, ainsi que les problèmes.

Pour cette introduction, on composera avec les événements ainsi que les commandes, acteurs, données et dépendances. C’est une bonne entrée en la matière que j’ai vu avec Marion Lecerf et Pablo Pernot lors d’un atelier pendant la conférence School of PO ; on obtient rapidement une cartographie intéressante du système.

Libre à vous d’adapter comme vous le souhaitez. On peut ajouter ou supprimer des étapes, en rassembler certaines en une seule étape, être plus macro ou plus micro. C’est très modulable. J’y reviendrais dans un second temps.

Préparation

En amont de l’atelier, on prendra soin d’inviter toutes les personnes qui ont un lien avec ce que l’on veut faire. Si on prend l’exemple d’un logiciel, on pourrait y inviter des développeurs, des POs, des experts du métier, des collaborateurs d’une équipe externe, etc. Toute personne qui peut contribuer est la bienvenue - on veut voir l’image dans son ensemble, on veut éclaircir des zones d’ombre, il faut qu’il y ait tous les acteurs.

Second point, la salle et le matériel. Il faut réserver un grand espace, avec de grands murs. On éloignera le mobilier qui peut gêner, et on mettra à disposition une infinité de stylos et de post-its avec les bonnes couleurs. Prévoir plusieurs mètres de papier craft idéalement pour permettre d’écrire et dessiner directement dessus. Possiblement du scotch ou des ficelles. Ça fonctionne aussi à distance sur un outil comme Miro.

Les événements

Sur une ligne de temps que l’on aura tracé, les participants vont s’atteler à positionner ensemble tous les événements qui composent le processus. On construit la colonne vertébrale. C’est ce qu’il se passe dans notre système. On peut commencer par délimiter le début et la fin en plaçant le premier événement et le dernier événement du processus pour borner.

On utilise des post-its oranges. Les événements sont décrits par un verbe au participe passé. « Facture générée », « Commande livrée ». C’est quelque chose qui a eu lieu. C’est très important. On veut forcer les participants à penser avec des actions achevées, des changements d’état, des choses qui peuvent agir comme un déclencheur pour une autre action. Les événements doivent être parlant pour les experts métiers et ça tombe bien, ils sont censés être dans la pièce avec nous.

Si on a du conditionnel, on peut faire deux branches. Et si on a trop de branches, on se dit qu’il faut les mettre de côté et faire un atelier dédié afin de se concentrer sur notre branche principale. On veut se concentrer sur notre cas nominal.

On veillera à exprimer tout ce qui vient via des post-its. On veut voir émerger l’ensemble du modèle. On discutera après. Ça peut sembler chaotique mais c’est ce que l’on veut. Lors de l’atelier avec Pablo, il indiquait qu’il poussait au chaos : si ce n’est pas assez bordélique, c’est peut-être qu’il n’y a pas les bonnes personnes ou qu’il y a trop de limites.

On peut marquer les désaccords, les questions, les risques, ça fait partie du modèle. On utilise des post-its roses foncés / rouges pour ces points d’attention (les Hot Spots). Alberto n’hésite pas à marquer tout ce qui s’éloigne du scénario nominal pour rester concentré. Ce seront des éléments à creuser plus tard. « Attention RGPD », « Que fait X ? », « Risque de fraude de paiement ». On peut les positionner en hauteur pour surplomber, ou directement à l’endroit où ça fait sens, au choix.

Cette première étape peut prendre du temps, c’est normal. Les événements forment le cœur du processus. Lorsqu’on arrive à la fin, on demande à une personne de raconter l’histoire qui est modélisée. Le storytelling fait son apparition, les gens aiment écouter des histoires. On en profite pour peaufiner et clarifier le modèle si besoin. Peut-être qu’il manque une précision à un moment. Peut-être qu’il reste une zone de flou.

Les commandes

Dans notre seconde étape, on va positionner les commandes. C’est ce qui déclenche un événement, souvent une conséquence d’une action utilisateur, une prise de décision, ou d’un système externe.

On utilise des post-its bleus. La commande est décrite avec un verbe à l’infinitif. « Ajouter au panier ». Elle est placée devant l’événement sur la ligne de temps.

Les commandes peuvent être utiles pour faire émerger du bordel, surtout sur un système existant, pour aligner les connaissances. On peut trouver que la commande et l’événement sont redondants. Avec la commande, on parle de l’action réalisée par un acteur, qui sera le déclencheur d’un ou plusieurs événements. Il n’y a pas forcément une commande sur chaque événement. Avec les commandes, on se projette également un peu dans le code.

Les acteurs

Troisième étape, on positionne les acteurs. Ce sont eux qui déclenchent les commandes. Ce peut être un utilisateur ou une partie d’un logiciel. On utilise des post-its jaunes et on y marque le nom de l’acteur. « Le client », « Le livreur », « Le système Y ». L’acteur est placé sur la commande, légèrement sur la gauche.

Les données

On arrive à la quatrième étape où l’on positionne les données. En anglais Read Model. Il y a une nuance importante ici. On va parler des données que l’on affiche et qui vont aider les acteurs à prendre des décisions. On ne parle pas des données que l’on écrit (écriture dans une base, un registre…), ces informations sont déjà indiquées dans les commandes comme « Ajouter (l’article) au panier ».

On utilise des post-its verts. On y écrit les données principales. « Nom, Prénom, Email ». On se limite pour mettre en valeur ce qui compte réellement. Le post-it est placé avant l’acteur.

Ne pas hésiter à se faire une session de storytelling pour s’assurer que tout va bien, et qu’on est aligné. On peut faire des sous-groupes. Est-ce qu’on est tous d’accord ? Est-ce clair pour tout le monde ? On peut commencer à préciser. Précis mais pas exhaustif, sinon on n’en fini pas. On met davantage au propre.

Les systèmes externes

Pour notre cinquième étape, on positionnera les systèmes externes. Ce sont les dépendances. On veut voir apparaître les adhérences auxquels est soumis le système, ce qui le contraint. On utilise des post-its rose clair. « Le fournisseur », « Service Z ».

On peut à nouveau reprendre le storytelling et raconter les événements afin de s’assurer que tout est représenté comme dans la vraie vie.

Quelques détails et astuces

Ici comme ailleurs, vous verrez qu’on associe une couleur à chaque élément de l’Event Storming. Respecter ce code couleur a son importance. On veut faciliter la lecture et la compréhension lors de l’atelier, et on veut s’y retrouver facilement si ce n’est pas notre premier Event Storming (on s’enlève la charge mentale de devoir réapprendre un autre code couleur). En voici un rappel :

• Acteur en jaune,
• Agrégat en jaune clair,
• Commande en bleu,
• Données en vert,
• Événement en orange,
• Point d’attention en rose foncé / rouge,
• Règle métier en violet,
• Système externe en rose clair.

On pourrait dire la même chose de la mise en page. Si tout le monde adopte une façon unique de présenter les post-its, on améliore la lisibilité. Une bonne pratique est d’afficher le modèle des différents post-its sur le mur.

Veillez à bien espacer les post-its entre eux pour faciliter l’ajout de nouveaux post-its au fil des étapes. D’ailleurs, un classique quand on joue avec des post-its, écrivez en majuscules, en gros, et soyez concis.

Dernière précision. On peut toujours mettre un événement, un acteur ou tout autre type de post-it même si on est passé à l’étape suivante. C’est toujours le bon moment d’ajouter de l’information.

Avec quoi on repart ?

On obtient de la visibilité. L’ensemble du processus, du système est rendu visible. Il n’y a plus de zones d’ombre - ou s’il y en a, elles sont explicitement révélées. Les problèmes et les questions sont identifiés. On va pouvoir avancer sur ces sujets.

On obtient de la compréhension. On peut avoir des prises de conscience comme “je ne pensais pas que je te créais des problèmes là-bas en faisant ça” ou “je ne savais pas que tu faisais ceci”. Les participants comprennent ce qu’il se passe chez eux et chez les autres, on casse les silos. On va améliorer la collaboration.

On obtient de l’alignement. On s’est mis d’accord tous ensemble sur le modèle, sur les problèmes. Continuons d’avancer ensemble.

La suite est très modulable, tout comme l’est l’atelier. On peut imaginer un tas de choses pour travailler sur le processus :

• Voter pour le problème principal, qui pourrait devenir la priorité numéro une.
• Mettre en lumière les zones à améliorer, et travailler dessus avec le temps.
• Identifier où il peut manquer des compétences.
• Regarder le niveau de qualité dans les zones les plus importantes pour le métier.
• Travailler sur les dépendances et goulots d’étranglement.
• Simplifier le processus.
• Etc.

Pour aller plus loin, Les éléments d’un Event Storming et leurs interactions.

Merci Marion Lecerf et Pablo Pernot pour les divers échanges, et Yannick Grenzinger qui avait initié mon équipe l’année dernière :)