Un langage dont nous voulons nous éloigner. Des API à mettre à jour. Du code ancien, difficile à modifier, mais qui remplit toujours une fonction essentielle. Des personnes arrivées tôt, qui savent pourquoi les choses ont été construites ainsi, et des collègues plus récents qui se demandent pourquoi nous faisons encore les choses ainsi.

Nous ne rencontrons pas tous le même problème au même moment. Une équipe entame une migration, une autre en termine une, et une troisième commence à remettre en question un choix fait il y a quelques années. C’est plus ou moins le même ensemble de problèmes qui revient régulièrement.

En ce moment, l’adoption de l’IA semble revenir dans presque toutes les conversations. Comment bien l’utiliser ? Qui a envie de l’essayer, qui hésite, et pourquoi ? Comment aider les gens à commencer alors que nous cherchons encore nous-mêmes ce qui fonctionne ?

Les produits ont parfois très peu de choses en commun, mais les conversations se ressemblent.

Je trouve cela rassurant. Il est facile de se laisser absorber par les problèmes de sa propre entreprise et d’imaginer que toutes les autres ont déjà trouvé les réponses. Parler avec des personnes d’ailleurs rappelle utilement qu’elles aussi essaient des choses, font des compromis et cherchent quelle direction prendre ensuite.

Si vous envisagez de changer de poste, attendez-vous à retrouver beaucoup des problèmes que vous cherchez à laisser derrière vous. Accordez moins d’importance aux défis techniques, architecturaux ou organisationnels, et davantage aux personnes avec lesquelles vous travailleriez et à la taille de l’organisation.

Préféreriez-vous apporter des changements dans une petite équipe et en voir rapidement les résultats, ou travailler dans une plus grande entreprise, où les choses prennent plus de temps mais touchent davantage de personnes ? Les deux peuvent être gratifiants. Tout dépend de ce à quoi vous voulez consacrer votre énergie et de ce que vous souhaitez en retirer.

Si votre entreprise rencontre ces problèmes, c’est peut-être une bonne nouvelle. Elle essaie de suivre le mouvement, d’améliorer les choses et de déterminer la suite, comme le reste du secteur. Rien ne garantit où cela la mènera, mais elle, et vous avec elle, êtes dans le train en marche.

Article issu de mon post LinkedIn.

Avec des outils comme Claude, nous accélérons une activité qui prenait souvent beaucoup de temps, mais que beaucoup de développeurs appréciaient particulièrement : écrire du code.

Tout le travail autour est toujours là. Mettre les tickets à jour, communiquer sur l’avancement, vérifier les changements, préparer les mises en production et s’assurer que tout fonctionne une fois entre les mains des utilisateurs.

Si écrire du code prend moins de temps et que tout le reste ne change pas, ces tâches occupent une plus grande part de la journée. Nous risquons de retirer de l’effort au travail, mais aussi une partie du plaisir qu’il procure.

Cela me semble important quand nous parlons d’adoption de l’IA. Certains développeurs sont enthousiastes, d’autres plus prudents. Cette différence tient peut-être en partie à la façon dont l’IA change leur expérience du métier.

Cela a aussi un effet sur la circulation du travail dans l’équipe : Écrire du code → relire → tester → mettre en production → exploiter → surveiller.

Accélérer le début du processus peut simplement allonger la file d’attente plus loin. La coordination manuelle entre ces étapes peut être répétitive et peu gratifiante.

À voir les pratiques SRE de Google et les outils d’AWS et de Datadog, une grande partie de cette automatisation existe déjà. Les petites équipes ou les organisations plus traditionnelles peuvent partir d’une situation différente. Même avec de l’automatisation, il peut rester du travail manuel : rassembler le contexte, enquêter sur des résultats inattendus et tenir les personnes concernées informées.

C’est pourquoi j’aimerais explorer une approche qui part des deux extrémités. Continuer à aider les développeurs à utiliser l’IA pour écrire du code, tout en s’appuyant sur l’automatisation existante pour s’attaquer au reste du travail, en partant de la production et en remontant le processus.

Pour la surveillance, un développeur pourrait demander à un agent, dans le canal Slack de l’équipe, d’enquêter sur une alerte, de rassembler les informations pertinentes et, lorsqu’il peut le faire de manière fiable, d’appliquer un correctif.

Pour les mises en production, des agents pourraient utiliser les outils existants pour préparer et exécuter les déploiements, en vérifier les résultats et annuler les changements si nécessaire. Nous pourrions ensuite chercher des possibilités semblables pour les tests et la revue de code. Au passage, les agents pourraient maintenir les tickets et les points d’avancement à jour.

Moins d’interruptions, des enquêtes plus rapides et moins de temps passé à coordonner les mises en production seraient des signes que cette approche fonctionne. Le retour sur investissement pourrait se voir à l’échelle de l’équipe plutôt que dans la production d’un seul développeur.

Je réserverais une partie du temps gagné à l’apprentissage. Si chaque heure économisée devient un nouvel engagement, il reste peu de place pour expérimenter.

Avez-vous essayé d’aborder l’adoption de l’IA par les deux extrémités ? Le fait de supprimer des tâches fastidieuses a-t-il donné davantage envie aux développeurs d’explorer ce que l’IA peut apporter ?

Article issu de mon post LinkedIn.

La semaine dernière, une conversation avec mon manager au sujet de la performance m’a rappelé un conseil que je donne depuis des années aux personnes que je manage : gardez votre propre trace de votre travail.

Notre mémoire est étonnamment courte en matière de performance. Si vous faites quelque chose de vraiment important en février, cela peut être reconnu sur le moment, mais en décembre, les détails ont déjà commencé à s’effacer.

Les détails disparaissent. Qu’est-ce qui était difficile ? Qu’avez-vous fait concrètement ? Qu’est-ce qui a changé grâce à votre travail ? Qui l’a remarqué ? De quelles preuves disposiez-vous à ce moment-là ?

Votre manager devrait aussi se souvenir d’une partie de tout cela. En tout cas, j’essaie. Mais beaucoup de choses peuvent changer en un an : vous pouvez rejoindre une autre équipe, changer de manager, ou les personnes qui ont vu votre contribution de près peuvent tout simplement ne plus être là. Et même si rien de tout cela n’arrive, personne ne voit tout ce que vous faites ni ne se souvient de votre année aussi bien que vous.

Il faut aussi distinguer le fait de bien faire son travail de celui d’accomplir quelque chose qui témoigne d’une performance exceptionnelle. Si vous êtes ingénieur et que votre travail consiste à livrer des fonctionnalités, le simple fait d’en livrer une ne prouve pas que vous dépassez les attentes. C’est ce que l’on attend de vous. Ne pas y parvenir régulièrement serait plutôt le signe que vous n’êtes pas sur la bonne voie.

Ce qui compte, c’est ce qui s’est passé au-delà du résultat attendu. Peut-être avez-vous surmonté une complexité inhabituelle, évité un problème grave, aidé d’autres personnes à devenir plus efficaces ou eu un impact au-delà de votre périmètre immédiat.

Ce sont ces choses-là qu’il faut noter lorsqu’elles se produisent. Gardez un document et ajoutez-y une entrée chaque fois qu’un élément vous semble digne d’être retenu : la date, un peu de contexte, votre contribution et, si possible, des preuves de son impact. Les chiffres sont très utiles quand vous en avez, mais un retour reçu, un résultat ou un exemple concret peuvent avoir autant de valeur.

Si vous n’avez rien consigné jusqu’ici cette année, il n’est pas trop tard. Commencez maintenant et, si votre mémoire vous fait défaut, regardez les traces que votre travail a déjà laissées.

Parcourez votre historique Slack, ou demandez à Claude de vous aider à l’explorer. Relisez vos messages privés avec votre manager. Regardez les pull requests que vous avez ouvertes, surtout celles qui sortent de l’ordinaire : si vous travaillez sur le frontend, pourquoi êtes-vous intervenu dans le code du backend ? Consultez les incidents, les documents, les canaux de projet et les retours de vos collègues.

Prenez le temps de garder cette trace. Servez-vous des données dont vous disposez déjà pour combler les trous, puis continuez à l’enrichir au fil des événements. Quand viendra le moment de parler de votre performance, ne comptez pas sur quelqu’un d’autre pour se souvenir de la valeur de votre contribution.

Donnez-vous les preuves nécessaires pour faire reconnaître votre travail.

Article issu de mon post LinkedIn.

Je les conserve dans un Canvas Slack partagé. Elles sont ainsi toujours faciles à retrouver, et nous pouvons tous les deux ajouter des sujets ou des notes avant notre prochain 1:1.

Le principe est simple : si ces notes portent sur une conversation que nous avons eue ensemble, pourquoi n’appartiendraient-elles qu’à moi ?

Cela impose aussi une contrainte utile. Mes notes sont délibérément neutres : ce dont nous avons parlé, les décisions prises, les sujets à reprendre et les actions convenues. Je ne conserve pas non plus ailleurs d’interprétations privées du comportement ou de la performance de quelqu’un. Si je ne suis pas à l’aise à l’idée que la personne lise ce que j’ai écrit à son sujet, je ne devrais probablement pas l’écrire.

Ce qui a changé, c’est la façon dont ces notes sont produites.

Depuis environ un an et demi, Gemini traite les transcriptions de mes réunions. Au début, je lançais manuellement un Gem après chaque 1:1, puis je collais son résultat dans le Canvas. Maintenant, toute la routine est automatisée avec Claude.

Par défaut, je partage les notes et j’explique clairement comment la conversation est traitée et à quoi sert le résultat. Avant de commencer à travailler ainsi avec une nouvelle personne, je lui explique que Gemini, dans Google Meet, transcrit nos réunions, comment j’utilise ces transcriptions, et je lui demande son consentement. Jusqu’à présent, tout le monde a accepté : les personnes concernées voient aussi l’intérêt de disposer du même compte rendu partagé de nos échanges.

Cela me permet d’être pleinement présent au lieu de prendre des notes : d’écouter attentivement, d’observer le langage corporel et de percevoir les signaux qu’une transcription ne peut pas saisir.

Chaque jour à 16h30, Claude traite les transcriptions de la journée, met à jour les notes et les actions partagées, puis me donne le retour positif et constructif que je lui demande sur ma propre façon de manager : comment j’ai mené les discussions, ce que j’ai bien fait, ce que j’aurais pu aborder autrement et comment je pourrais améliorer ma communication. C’est un peu comme avoir un coach en management qui aurait assisté à chaque conversation.

Je ne suis pas d’accord avec tous ses retours, mais ils me donnent matière à réfléchir à la fin de chaque journée.

La routine est maintenant partagée en interne en open source pour que d’autres managers puissent l’utiliser, que leurs notes soient dans un Canvas Slack ou ailleurs, et qu’ils choisissent de les partager avec les personnes qu’ils managent ou de les garder privées.

Les outils sont adaptables. Le principe qui me tient à cœur est simple : laisser la machine gérer l’information, pour que je puisse concentrer mon attention sur la personne en face de moi et continuer à progresser dans la dimension humaine du management.

Article issu de mon post LinkedIn.

Avant un entretien individuel, je veux me souvenir de ce dont nous avons parlé la dernière fois, de ce qui s’est passé depuis dans leur équipe et des sujets sur lesquels elles pourraient avoir besoin de mon aide. Quand je parle avec mes engineering managers, je veux déjà savoir ce qui avance et ce qui bloque.

Pour moi, arriver préparé est une marque de respect pour le temps et le travail des autres. Mais cela demande une quantité étonnante de travail mécanique : recueillir les dernières informations, retrouver d’anciennes conversations, se souvenir des actions convenues, préparer le contexte.

Ces dernières semaines, j’ai donc construit des routines quotidiennes qui s’appuient sur l’IA. Pas un chatbot auquel je pose des questions, mais des automatisations qui préparent ma journée et en publient le résumé sur Slack avant même que j’ouvre mon ordinateur :

• Un « secrétaire » qui prépare mes entretiens individuels à partir des notes et des actions précédentes.
• Une routine de préparation aux entretiens de recrutement qui récupère le CV d’une personne candidate dans ma boîte de réception, ainsi que les résultats de ses tests précédents.
• Un contrôle quotidien dans Jira de l’état des initiatives et des epics de mes équipes, comparé à la veille, pour voir ce qui avance et ce qui bloque avant de parler avec mes engineering managers.
• Une routine de fin de journée qui transforme mes notes de réunion en une base de connaissances locale, en reliant les conversations, les objectifs et les échanges au sein de mes équipes et avec les parties prenantes.

Cette dernière routine devrait aussi éviter que les évaluations de fin d’année se transforment en chasse aux informations dans six mois de notes et de messages Slack éparpillés. Le contexte se construit déjà, semaine après semaine.

Et l’ensemble consomme environ 0,30 $ par jour de mon quota Claude.

Mais gagner du temps n’est pas vraiment le but.

Je veux confier aux machines la partie mécanique de mon travail, pour avoir plus de temps et de disponibilité d’esprit pour sa dimension humaine. Je veux passer mes entretiens individuels à comprendre où une personne a besoin d’aide, ce qui la frustre et dans quelle direction elle souhaite évoluer. Je veux que mes échanges avec mes engineering managers servent à prendre de meilleures décisions et à les aider à progresser, pas à leur demander de répéter des informations que j’aurais pu recueillir à l’avance.

L’IA ne remplace pas ces conversations. Elle me permet d’y arriver mieux préparé, de mieux connaître le travail des personnes et, au bout du compte, d’être plus présent avec elles. Rien de tout cela ne remplace le discernement. Cela supprime la recherche et la collecte d’informations qui accaparaient le temps et l’attention que méritent ce discernement, et les personnes.

Je ne peux pas partager ces routines telles quelles : elles sont étroitement liées à mon contexte et à ma façon de travailler. Mais j’en transforme les parties utiles en versions neutres, faciles à installer et adaptables, pour les partager avec mes collègues. Et avec un peu de créativité, ce post et Claude, chacun pourrait construire le même type de système autour de sa propre façon de travailler.

Quelle est la tâche mécanique de votre travail que vous confieriez volontiers à une machine ?

Article issu de mon post LinkedIn.

Nous utilisons actuellement Slack en famille, donc supprimer complètement l’application n’est pas envisageable. Le problème, c’est que placer mon espace familial et mon espace professionnel côte à côte rendrait la tentation de consulter le travail presque irrésistible.

Je me connais. J’ouvrirais Slack pour lire un message de ma famille, je remarquerais quelque chose dans l’espace professionnel et finirais par le consulter aussi. Ou je prendrais mon téléphone pour parcourir X, chercher une nouvelle voiture que je n’achèterai jamais, ou faire quelque chose de vaguement constructif, avant de me retrouver malgré tout au travail.

Même un coup d’œil de trente secondes peut ramener dans mon esprit, pour toute la soirée, un problème non résolu ou une conversation difficile.

Le travail vit donc sur un deuxième téléphone.

J’utilise un ancien iPhone SE de 2020, qui reste normalement sur la station de recharge familiale. Pendant la journée, je peux l’emporter lorsque je suis loin de mon ordinateur. Lors des rares soirées ou week-ends où quelque chose exige réellement mon attention, je peux aller le chercher.

L’essentiel est que le travail ne me suive pas par défaut.

En tant que cadre en France, mon métier ne consiste pas vraiment à compter un nombre fixe d’heures. Il s’agit d’assumer des responsabilités et de faire avancer le travail. J’accepte que cela demande parfois de la souplesse. Mais cette souplesse doit fonctionner dans les deux sens. Pouvoir répondre lorsque c’est nécessaire ne signifie pas transporter le travail partout et tout le temps.

Cela me vient peut-être plus naturellement parce que j’ai passé la majeure partie des années 2010 sans smartphone. J’ai gardé un BlackBerry pendant quelques années, jusqu’en 2012, puis je n’ai plus possédé de smartphone avant 2020, lorsque j’ai finalement cédé et acheté un Moto G. Je suis passé chez Apple en août 2021 avec un iPhone SE original de 2015.

Pendant des années, avoir Internet en permanence dans ma poche n’était tout simplement pas normal pour moi. Je ne crois toujours pas que chaque aspect de ma vie doive partager le même appareil.

Le téléphone professionnel est aussi réellement utile pour les tests. Je peux y installer des versions TestFlight, conserver plusieurs navigateurs et comptes configurés, et expérimenter sans remplir mon téléphone personnel d’applications professionnelles, de cookies et d’historique de navigation.

Cela me rappelle le laboratoire d’appareils que j’avais été chargé de mettre en place chez FanDuel pour les développeurs frontend. J’avais organisé et entretenu une collection de téléphones et de tablettes, anciens comme récents. C’était toujours amusant — et véritablement pratique — de prendre un appareil réel et de voir ce que le produit donnait concrètement.

Les simulateurs ont leur place, mais ils ne reproduisent pas tout à fait un téléphone lent, un petit écran, un ancien navigateur particulier ou un appareil qui peine sous le poids d’une application moderne. Il fallait être là, sans doute.

Utiliser un ancien téléphone est donc une fonctionnalité, pas un compromis. Mon iPhone SE donne une approximation correcte de l’expérience dégradée que certains utilisateurs rencontrent. Les problèmes de performance et les interfaces à l’étroit sont bien plus difficiles à ignorer sur un téléphone vieux de six ans que sur le dernier modèle haut de gamme.

Je ne paie ni deuxième carte SIM ni forfait mobile supplémentaire. Lorsque j’ai besoin d’une connexion loin du Wi-Fi, je partage celle de mon téléphone personnel.

Il y a également un avantage en matière de sécurité. La plupart du temps, lorsque je quitte la maison, les données de l’entreprise et les comptes professionnels restent sur place. Perdre mon téléphone personnel serait toujours pénible, mais cela ne signifierait pas aussi perdre un appareil rempli d’applications professionnelles.

Je ne prétends pas que tout le monde a besoin de deux téléphones. Pour moi, les modes de concentration et les réglages de notifications sont trop faciles à contourner. Ils ne résolvent pas non plus le fait que la même application Slack contient à la fois ma famille et mes collègues.

Une frontière physique fonctionne mieux.

Lorsque je laisse le téléphone professionnel sur mon bureau, j’ai délibérément arrêté de travailler. Le travail reste accessible lorsqu’il le faut vraiment, mais il ne vit pas dans ma poche.

Non pas parce qu’il n’était pas utile, mais parce qu’il est devenu normal. Les fonctionnalités sont livrées et intègrent le produit. Les refactorisations tiennent et plus personne n’y pense. Les petites décisions, les blocages levés et les responsabilités supplémentaires se fondent discrètement dans le décor.

Après quelques mois, même vous en oubliez une partie. C’est pourquoi je garde un historique de mon travail, et pourquoi vous devriez en faire autant.

La mémoire n’est pas fiable

Les managers oublient. Nous aussi. Une année est longue. Le contexte évolue. Les priorités changent. Ce qui semblait important en mars est difficile à reconstituer en novembre.

Même les bons managers s’appuient involontairement sur ce qui est récent ou visible. C’est simplement ainsi que fonctionne la mémoire.

Garder ses propres notes n’est pas une question de méfiance. C’est reconnaître que la mémoire n’est pas un système.

Il ne s’agit pas d’autopromotion

Noter ce que l’on a accompli peut sembler gênant. Cela peut donner l’impression que l’on cherche à constituer un dossier.

En réalité, c’est beaucoup plus simple.

À un moment donné, on vous demandera :

• Comment s’est passée votre année ?
• Avez-vous atteint vos objectifs ?
• Dans quels domaines avez-vous dépassé vos habitudes ?
• Travaillez-vous déjà au niveau supérieur ?

Sans notes, vous finissez par reconstruire l’année à partir de fragments. Avec des notes, vous voyez des tendances. Vous voyez où vous avez pris des initiatives, où vous avez progressé et où vous avez assumé davantage que prévu.

La discussion devient plus calme. Plus factuelle. Moins émotionnelle.

Ce que je note réellement

Je ne consigne pas tout. Je ne dresse pas la liste des tickets.

Je note les choses dont je sais que je ne me souviendrai plus clairement dans six mois :

• Les refactorisations qui ont réduit la complexité
• Les risques évités avant qu’ils ne deviennent des incidents
• L’aide apportée à d’autres équipes en dehors de mon périmètre officiel
• Les présentations ou démonstrations internes
• Les décisions qui ont résisté au temps
• Les moments où je suis allé légèrement au-delà de mon niveau

Si quelque chose a demandé de l’initiative ou m’a mis légèrement mal à l’aise, cela mérite généralement d’être noté.

Regardez un niveau au-dessus

Une habitude utile consiste à lire les attentes correspondant au niveau supérieur au vôtre.

Non pas pour le revendiquer prématurément, mais pour vous orienter. Si vous constatez régulièrement que votre travail y correspond, il est utile d’avoir des exemples sous la main. Pas pour préparer un discours, simplement pour montrer une tendance.

Les tendances sont plus faciles à discuter que les réussites isolées.

Quand cela devient important

Pendant la majeure partie de l’année, ce document reste simplement là.

Puis arrive la période des autoévaluations. Ou les discussions sur la rémunération. Ou un changement de périmètre. Ou l’arrivée d’un nouveau manager.

C’est à ce moment-là qu’il devient utile.

Au lieu d’essayer de vous souvenir de ce qui s’est passé, vous disposez d’une chronologie. Au lieu d’impressions vagues, vous avez des exemples. Inutile d’en rajouter. Le travail parle de lui-même.

Vous serez heureux de l’avoir conservé.

Comment je conserve le mien

J’utilise un Canvas Slack.

Principalement parce que je suis déjà dans Slack tous les jours. Il est facile à mettre à jour. Si quelque chose de notable se produit, je peux ajouter une ligne pendant que le souvenir est encore frais.

Je programme également un petit rappel hebdomadaire et j’enregistre les conversations qui pourraient devenir pertinentes plus tard.

L’outil importe peu. Un document, une note, un canal privé. Ce qui compte, c’est qu’il soit suffisamment proche de votre travail quotidien pour ne pas ressembler à une tâche supplémentaire.

Si cela paraît lourd, vous ne tiendrez pas dans la durée.

C’est tout

Il ne s’agit pas de manipuler les évaluations. Il s’agit de ne pas laisser votre propre travail disparaître à l’arrière-plan.

Faites votre travail.
Gardez-en une trace légère.
Facilitez les conversations futures.

Demandez et vous recevrez.

Cette phrase apparaît aux côtés de « cherchez et vous trouverez » et « frappez et l’on vous ouvrira ». Dans son contexte, elle ne promet pas une récompense. Elle affirme la nécessité d’agir. Rien n’est donné si rien n’est demandé.

Nous considérons souvent cela comme une idée spirituelle, mais elle s’applique très concrètement à la vie quotidienne. Au travail, à la maison et dans les relations, de nombreux résultats ne se produisent jamais simplement parce qu’ils n’ont jamais été clairement demandés.

Un dicton écossais exprime la même idée plus directement :

Shy bairns get nowt.

Les enfants timides n’obtiennent rien. Si vous ne demandez pas, vous ne devriez pas vous attendre à recevoir.

Agir vient avant demander, la plupart du temps

Dans un contexte professionnel, une demande ne fonctionne généralement que lorsqu’elle fait suite à l’action.

Vous ne demandez pas davantage de responsabilités avant d’avoir montré que vous pouvez les assumer.
Vous ne demandez pas la confiance avant de vous être comporté de manière digne de confiance.
Vous ne demandez pas une promotion avant de travailler déjà au niveau supérieur.

L’action crée la crédibilité. La demande rend cette crédibilité visible.

Mais il existe une exception importante. Parfois, vous ne pouvez pas agir avant que l’occasion vous soit donnée. Les responsabilités supplémentaires ne se présentent pas toujours d’elles-mêmes. Dans ce cas, la première chose à demander n’est pas un titre ou une récompense, mais une chance.

Une chance d’essayer.
Une chance de prendre en charge un problème.
Une chance de travailler à un niveau légèrement supérieur.

Cette demande n’est pas prématurée. C’est elle qui rend l’action possible.

Agissez. Puis demandez. Ou demandez à agir.

Les carrières stagnent le plus souvent non par manque de capacité, mais parce que la direction souhaitée reste implicite. Les personnes font le travail sans jamais le relier à ce qu’elles veulent ensuite. Ou elles attendent des occasions qui ne viennent jamais.

Votre manager possède une vision de l’organisation. Vous possédez une vision de votre propre trajectoire. Les deux ne peuvent s’aligner que par la conversation, une fois les intentions explicites.

Cela signifie parfois parler au-delà de son responsable direct, non pas pour faire de la politique, mais pour explorer. Comprendre où se trouvent les besoins, où des occasions pourraient être créées et où vous êtes prêt à intervenir.

La même logique s’applique aux promotions et à la rémunération. Les organisations réagissent aux risques et aux incitations. Le coût de la perte d’une personne qui crée du levier est souvent supérieur au coût nécessaire pour la garder alignée et justement rémunérée. Cette équation ne fonctionne que lorsque la contribution est visible et l’intention connue.

L’ordre compte donc, mais il reste flexible.

Faites le travail lorsque vous le pouvez.
Demandez l’occasion lorsque vous ne le pouvez pas.
Puis demandez, clairement et honnêtement, ce qui vient ensuite.

Demandez et vous recevrez.
Shy bairns get nowt.

Les prompts comptent. Mais ils sont rarement le levier principal.

En pratique, la qualité de ce que vous obtenez d’un système d’IA dépend bien davantage du contexte que vous lui fournissez que de l’habileté de votre formulation. Pour un responsable d’ingénierie, cette différence est importante.

Le contexte est le véritable levier

Un responsable d’ingénierie évolue dans un flux d’informations fragmentées : des pull requests étalées sur plusieurs mois, des revues de code, des fils de discussion et messages privés sur Slack, des notes de réunions individuelles, des objectifs qui évoluent et des attentes liées au rôle à moitié oubliées.

Personne ne peut garder tout cela de manière fiable en mémoire. Lorsque nous essayons, nous prenons des raccourcis : ce qui s’est passé récemment, ce qui a fait du bruit, ce qui semblait important.

Les LLM n’ont rien de magique. Mais ils savent absorber de grands volumes d’informations variées et faire émerger des tendances difficiles à percevoir morceau par morceau, à condition de leur donner suffisamment de matière.

Les prompts guident la structure. Le contexte permet de comprendre.

Un bon prompt reste utile. Il définit la structure du résultat : résumé, points forts et axes de développement, formulation neutre, affirmations étayées par des faits.

Mais aucun prompt ne compense un contexte absent. Une instruction bien conçue appliquée à des données superficielles produit un résultat superficiel. Une instruction simple appliquée à un contexte riche produit souvent quelque chose d’étonnamment utile.

Pour un manager, le levier n’est pas rhétorique. Il réside dans la sélection et l’organisation du contexte.

Un exemple concret : les évaluations de performance

Les évaluations de fin d’année rendent cela évident.

La plupart sont rédigées de mémoire, avec quelques faits marquants récents. Même avec de bonnes intentions, cela déforme le résultat. Les contributeurs discrets sont oubliés. Le travail réalisé en début d’année s’efface. Les comportements sont réduits à quelques anecdotes.

L’amélioration ne vient pas d’un meilleur prompt.

Elle vient de meilleures données d’entrée.

Donnez du contexte au système :

• Les pull requests rédigées ou auxquelles la personne a contribué de manière significative
• Les commentaires de revue de code
• Les discussions Slack pertinentes
• Les décisions ou le mentorat qui ont eu lieu en messages privés
• Les objectifs documentés
• Les attentes liées au parcours professionnel

Une fois ces éléments présents, l’IA peut aider à faire émerger des thèmes : les formes de prise de responsabilité, le style de collaboration, la régularité ou les axes de progression qui ne deviennent visibles qu’avec le temps.

À ce stade, le prompt façonne le format, mais la compréhension vient des données.

Le contexte réduit les biais, pas la responsabilité

Il ne s’agit pas de déléguer son jugement. Le manager continue de décider et d’assumer le feedback.

Le contexte élargit le champ de vision. Il réduit les angles morts créés par la mémoire et le bruit organisationnel. Il offre une base plus large pour raisonner avant de parler ou d’écrire.

La véritable limite n’est pas le modèle. C’est le peu de contexte que nous fournissons habituellement. Nous sommes habitués à des outils qui travaillent sur de petites quantités d’information. Les LLM récompensent davantage l’exhaustivité que l’ingéniosité.

Pour les responsables d’ingénierie, c’est une occasion non pas d’automatiser le management, mais de l’aborder avec plus de cohérence et de moins dépendre de la mémoire seule.

Le contexte l’emporte sur les prompts.

Les responsables d’ingénierie ne sont pas payés pour gérer des calendriers, réécrire des comptes rendus de réunion ou courir après des documents. Ils sont payés pour créer de la clarté, permettre aux personnes d’avancer et prendre des décisions qui font progresser l’organisation.

Lorsque la majeure partie de votre temps est absorbée par des tâches administratives répétitives, vous ne faites pas preuve de prudence ou de rigueur. Vous exploitez insuffisamment le levier que représente votre rôle.

C’est précisément là que l’IA change la nature du métier.

L’IA n’est plus facultative

Les outils d’IA ne sont plus des expériences, des jouets ou des paris lointains sur l’avenir. Ils sont devenus une infrastructure de base du travail intellectuel moderne.

Bien utilisés, ils prolongent votre manière de réfléchir et de vous préparer. Ils vous aident à écrire plus clairement, à synthétiser l’information plus rapidement, à mieux préparer les conversations et à assurer un suivi plus régulier. Ils ne remplacent pas le jugement, mais ils l’amplifient.

Choisir de ne pas utiliser l’IA dans un rôle de responsable d’ingénierie n’est pas une position de principe. En pratique, c’est un déficit de productivité et de qualité.

L’IA peut contenir plus de contexte que n’importe quelle personne

Un responsable d’ingénierie évolue dans un flot constant d’informations : des mois de notes de réunions individuelles, des transcriptions de réunions, des discussions Slack entre plusieurs équipes, des décisions à moitié prises, des objectifs en évolution et des retours sur la performance provenant de nombreuses sources.

Aucun humain ne peut garder tout cela de manière fiable dans sa mémoire de travail. Prétendre le contraire conduit généralement à un biais de récence et à une reconnaissance superficielle des tendances.

L’IA, en revanche, peut absorber de grands volumes d’informations qualitatives et raisonner à partir de celles-ci. Utilisée avec soin, elle peut aider à préparer des évaluations de fin d’année fondées sur l’historique réel plutôt que sur les impressions récentes. Elle peut faire ressortir des thèmes récurrents dans plusieurs réunions individuelles, mettre en évidence des blocages répétés ou des trajectoires qui stagnent, et révéler des schémas de progression qui n’apparaissent que lorsque l’on observe des mois plutôt que des semaines.

Elle peut même contribuer à créer des plans de développement véritablement personnalisés et révéler des dynamiques interpersonnelles émergentes à travers les réunions et les équipes.

Ce n’est pas de l’automatisation. C’est une perception augmentée.

L’IA comme conseillère, pas comme oracle

Certaines des situations les plus difficiles du métier sont celles où aucune décision correcte ne s’impose. Une tension entre deux personnes, un feedback qui semble juste mais reste difficile à formuler, des conflits aux conséquences humaines qui ne peuvent être réduits à un arbre de décision.

Dans ces moments, l’IA est particulièrement utile lorsqu’elle agit comme partenaire de réflexion.

Elle peut vous aider à reformuler une situation, explorer d’autres interprétations, suggérer des questions à poser et examiner les compromis avant de parler. Sa valeur réside dans l’élargissement de votre perspective, pas dans la production d’une réponse définitive.

L’IA ne devrait jamais décider à votre place. Elle devrait vous aider à mieux décider.

Réduire les frictions, pas la responsabilité

L’IA est extrêmement efficace pour supprimer les frictions mécaniques qui entourent le management. Elle peut aider à résumer les réunions individuelles et en extraire les actions, préparer des conversations difficiles avec plus de clarté et d’empathie, synthétiser le feedback dans le temps et entre différentes sources, structurer les évaluations et les objectifs, transformer des discussions dispersées en journaux de décisions utilisables et préparer des messages d’alignement en quelques minutes plutôt qu’en quelques heures.

Ce qu’elle ne peut pas faire, c’est comprendre la confiance, lire une pièce, choisir le bon moment ou assumer les conséquences de ce qui est dit et décidé.

L’IA peut soutenir votre jugement, mais elle ne pourra jamais absorber votre responsabilité.

Passez moins de temps à gérer les processus et davantage à accompagner les personnes

Le travail qui offre le plus de levier à un responsable d’ingénierie n’est pas la documentation. C’est la conversation.

Le coaching, la transmission du contexte, la prise de décision, la levée des blocages et l’alignement des personnes avec la stratégie sont les domaines où se crée le véritable impact. L’IA devrait comprimer les aspects mécaniques du rôle afin que vous puissiez consacrer davantage d’attention aux aspects humains.

Si l’IA vous rend du temps, l’objectif n’est pas de remplir ce temps avec davantage d’administration. Il est de le réinvestir dans les personnes.

La préparation l’emporte sur l’improvisation

Les bons managers comptent rarement sur l’improvisation. Ils arrivent avec du contexte, une intention et des questions bien choisies.

L’IA est un puissant multiplicateur pour la préparation. Brouillons, résumés, reformulations, scénarios possibles et questions de suivi deviennent tous plus faciles à produire. Vous continuez de prendre les décisions, mais vous y arrivez avec plus de profondeur et de perspective.

Le niveau d’exigence est désormais plus élevé

Utiliser l’IA simplement pour moins gérer passe à côté de l’essentiel. Les meilleurs responsables d’ingénierie l’utilisent pour manager de manière plus intentionnelle.

Plus de clarté.
Plus de cohérence.
Plus d’équité.
Plus de suivi.

L’IA ne réduit pas les attentes. Elle les élève.

L’état d’esprit

Déléguez la répétition aux machines. Gardez le jugement chez les humains. Utilisez l’IA pour mieux réfléchir, pas pour réfléchir moins. Optimisez le levier, pas le confort.

Le management de l’ingénierie reste un savoir-faire. L’IA ne le remplace pas. Elle supprime simplement beaucoup d’excuses pour ne pas bien le pratiquer.

La perfection compte beaucoup moins.

La plupart des produits logiciels ne sont ni des fusées, ni des dispositifs médicaux, ni des systèmes de contrôle nucléaire. Ce sont des outils conçus pour résoudre de vrais problèmes, pour de vrais utilisateurs, sous de vraies contraintes.

Dans ce contexte, fonctionner et livrer comptent davantage que l’élégance théorique.

Si cela fonctionne et apporte de la valeur, c’est suffisant pour le moment.

La production est la seule vérité

Du code propre qui n’atteint jamais la production n’a aucune importance.

Une architecture conçue pour survivre à ses créateurs devient généralement un handicap. Le seul endroit où la réalité existe est la production, avec de vrais utilisateurs, de vraies données et de vraies contraintes.

On n’apprend pas grâce aux diagrammes.
On n’apprend pas grâce aux documents de planification.
On apprend grâce aux choses qui sont utilisées.

Livrer permet d’obtenir du feedback.
Le feedback permet d’apprendre.
L’apprentissage permet de progresser.

L’ego n’est pas une architecture

Imposer votre solution plutôt qu’une solution n’est pas du leadership technique. Défendre une conception parce qu’elle est la vôtre n’est pas une marque de qualité. Bloquer les contributions pour rester « indispensable » n’est pas assumer ses responsabilités.

C’est de l’ego.

Les bons systèmes ne sont pas protégés par des gardiens. Ils sont améliorés par l’examen critique. Si quelqu’un d’autre peut trouver des défauts, des simplifications ou de meilleures approches, c’est une réussite, pas une menace.

Le code n’est pas une identité.
L’architecture n’est pas un statut.
Avoir tort n’est pas un échec.

L’objectif est de livrer, pas d’être validé.

« Suffisamment bon » ne signifie pas bâclé

Ce n’est pas un plaidoyer pour la négligence.

Le logiciel doit être stable.
La disponibilité compte.
La performance compte.
Le taux de bugs compte.
Les SLA comptent.

Mais ce sont des contraintes dans lesquelles travailler, pas des excuses pour ralentir indéfiniment.

La robustesse n’est pas l’opposé de la vitesse. Elle résulte de boucles de feedback rapides, d’une bonne supervision, de choix par défaut raisonnables et de la responsabilité.

Si vous voyez un bug, corrigez-le

Si vous rencontrez un bug et pouvez le corriger, corrigez-le.

Ne reportez pas la responsabilité sous prétexte que c’est « hors périmètre ». Ne le transférez pas à une autre équipe parce que c’est « leur application ». N’attendez pas parce que quelqu’un d’autre est « trop occupé ».

Faire circuler les bugs ne protège pas les frontières. Cela protège l’inefficacité.

La responsabilité concerne les résultats, pas les territoires. Les utilisateurs vivent le produit comme un tout, pas comme un organigramme.

Corriger ce que vous pouvez corriger, c’est faire preuve de professionnalisme.

Utilisez les outils qui vous rendent plus rapide

L’automatisation n’est pas de la triche.
Utiliser une base existante n’est pas de la paresse.
Le développement assisté par l’IA n’est pas un gadget.

Des outils comme GitHub Copilot sont des accélérateurs. Ils suppriment les frictions du travail répétitif. Ils libèrent l’attention pour la véritable résolution de problèmes.

Si un outil vous aide à aller plus vite sans compromettre les résultats, vous devriez l’utiliser. Tous les jours.

L’efficacité ne consiste pas à prendre des raccourcis. Elle consiste à respecter le temps.

Le code est un moyen, pas l’objectif

Nous n’écrivons pas de logiciels pour nous impressionner nous-mêmes ou impressionner nos pairs. Nous ne construisons pas de produits pour gagner des débats internes ou des revues de code.

Nous construisons des logiciels pour servir les utilisateurs.

Cela implique de faire des compromis. Cela implique de livrer des choses suffisamment bonnes aujourd’hui, parce qu’elles permettront demain d’apprendre, de générer des revenus et d’itérer.

L’approbation interne n’est pas la réussite.
La pureté technique n’est pas la réussite.
Un beau code n’est pas la réussite.

L’impact pour le client, si.

La réalité l’emporte sur la phase de découverte

La recherche, la découverte et la planification sont utiles. Elles réduisent les risques. Elles aident à cadrer les problèmes.

Elles ne remplacent pas la réalité.

Seuls de vrais utilisateurs, à grande échelle, utilisant de vraies fonctionnalités en production peuvent vous dire ce qui fonctionne. Tout le reste est une hypothèse.

L’état d’esprit

• Expérimentez vite
• Itérez encore plus vite
• Corrigez ce que vous voyez
• Mesurez la réussite par l’impact pour le client

Pas par les préférences personnelles.
Pas par l’appropriation d’un territoire.
Pas par l’impression d’être indispensable.
Pas par l’élégance de la solution prise isolément.

La vitesse accompagnée de responsabilité est la manière dont les produits réussissent. Aujourd’hui comme à long terme.

Soyez fier des résultats. Le processus existe pour les servir.

Cela m’a fait comprendre qu’une grande partie de ma manière de penser l’ingénierie, le leadership et même la vie de famille peut se résumer en un mot : punk. Pas bruyant ou chaotique, mais indépendant, intentionnel et ancré dans la réalité.

Ces principes guident ma manière de prendre des décisions, de diriger des équipes et des systèmes, et de m’adapter à de véritables contraintes.

Voici ma lecture de PUNK :

Pragmatic (pragmatique)

Être Pragmatic (pragmatique) signifie regarder la réalité en face et agir en conséquence.

À la maison comme au travail, quelqu’un doit décider. Tout ne nécessite pas un consensus et tout ne mérite pas une discussion sans fin. Les avis comptent, mais la clarté compte davantage. Une fois que l’on en sait suffisamment, une décision est prise et assumée.

Les compromis sont nommés plutôt qu’évités.
Le temps contre le confort. La stabilité contre la flexibilité. La profondeur contre l’étendue. Prétendre qu’il existe une option parfaite ne fait que retarder le mouvement. Le pragmatisme accepte que chaque choix ait un coût et choisit consciemment.

L’énergie est considérée comme une ressource limitée.
Qu’il s’agisse de la logistique familiale, de l’apprentissage ou de la création, l’attention est consacrée aux endroits où elle change réellement les résultats. Les détails qui n’améliorent pas véritablement la vie ou les résultats sont simplifiés ou abandonnés.

La qualité est définie par l’utilité, pas par des idéaux.
Dans la vie comme dans l’ingénierie, « suffisamment bon » est souvent le bon objectif. Fiable, compréhensible et adaptable vaut mieux que parfait mais fragile. Ce qui compte, c’est que les choses fonctionnent, tiennent sous pression et puissent évoluer.

La réalité est le juge ultime.
Les plans, les principes et les intentions sont des hypothèses. Vivre avec leurs conséquences, jour après jour, est ce qui les valide. Les ajustements reposent sur l’expérience vécue, pas sur l’attachement aux décisions passées.

Le pragmatisme n’est ni du cynisme ni de la paresse.
C’est le respect du temps, de l’énergie et de l’élan. C’est choisir le progrès plutôt que la posture, et la cohérence plutôt que les apparences.

L’état d’esprit est simple :

• Décider lorsque cela compte
• Simplifier ce qui ne compte pas
• Agir, observer, ajuster
• Continuer d’avancer

Être Pragmatic (pragmatique) consiste à construire une vie et un ensemble de réalisations qui tiennent réellement lorsque la réalité exerce une pression.

Unconventional (non conventionnel)

Être Unconventional (non conventionnel) consiste à ne pas déléguer sa réflexion, sans pour autant se retirer du collectif.

Cela commence par remettre en question les choix par défaut.
La structure des équipes. La manière de mesurer la réussite. La façon dont une famille organise l’apprentissage, le mouvement ou ses priorités. Les choix courants ne sont pas nécessairement mauvais, mais ils restent des hypothèses. Ils méritent d’être examinés plutôt qu’hérités passivement.

Être Unconventional (non conventionnel) ne signifie pas faire les choses seul dans son coin.
Cela signifie réfléchir indépendamment avant de s’aligner délibérément. Les idées sont contestées, explorées et mises à l’épreuve, mais une fois la direction choisie, elle est portée collectivement.

Les valeurs sont rendues explicites afin que les décisions restent compréhensibles.
Lorsque les personnes comprennent pourquoi un choix est différent, la confiance remplace la confusion. Les chemins non conventionnels fonctionnent lorsqu’ils sont expliqués, documentés et réexaminés, pas lorsqu’ils reposent sur l’intuition personnelle ou des suppositions implicites.

Cela s’applique autant à la maison qu’au travail.
Vivre différemment ne fonctionne que si cela reste compréhensible, durable et bénéfique pour toutes les personnes concernées. L’indépendance sans contexte partagé se transforme rapidement en friction.

La pensée non conventionnelle n’est donc pas une rébellion pour le plaisir.
C’est la discipline de choisir différemment lorsque cela rend les choses plus simples, plus saines ou plus cohérentes, tout en restant aligné avec les personnes avec lesquelles on construit et on vit.

La limite est claire :

• Penser par soi-même
• Décider ensemble
• Avancer comme un seul système

C’est cet équilibre qui empêche les choix non conventionnels de devenir du bruit.

Nimble (agile)

Être Nimble (agile), c’est savoir s’adapter tout en restant ancré.

Vivre avec le changement vous apprend rapidement ce qui compte et ce qui ne compte pas. Lorsque le contexte évolue souvent, on apprend à garder les choses simples, à voyager léger et à ne pas trop investir dans des arrangements qui ne survivront pas au prochain changement. Moins de possessions, moins de plans fragiles, davantage de marge pour s’adapter.

Mais l’agilité ne signifie pas l’absence de structure.
C’est la capacité à bouger parce que certaines choses sont stables. Les valeurs, les standards et un petit ensemble de principes non négociables forment la colonne vertébrale qui permet à tout le reste de fléchir.

En pratique, cela signifie choisir délibérément ce qui doit rester rigide.
Les interfaces, les règles de sécurité, les contraintes de cybersécurité, les principes de recrutement et le langage partagé sont rendus stables afin que l’exécution, les tactiques et les décisions quotidiennes puissent s’adapter sans chaos.

Cela s’applique tout autant en dehors du travail.
Les rythmes familiaux, les attentes et les principes fondamentaux assurent une continuité, tandis que les lieux, les emplois du temps et les méthodes peuvent changer. La stabilité au centre rend possible le mouvement en périphérie.

La direction est préservée même lorsque les plans changent.
Être Nimble (agile) ne consiste pas à réagir à tout. Cela consiste à savoir ce qui doit tenir et ce qui peut bouger, puis à s’adapter sans perdre sa cohérence.

L’agilité ne bat pas la rigidité.
Elle en dépend.

L’équilibre ressemble à ceci :

• Fixer les fondations
• Assouplir les contours
• S’adapter sans dériver

C’est ainsi que les systèmes, les équipes et les vies restent à la fois résilients et libres d’évoluer.

Keen (enthousiaste)

Keen (enthousiaste) fait partie de ces mots qui sonnent presque australiens. Le genre d’énergie que l’on entend chez quelqu’un comme Beau Miles. Curieux, enthousiaste, tranquillement aventureux.

À ce niveau, la curiosité est acquise.
Ce qui compte, c’est ce que vous en faites.

Être Keen (enthousiaste) signifie rester intéressé sans courir après la nouveauté pour elle-même. C’est choisir de continuer à apprendre même lorsque l’on pourrait s’appuyer uniquement sur son expérience. Explorer de nouveaux outils, de nouvelles idées et de nouvelles voies, non pour les collectionner, mais pour découvrir lesquels comptent réellement.

Keen (enthousiaste) désigne une curiosité dirigée.
L’attention est placée là où elle se cumule : comprendre les systèmes plus profondément, remarquer les tendances dans le temps et relier des idées très éloignées. L’objectif n’est pas de tout savoir, mais de continuer à affiner son jugement.

Cela dépasse le cadre du travail.
La même énergie qui pousse quelqu’un à gravir une colline, entreprendre une longue marche ou découvrir un lieu inconnu nourrit également la patience envers les autres, l’ouverture au changement et la volonté de réessayer après un échec.

Être Keen (enthousiaste) ne signifie pas être impulsif.
Cela signifie être engagé. Présent. Prêt à fournir l’effort lorsqu’une chose mérite d’être explorée, et à l’aise avec l’idée de dire non lorsqu’elle ne le mérite pas.

Le signal est simple :

• Curieux, mais sélectif
• Ouvert, mais ancré
• Aventureux, mais responsable

Keen (enthousiaste) ne parle pas de potentiel.
Il s’agit d’un intérêt soutenu dans le temps et de la confiance tranquille qu’il y aura toujours davantage à comprendre.

Comment cela se traduit en pratique

Pragmatic (pragmatique)
Lorsque la livraison et les idéaux d’ingénierie entrent en conflit, je rends le compromis explicite, décide rapidement et optimise pour apprendre en production plutôt que pour atteindre une complétude théorique.

Unconventional (non conventionnel)
J’invite activement les désaccords et les propositions alternatives, mais je suis strict sur l’alignement une fois la décision prise. Le débat est encouragé ; le ralentissement de l’exécution ne l’est pas.

Nimble (agile)
Je conçois les équipes, les systèmes et les feuilles de route de manière à rendre le changement peu coûteux et réversible, tout en maintenant délibérément un petit ensemble de standards et de contraintes stables.

Keen (enthousiaste)
Je considère que l’apprentissage et l’expérimentation font partie de la livraison normale, pas de projets annexes, et j’accorde de la valeur à une curiosité durable qui améliore le jugement avec le temps.

Punk, donc

Ensemble, ces principes forment une manière de travailler et de vivre qui privilégie :

• ce qui fonctionne plutôt que ce qui présente bien
• la réflexion personnelle
• l’adaptation sans drame
• une curiosité et un engagement durables

C’est suffisamment punk pour moi.

Punk.