Le leadership éthique dans l’ingénierie requiert de la persévérance malgré les résistances
Le leadership éthique C’est ainsi que se construisent les entreprises durables. En réalité, lorsque vous prenez des décisions visant à faire ce qu’il faut, les gens s’y opposent. Surtout si « la bonne chose » ralentit les choses ou met un œil supplémentaire sur la façon dont vous gérez vos systèmes. Certains parleront d’idéalisme. D’autres y verront de la naïveté. Ce n’est pas grave. Faites-le quand même.
La plupart des équipes d’ingénieurs travaillent sous pression : délais, budgets, exigences des parties prenantes. Mais la pression ne justifie pas que l’on prenne des raccourcis. Si votre système tombe en panne et que les utilisateurs en pâtissent, personne ne se soucie du fait que vous ayez livré rapidement. Ce qui compte, c’est que votre produit n’ait pas fonctionné au moment opportun. Le leadership consiste à choisir l’intégrité à long terme plutôt que la commodité à court terme, même lorsque les pairs ou la direction s’y opposent.
La cohérence éthique est difficile et vous ne gagnerez pas toutes les batailles. Parfois, vous serez mis en minorité. Parfois, vous serez ignoré. Mais si un nombre suffisant de dirigeants maintiennent la ligne de conduite, la culture change. La barre est placée plus haut. Finalement, faire ce qu’il faut devient un comportement par défaut, plutôt qu’une exception. C’est là que commence la transformation, lorsque la réflexion éthique devient la norme et non plus un débat.
Cela ne concerne pas seulement les développeurs et les ingénieurs, mais surtout les décideurs. Construire des produits que les gens utilisent n’est pas seulement une question de vitesse ou de coût, c’est aussi une question de confiance. Les gens font confiance aux systèmes qui sont construits pour durer. Vous ne gagnerez pas cette confiance en prenant des raccourcis.
Les développeurs ne doivent pas être traités comme des marchandises interchangeables
Les développeurs ne sont pas des machines. Ils ne fonctionnent pas avec des scripts réutilisables et des modèles standardisés. Pourtant, dans de nombreuses entreprises technologiques, les développeurs sont encore considérés comme des composants prêts à l’emploi. Cet état d’esprit ralentit l’innovation et sape le moral des troupes. Si vous voulez des produits solides, en particulier dans les environnements à haut risque, vous devez cesser de considérer les ingénieurs comme des ressources interchangeables.
Chaque ingénieur apporte un ensemble différent de points forts. L’un d’entre eux peut être doué pour l’architecture, un autre pour l’optimisation du code, un autre encore pour le débogage des systèmes distribués. Les traiter comme des unités uniformes de production de logiciels affaiblit votre capacité à construire quelque chose qui vaille la peine d’être mis à l’échelle. Certains ingénieurs deviendront des architectes, d’autres des responsables techniques. Pour d’autres, il est préférable d’approfondir leur métier sans passer à la gestion. C’est une bonne chose.
Le leadership consiste à comprendre les compétences uniques de vos collaborateurs et à définir les rôles en fonction de ces compétences, plutôt que d’enfermer tout le monde dans des titres et des hiérarchies qu’ils n’ont pas demandés. Le passage forcé de « développeur » à « manager » n’aide personne et promeut souvent les mauvaises personnes. C’est de la paresse.
Si vous souhaitez que vos équipes techniques soient performantes, fidélisées et aient un impact à long terme, ne réduisez plus les développeurs à des chiffres d’effectifs. Investissez dans l’apprentissage de ce qui rend chaque collaborateur efficace, puis soutenez-le avec des ressources et du mentorat. C’est payant. Les équipes fortes ne sont pas constituées de compétences clonées. Elles sont construites à partir de compétences complémentaires que vous alignez autour d’un objectif. Cette approche est évolutive. Ce n’est pas le cas de l’état d’esprit des produits de base.
Le code de démonstration du concept (POC) ne doit pas être transformé en système de production.
Une preuve de concept est un test. Ni plus ni moins. Elle est construite rapidement, souvent avec un minimum de garanties, pour démontrer qu’une idée fonctionne. C’est son but. Ce qui n’est pas prévu, c’est le déploiement à long terme. Pourtant, les entreprises transfèrent régulièrement du code POC en production parce qu’il existe déjà et qu’il « fonctionne ». Cette décision s’avère généralement coûteuse.
Lorsqu’une validation de principe est traitée comme une version finale, l’équipe hérite d’un code qui n’a jamais été conçu pour être mis à l’échelle, sécurisé ou utilisé de manière durable dans le monde réel. Il manque la qualité, la gestion des erreurs et la compatibilité des systèmes nécessaires à la production d’un logiciel prêt à l’emploi. Il n’est pas rentable de gagner du temps dès le départ en omettant un développement adéquat, car ce temps revient multiplié lorsque vous êtes obligé de réécrire ou de stabiliser le code par la suite.
Si un POC prouve le concept, il a fait son travail. Tirez-en des enseignements. Repartez ensuite de zéro et construisez un véritable produit capable de résister à la charge de travail des utilisateurs, aux cas extrêmes et aux mises à jour. Il ne s’agit pas d’un processus pour le plaisir du processus, mais d’une discipline d’ingénierie. Traiter les projets comme des travaux finis conduit à des systèmes fragiles, à une complexité inutile et à des heures de développement brûlantes après le lancement.
Pour les dirigeants, c’est important. Lorsque votre équipe insiste pour reconstruire une fonctionnalité après le prototypage, elle ne perd pas de temps, elle protège votre feuille de route d’un ralentissement ultérieur. La mise en production des premières expériences peut sembler légère, mais elle crée l’une des formes les plus coûteuses de dette technique. Donnez la priorité à des constructions réelles où la fiabilité est attendue.
Les dirigeants doivent être prêts à réinitialiser les projets lorsqu’ils ne sont pas sur la bonne voie.
Il arrive qu’un projet ne fonctionne pas. L’orientation est mauvaise, la mise en œuvre échoue ou la personne qui dirige la tâche ne parvient pas à la mener à bien. Dans ce genre de situation, la plupart des dirigeants hésitent à débrancher le projet ou à le réaffecter. Ils s’inquiètent des apparences, de la perte de crédibilité ou de la politique interne. Cette hésitation n’est pas anodine, elle a un coût.
Les responsables techniques qui retardent leur intervention parce qu’ils ne veulent pas admettre une erreur finissent souvent par superviser un échec plus long et plus douloureux. Lorsque le code est erroné, il ne suffit pas d’aller de l’avant pour qu’il soit correct. L’équipe passe plus de temps à essayer de corriger les erreurs qu’à résoudre les problèmes de fond. Cela retarde la livraison et mine la confiance dans l’ensemble de l’organisation.
Un leadership fort signifie qu’il faut remettre les pendules à l’heure lorsqu’il est clair qu’un projet a dérapé. Interrompez le travail, changez de propriétaire si nécessaire et recommencez à zéro. Toutes les tâches ne reviennent pas à la personne qui s’en est chargée en premier. Tous les plans ne tiennent pas la route lorsqu’ils sont exécutés. Prenez du recul lorsque c’est nécessaire et expliquez clairement pourquoi. Ce n’est pas de la faiblesse, c’est une stratégie d’impulsion.
Les dirigeants devraient encourager les responsables des produits et de l’ingénierie à prendre des décisions d’une grande intégrité en matière de réinitialisation. Ignorer l’échec ne le fait pas disparaître, cela ne fait qu’aggraver le problème. Lorsque votre système va dans la mauvaise direction, un retournement précoce permet de gagner du temps, de l’argent et d’améliorer le moral de l’équipe.
Le changement de paradigme est nécessaire à l’innovation
Il y a un moment dans le cycle de vie de chaque entreprise où les processus hérités commencent à ralentir les choses. Qu’il s’agisse de systèmes obsolètes, de zones de confort ou d’habitudes internes qui ne sont plus en phase avec la croissance, ces éléments s’aggravent. Le problème n’est pas toujours technique. Il est souvent culturel. Les équipes s’habituent à faire les choses d’une certaine manière et les dirigeants laissent faire, même si cela ne donne plus de résultats.
Dans l’exemple cité, les pannes de système étaient devenues routinières. Plutôt que de résoudre le problème à la racine, les ingénieurs profitaient financièrement des temps d’arrêt. La direction a laissé faire parce que l’équipe se sentait « en sécurité » en faisant les choses à l’ancienne. Ce n’est pas de la résilience. C’est de la stagnation. Si votre système tombe régulièrement en panne et que personne ne donne la priorité à sa résolution, vous ne protégez pas votre équipe, vous la limitez.
L’innovation nécessite de nouveaux apports. Si votre équipe se présente tous les jours pour gérer les échecs au lieu de résoudre les problèmes à la source, elle ne se développe pas. La culture est le moteur de la performance. Les équipes doivent être encouragées, voire poussées, à faire évoluer leurs méthodes de travail. Il s’agit notamment d’adopter de meilleurs outils, cadres et pratiques qui réduisent l’inefficacité et resserrent les boucles de rétroaction. Mais le changement n’est durable que si les dirigeants créent les attentes et l’environnement nécessaires à la croissance.
Les dirigeants doivent intervenir à ce niveau. « Laisser l’équipe se débrouiller n’est pas du leadership lorsque l’équipe n’est pas incitée à s’améliorer. Soutenez vos ingénieurs en éliminant les obstacles internes. Expliquez clairement à quoi ressemblent les performances et soutenez ces attentes par des systèmes modernes et la responsabilisation. Les équipes qui sont incitées à s’améliorer le font. Les autres répètent des schémas et restent statiques.
Les ingénieurs doivent revendiquer la pleine propriété de leur code
Une ingénierie solide ne s’arrête pas lorsque le code est poussé. Si les développeurs ne sont pas responsables de la qualité de ce qu’ils livrent, tout se dégrade en aval. Les tests échouent. La surveillance échoue. Les tickets de support se multiplient. L’appropriation change la donne. Lorsque les ingénieurs sont pleinement responsables des tests, de la documentation et de l’instrumentation de leur propre code, le produit s’améliore. Rapidement.
Transmettre du code à d’autres sans contexte crée des points faibles dans votre système. Personne ne connaît mieux le code que la personne qui l’a écrit. Elle sait comment il fonctionne, quelles hypothèses ont été émises et où il pourrait se briser. Le fait de confier la responsabilité du code aux développeurs garantit une meilleure fiabilité à chaque étape. Ils écriront des tests qui détectent les vraies erreurs. Ils intégreront de manière proactive l’observabilité dans le système. Et ils se sentiront investis dans le résultat, parce que c’est le leur.
Liz Fong-Jones, ingénieure chez Honeycomb et spécialiste de la fiabilité des logiciels, l’a clairement exprimé dans le podcast On-Call Me Maybe : les développeurs devraient écrire leurs propres tests, commentaires et instruments. Ce niveau d’engagement permet d’obtenir des systèmes plus performants et plus faciles à maintenir.
Pour les dirigeants, il ne s’agit pas de microgérer les pratiques d’ingénierie. Il s’agit de fixer les bonnes attentes dans l’ensemble de l’organisation. Si les développeurs savent qu’ils sont responsables de la réussite et de la fiabilité de leur produit, la qualité augmente, les problèmes postérieurs à la publication diminuent et les équipes progressent plus rapidement. L’appropriation crée de la fierté et de la responsabilité. Sans cela, vos systèmes sont moins prévisibles et plus difficiles à faire évoluer.
La création d’un environnement psychologiquement sûr favorise la croissance
Les gens font leur meilleur travail lorsqu’ils n’ont pas peur de faire des erreurs. Les équipes qui ne se sentent pas en sécurité lorsqu’elles posent des questions, remettent en cause des hypothèses ou admettent qu’elles sont bloquées, ralentissent. L’ingénierie est complexe par nature. La tâche devient plus difficile lorsque les gens prétendent qu’ils comprennent quelque chose juste pour éviter les critiques.
La sécurité psychologique n’a rien à voir avec le chouchoutage. Il s’agit de créer un espace où les talents peuvent s’exprimer sans craindre d’être rejetés, embarrassés ou pénalisés. L’exemple de la professeure de français au lycée qui a admis qu’elle réapprenait également la matière met en lumière un trait de leadership essentiel : la vulnérabilité. Lorsque les dirigeants font preuve d’humilité, les gens s’engagent plus ouvertement. Ils participent. Ils expérimentent. Ils apprennent.
Dans le domaine de l’ingénierie, où les technologies et les cadres évoluent constamment, il n’est pas réaliste de s’attendre à ce que tout le monde sache tout. La mise en place d’un environnement d’apprentissage dans lequel les développeurs juniors et seniors peuvent évoluer sans être jugés permet de constituer des équipes plus fortes et plus adaptables. Vous n’y parviendrez pas uniquement grâce à des politiques ou à des évaluations de performance, mais aussi grâce au comportement des dirigeants.
Les dirigeants devraient y prêter attention. Si la culture de votre entreprise ne récompense que la certitude et la rapidité, vous verrez l’innovation chuter rapidement. Les équipes ne se manifesteront pas rapidement lorsque quelque chose ne va pas. Elles éviteront de prendre des risques, ce qui signifie qu’elles éviteront de progresser. Donnez le ton par vos actions. Encouragez les questions. Normalisez l’apprentissage en public. Cela permet d’obtenir des résultats durables.
La gentillesse en cas d’échec renforce les équipes
Les pannes de système se produisent. Quelle que soit la qualité de votre équipe d’ingénieurs, le code se casse, les composants tombent en panne et les choses tournent mal. Ce qui définit votre organisation, c’est la façon dont les gens réagissent à ce moment-là. Pointer du doigt ne sert à rien. Le blâme ajoute du stress, nuit à la confiance et ralentit le rétablissement.
Lorsqu’une équipe sait que les opérations sont soutenues, et non punies, pendant les incidents, elle est en mesure de penser clairement, de déboguer plus rapidement et de récupérer les systèmes sans tension supplémentaire. La gentillesse et le professionnalisme ne sont pas des compétences non techniques. Ce sont des multiplicateurs de force, en particulier dans les environnements à forte pression où le temps de fonctionnement affecte le chiffre d’affaires, la crédibilité et l’expérience client.
Les encouragements en cas d’échec ont deux effets. Premièrement, il renforce la loyauté. Les équipes se souviennent de la manière dont elles ont été traitées lorsque les choses ont mal tourné. Deuxièmement, il crée une culture de la responsabilité sans crainte. Les gens prennent des initiatives avec plus de confiance lorsqu’ils ne sont pas préoccupés par leur propre protection.
Du point de vue de la direction, cette culture a des répercussions sur les résultats. Si les équipes d’intervention peuvent fonctionner à pleine capacité cognitive au lieu de se préoccuper des reproches, vous obtiendrez des délais de résolution plus courts et moins de problèmes récurrents. Donnez à l’ensemble de l’entreprise le ton d’un professionnalisme sous pression. Récompensez l’exécution calme, et non l’agressivité ou l’escalade. Le retour est mesurable, en termes de résilience, de rétention et d’alignement interne.
Les dirigeants ne doivent pas laisser leur ego entraver les efforts d’amélioration
Il y a un moment où le leadership cesse d’être efficace, lorsque l’ego s’oppose à la réalité. Les systèmes échouent. Les équipes commettent des erreurs. Lorsque ces problèmes sont soulevés et que les dirigeants ferment la conversation pour préserver leur image, rien ne s’améliore. Cette dynamique bloque l’élan et nuit à la confiance en interne.
Dans l’exemple cité, un manager a mis en évidence des signes clairs d’un système défaillant et a proposé des solutions. Au lieu de s’attaquer au problème, la direction s’est offusquée. Ce type d’attitude défensive décourage le retour d’information critique et rend les gens moins enclins à s’exprimer la prochaine fois qu’il y aura un problème. Le résultat est simple : les problèmes sont enterrés jusqu’à ce qu’ils ne puissent plus être ignorés. Et à ce moment-là, il est plus coûteux de les résoudre.
L’écoute ne nécessite pas d’accord. Elle exige de l’ouverture. Vous n’avez pas besoin de donner suite à tous les commentaires, mais vous devez les entendre. Lorsque des personnes, à quelque niveau que ce soit de votre organisation, font part de leurs préoccupations, elles le font parce qu’elles se sentent suffisamment concernées pour remettre en question la manière dont les choses fonctionnent. C’est un signal qui mérite d’être pris en compte.
Pour les cadres, cela est directement lié à la résilience du système et à la performance de l’équipe. Si vos collaborateurs ont peur de faire remonter les problèmes de manière proactive, votre organisation reste réactive. Les meilleurs systèmes et les meilleures équipes s’améliorent parce qu’ils font face à la réalité dès le début et qu’ils la corrigent rapidement. Cela n’est possible que lorsque les dirigeants sont prêts à ignorer l’orgueil et à donner la priorité au progrès.
L’action éthique se heurte à des résistances, mais la cohérence peut conduire à un changement systémique
Faire ce qu’il faut n’est pas toujours facile. Il y a des réactions négatives, parfois de la part des pairs, souvent de la part de la direction. C’est normal. Mais lorsque faire ce qui est juste devient systématiquement une partie intégrante de votre mode de fonctionnement, la résistance s’atténue. Les autres suivent. Au fil du temps, la norme change.
Une seule action peut ne pas faire évoluer le secteur, mais les modèles, eux, le font. Lorsque les dirigeants et les ingénieurs maintiennent leur position en matière de qualité, de responsabilité et de transparence, même sous la pression, ils obligent le système qui les entoure à s’adapter. Ces comportements commencent à définir la culture. Une fois qu’un nombre suffisant de personnes adoptent cet état d’esprit, les décisions éthiques deviennent la norme, et non plus une exception.
Il ne s’agit pas d’un sujet abstrait. Il s’agit d’un changement de comportement systémique. Plus l’éthique guide systématiquement la manière dont les équipes construisent, expédient et dirigent, plus ces systèmes deviennent fiables et dignes de confiance. La stabilité s’améliore. L’épuisement professionnel diminue. Les produits durent plus longtemps. Et l’entreprise se forge une réputation à laquelle les utilisateurs, les partenaires et les futurs employés font confiance.
Pour la direction, c’est important. La culture n’est pas dictée par une note de service, elle est façonnée par ce qui est récompensé et ce qui est ignoré. Si vous voulez une organisation qui fasse ce qu’il faut, même sous la pression, vous devez en être le modèle. Vous devez soutenir les personnes qui tiennent cette ligne. C’est ainsi que se construit l’avantage à long terme.
Récapitulation
Si vous occupez un poste de direction, en particulier dans le domaine de la technologie, votre influence ne se limite pas aux délais de livraison ou aux spécifications du produit. Elle définit la manière dont vos équipes fonctionnent sous pression, dont vos systèmes sont performants lorsque cela compte et dont on se souvient de votre entreprise lorsque les choses tournent mal. Le leadership éthique n’est pas de l’idéalisme. C’est une stratégie opérationnelle.
Une équipe qui possède son code, qui s’exprime tôt, qui réinitialise si nécessaire et qui construit avec intégrité sera plus performante qu’une équipe qui se précipite pour livrer et qui cache les problèmes sous le tapis. La stabilité à long terme, l’innovation et la réputation se construisent lorsque la responsabilité est privilégiée par rapport à la rapidité et que la clarté est plus appréciée que la hiérarchie.
Vous rencontrerez des résistances. C’est normal. Mais les bonnes décisions, en particulier celles qui sont difficiles, s’intègrent dans une culture qui ne se contente pas d’avancer rapidement, mais qui avance intelligemment. Soutenez les personnes qui disent des vérités difficiles. Récompensez l’appropriation. Éliminez le bruit, réglez ce qui est important et faites en sorte que les bonnes décisions deviennent la norme.
C’est ainsi que l’on construit des systèmes résistants et des entreprises solides.
