Le meilleur livre de Product Management a été écrit en 1513
Le meilleur livre de Product Management n’est pas signé Marty Cagan.
Il s’appelle Le Prince. Son auteur n’a jamais entendu parler de backlog, de sprint review ou de product-market fit. Il ne savait pas ce qu’était un stakeholder, ignorait tout du Net Promoter Score, et n’avait probablement aucune opinion sur Jira.
Pourtant, relire Niccolò Machiavel cinq siècles après sa mort avec les yeux d’un Product Manager, c’est éprouver un sentiment étrange et légèrement inconfortable : celui d’être lu avant d’avoir existé.
Ce texte n’est pas un exercice de style. C’est une tentative sérieuse – avec ce qu’il faut d’autodérision – de montrer que les tensions qui structurent le quotidien d’un Product Manager ont été décrites avec une lucidité troublante par un fonctionnaire florentin du XVIe siècle. La gestion des parties prenantes, la prise de décision sous pression, la question de l’autorité sans pouvoir hiérarchique, la manipulation de la perception : Machiavel a tout vu. Tout nommé. Avec une franchise que nos formations certifiantes n’osent plus vraiment assumer.
Mais avant d’aller plus loin, une mise en garde s’impose.
Machiavel a mauvaise réputation – et en partie à juste titre. Le Prince est un traité du pouvoir écrit pour un prince absolu dans un contexte de violence politique endémique. Y voir un manuel de management sans filtre serait non seulement naïf, mais potentiellement dangereux. Ce qui suit n’est donc pas une invitation à manipuler ses équipes ou à traiter ses utilisateurs comme des sujets. C’est une invitation à lire les dynamiques réelles de l’entreprise avec plus de lucidité – et à en tirer des leçons de pragmatisme, de courage et d’adaptation, tout en sachant ce qu’il faut laisser de côté.
Cela dit : commençons.
Machiavel, brièvement (pour ceux qui n’ont pas relu depuis le lycée)
Le Prince est écrit en 1513, dans une période d’instabilité politique intense en Italie. Machiavel, ancien secrétaire de la République florentine, vient d’être écarté du pouvoir. Il observe, analyse, et rédige ce qui deviendra l’un des textes les plus commentés — et les plus mal cités — de l’histoire de la pensée politique.
Sa thèse centrale est simple et brutale : le pouvoir a ses propres lois, qui ne sont pas celles de la morale ordinaire. Un dirigeant efficace ne demande pas ce qui est juste en soi — il demande ce qui fonctionne. La stabilité de l’État prime sur tout le reste. Et pour l’assurer, le prince doit être capable d’employer tous les moyens nécessaires, vertueux ou non, selon ce que les circonstances exigent. Tous les moyens qu’il aura pris, écrit Machiavel, seront jugés honorables tant que le dirigeant conserve son royaume.
Quatre grands principes structurent sa pensée, et ce sont ces quatre principes que nous allons confronter à la réalité du Product Management.
Le rôle de Product Manager : ce que les fiches de poste ne disent pas vraiment
Avant de construire le parallèle, un bref détour s’impose par ce que le métier implique réellement — au-delà des définitions convenues.
Un Product Manager est officiellement responsable du succès d’un produit de sa conception à sa mise sur le marché. Il agit à l’intersection du business, de la technologie et de l’expérience utilisateur. Marty Cagan, figure de référence du secteur, le résume comme le pont entre l’entreprise, la technologie et l’utilisateur.
Tout cela est juste. Et tout cela rate l’essentiel.
Ce que les définitions officielles omettent, c’est que le Product Manager exerce une responsabilité pleine et entière sur des résultats qu’il ne peut pas atteindre seul, avec des équipes sur lesquelles il n’a aucune autorité hiérarchique, dans un environnement où les intérêts divergent en permanence.
Et, bien sûr, avec des ressources presque toujours insuffisantes par rapport aux ambitions.
Il doit prioriser — ce qui signifie dire non, souvent, à des gens qui ont de bonnes raisons d’entendre oui. Il doit convaincre sans pouvoir imposer. Il doit tenir une vision à long terme tout en gérant des urgences à court terme. Il doit assumer les échecs du produit sans toujours en avoir été la cause, et partager les succès avec des équipes dont il a coordonné le travail sans en avoir dirigé les individus.
C’est précisément cette position — responsabilité sans autorité, influence sans pouvoir formel, nécessité de naviguer dans des dynamiques politiques complexes — qui rend la lecture de Machiavel si étrangement pertinente.
Mieux vaut être craint qu’aimé : quand plaire à tout le monde revient à ne servir personne
C’est la maxime la plus célèbre de Machiavel, et probablement la plus mal comprise.
Il ne dit pas qu’il faut être brutal. Il dit qu’un dirigeant qui gouverne à la recherche de l’amour de ses sujets finit inévitablement par perdre le contrôle de ses décisions. L’amour est changeant, contingent, fragile — il dépend de la bonne humeur des gens et de la capacité du prince à leur donner ce qu’ils veulent. La crainte, elle, repose sur quelque chose de plus solide : le respect de l’autorité, la cohérence des décisions, la certitude que le dirigeant ne plie pas sous la pression.
Transposez cette idée dans le quotidien d’un Product Manager, et quelque chose claque.
Une feature arrive dans le backlog. Elle ne vient pas du process habituel — pas d’une analyse utilisateur, pas d’une hypothèse testée, pas d’une priorisation collective. Elle tombe d’en haut, sans contexte, sans donnée, avec le poids implicite d’une demande qu’on n’est pas vraiment censé refuser.
L’instinct dit non. Pas la bonne priorité. Pas le bon moment. Pas les bonnes ressources.
C’est comme refuser une modification “juste un petit truc” glissée en fin de sprint par un directeur pressé — tout le monde sent que ce n’est pas la bonne décision, mais dire non frontalement n’est jamais facile.
Sauf que dire non à une demande qui vient d’en haut, ce n’est pas une décision technique. C’est un acte politique.
On pourrait acquiescer. Promettre d’y regarder. Laisser traîner poliment jusqu’à ce que la demande se noie dans les sprints. C’est confortable. C’est ce qu’on fait quand on préfère être aimé — ou du moins ne pas être détesté.
Mais un Product Manager qui optimise ses choix pour ne froisser personne finit par ne plus vraiment choisir. Il subit le backlog plutôt qu’il ne le pilote. Il devient le reflet des volontés des autres plutôt que le gardien d’une vision. Et paradoxalement, en cherchant à se faire apprécier de tous, il perd la crédibilité qui lui permettrait d’être vraiment utile à quiconque.
Machiavel mettait également en garde contre l’excès inverse : inspirer la crainte ne signifie pas susciter la haine. Le prince qui écrase tout sur son passage perd l’adhésion dont il a besoin pour gouverner. En Product Management, la traduction est directe : le PM qui dit non à tout, sans explication, sans pédagogie, sans prendre soin de la relation, détruit la confiance qui lui permet d’exercer son influence. Le non doit être motivé, transparent, respectueux — mais il doit rester un non.
La crédibilité à long terme se construit dans ces moments-là. Pas dans les consensus confortables.
Les décisions difficiles, ou la cruauté bien employée
Machiavel introduit dans Le Prince une distinction qui a choqué ses contemporains et continue d’interpeller : il existe selon lui une cruauté bien employée — celle qui sert l’ordre et la stabilité, appliquée vite, clairement, une bonne fois pour toutes — et une cruauté mal employée, répétée, gratuite, qui détruit ce qu’elle prétend protéger.
La première est parfois nécessaire. La seconde est toujours contre-productive.
C’est une distinction que le Product Management connaît bien, même s’il ne l’articule pas ainsi.
Arrêter un projet en cours qui n’atteint pas ses objectifs. Couper une fonctionnalité sur laquelle une équipe a travaillé plusieurs mois. Réduire le périmètre d’une initiative portée avec enthousiasme par des gens compétents et bien intentionnés. Refuser le refacto technique que les développeurs réclament depuis deux sprints parce que les délais ne le permettent pas. Ces décisions font partie du métier. Elles sont douloureuses. Elles créent des frictions. Et pourtant, les éviter — les reporter indéfiniment, les noyer dans des reformulations prudentes, les diluer dans des compromis mous — coûte presque toujours bien plus cher que de les prendre franchement.
Ce que Machiavel apporte ici, c’est une légitimation du courage décisionnel. Non pas la légitimation de la brutalité ou de l’arbitraire — mais l’idée que certaines décisions doivent être prises vite, clairement, une bonne fois pour toutes, plutôt que d’être étalées dans le temps au point de devenir une source d’incertitude permanente pour tout le monde.
Car l’incertitude a un coût que les managers sous-estiment systématiquement. Une équipe qui sait qu’un projet va être arrêté mais attend la confirmation officielle depuis trois semaines ne travaille pas sereinement sur ce projet — elle travaille à moitié, l’œil rivé sur les signaux qui confirmeront ce qu’elle pressent déjà. Une fonctionnalité dont le sort est indécis depuis deux cycles de planification mobilise de l’énergie cognitive à chaque réunion de priorisation, sans jamais être véritablement tranchée. Le flou prolongé n’est pas une forme de bienveillance — c’est une forme de lâcheté managériale qui se déguise en prudence.
Machiavel l’aurait formulé ainsi : mieux vaut faire souffrir une fois, clairement, que laisser souffrir longtemps, vaguement. La cruauté bien employée, c’est celle qui libère — qui ferme une porte définitivement pour permettre à tout le monde d’avancer vers la suivante. La cruauté mal employée, c’est celle qui maintient tout le monde dans l’entre-deux, suspendu à une décision que tout le monde attend et que personne n’ose prendre.
Un Product Manager qui hésite trop longuement sur une décision difficile ne protège pas son équipe. Il la laisse dans le flou. Et le flou, en gestion de produit, est souvent plus destructeur que la mauvaise nouvelle annoncée clairement.
Alliés, ennemis, et la cartographie du pouvoir : le stakeholder management selon Machiavel
Machiavel consacre plusieurs chapitres de Le Prince à ce qu’on appellerait aujourd’hui la gestion des parties prenantes. Il conseille au prince de cartographier soigneusement les forces en présence : qui sont ses alliés naturels, qui sont ses opposants, qui peut basculer d’un camp à l’autre selon les circonstances ? Et surtout : comment entretenir les premières, neutraliser les seconds, et ne jamais se retrouver isolé quand la situation se tend ?
Un Product Manager évolue dans un écosystème d’une complexité similaire — à cette différence près qu’il n’a généralement aucune autorité hiérarchique sur les personnes dont il a besoin pour avancer.
Il dépend des développeurs pour construire. Des designers pour penser l’expérience. Du marketing pour aller sur le marché. Des équipes commerciales pour comprendre les besoins clients. De la direction pour obtenir les ressources et la légitimité. Du support pour remonter ce qui ne fonctionne pas. Et de dizaines de parties prenantes intermédiaires qui ont chacune leur agenda, leurs contraintes, leurs victoires à revendiquer.
Dans cet environnement, la naïveté est un luxe qu’on ne peut pas se permettre. Non pas qu’il faille voir des ennemis partout — mais il faut comprendre les dynamiques réelles, pas les dynamiques supposées. Le directeur commercial qui soutient la roadmap en réunion mais la critique en coulisses n’est pas un allié fiable. Le développeur senior qui remet en question les décisions en public mais aide à les défendre auprès de l’équipe est peut-être le meilleur atout disponible.
Machiavel conseillait au prince d’identifier avec précision où se situe réellement le pouvoir dans son territoire — pas le pouvoir formel, mais le pouvoir d’influence : qui fait changer les décisions, qui bloque les initiatives, qui emporte l’adhésion ? C’est exactement le travail de fond qu’un PM doit mener dans son organisation, et que personne ne lui enseigne formellement dans aucune formation certifiante.
S’assurer d’avoir les bons alliés dans son camp avant de défendre une décision difficile, anticiper les objections de ceux qui s’y opposeront, préparer les arguments qui les feront changer de position — ou à défaut, neutraliser leur influence — : c’est de la politique, au sens noble du terme. Machiavel appellerait ça du renard. Les frameworks agiles appellent ça du stakeholder management. C’est la même chose.
La virtù face à la fortune – l’agilité comme philosophie, pas comme framework
C’est peut-être le concept le plus riche que Machiavel introduit dans Le Prince : l’opposition entre la virtù et la fortune.
La fortune désigne tout ce qui échappe au contrôle du prince : les circonstances, le hasard, les retournements imprévus. Elle gouverne, selon Machiavel, environ la moitié des affaires humaines. L’autre moitié appartient à la virtù — non pas la vertu morale, mais la capacité du dirigeant à s’adapter, à anticiper, à changer de méthode quand les circonstances l’exigent.
Machiavel est explicite sur ce point : les dirigeants qui échouent sont souvent ceux qui ont réussi par une méthode et qui, par entêtement ou incapacité, continuent de l’appliquer même quand le contexte a changé. Très peu d’hommes, écrit-il, savent s’écarter du chemin où les pousse leur nature. Ceux qui prospèrent sont ceux qui savent lire l’évolution de la situation et ajuster leur comportement en conséquence.
En Product Management, cette idée résonne avec une précision presque embarrassante.
Le marché change. Les utilisateurs évoluent. Un concurrent émerge. Une technologie déplace les usages. Une hypothèse fondatrice se révèle fausse au contact de la réalité. Que fait le Product Manager dans ces moments-là ?
S’il est trop attaché à son plan initial — à sa roadmap soigneusement construite, à ses convictions sur ce que les utilisateurs veulent — il risque de continuer dans une direction que les faits ont déjà invalidée. Par orgueil, par habitude, ou simplement parce que changer de cap demande un effort politique considérable dans une organisation.
Et c’est là que les méthodes agiles modernes rejoignent une idée vieille de cinq siècles.
La virtù machiavélienne, c’est exactement ce que les méthodologies agiles tentent d’institutionnaliser : la capacité à tester rapidement, à apprendre de l’échec, à pivoter sans que ce pivot soit vécu comme une défaite. Fail fast, learn faster est une formulation moderne d’une idée vieille de cinq siècles.
Mais Machiavel va plus loin que les frameworks agiles sur un point : il insiste sur le courage que demande l’adaptation. Changer de méthode quand on a publiquement défendu une direction, c’est accepter une forme de vulnérabilité. C’est admettre qu’on s’était peut-être trompé. En entreprise comme dans les principautés italiennes, ce courage-là est rare — et c’est précisément pour ça qu’il distingue les leaders durables des autres.
L’art des apparences – pourquoi la perception est une compétence produit à part entière
C’est probablement le principe de Machiavel qui met le plus mal à l’aise dans un contexte professionnel moderne — et pourtant, c’est peut-être celui qui décrit avec le plus de précision une réalité que peu de gens osent nommer franchement.
Machiavel conseille au prince de maîtriser l’art de simuler et dissimuler. De paraître vertueux, honnête, fiable — car les hommes jugent sur l’apparence. Tout le monde voit ce que tu parais, écrit-il, peu perçoivent qui tu es réellement. Et un prince dont tous les défauts sont visibles perd l’autorité morale dont il a besoin pour gouverner.
Un Product Manager passe une partie significative de son temps à gérer des perceptions. La perception que l’équipe a du produit. La perception que la direction a de l’avancement. La perception que les utilisateurs ont des changements introduits. La perception que les parties prenantes ont de sa compétence et de son jugement.
Et dans cet exercice, il y a une part d’art — au sens plein du terme.
Annoncer une modification impopulaire en insistant sur les bénéfices à long terme pour l’utilisateur, c’est une forme de mise en scène. Cadrer une décision difficile comme un choix stratégique plutôt que comme une contrainte subie, c’est du contrôle du récit. Présenter un pivot comme une évolution naturelle plutôt que comme un aveu d’erreur, c’est gérer la perception de façon à préserver la confiance — et donc la capacité à continuer à travailler.
La différence avec Machiavel est ici importante : là où il encourageait ouvertement le mensonge stratégique, un Product Manager efficace vise à contrôler le récit sans trahir la réalité. L’authenticité et la transparence ont une valeur pratique, pas seulement morale — dans un environnement d’équipe, le mensonge se détecte vite et détruit la confiance de façon durable.
Mais l’idée que les apparences comptent, que la façon dont on communique une décision est aussi importante que la décision elle-même, que soigner son image n’est pas de la vanité mais de la stratégie : ça, Machiavel l’avait compris bien avant le premier cours de communication corporate.
Prévenir et gérer les crises – ou comment un prince florentin décrivait la gestion des risques produit
Le Prince contient un conseil que tout chef de projet devrait relire régulièrement : les maux qu’on prévoit de loin se guérissent aisément, mais si on les laisse approcher, le remède n’arrive plus à temps.
Machiavel parle de complots et de rébellions. Mais la mécanique est identique pour un Product Manager.
Le mécontentement utilisateur qui enfle silencieusement dans les données de support avant d’exploser en bad buzz. Le désaccord latent entre deux équipes qui se cristallise au mauvais moment, en plein sprint, à trois semaines d’un lancement. La dette technique qui s’accumule sans qu’on l’adresse jusqu’au jour où elle paralyse la capacité à livrer.
Dans tous ces cas, le problème n’est généralement pas imprévisible. Les signaux sont là — faibles, parfois, mais présents. Ce qui manque, c’est la volonté d’intervenir tôt, quand l’intervention est encore peu coûteuse, plutôt que d’attendre que la situation se soit suffisamment dégradée pour qu’on ne puisse plus l’ignorer.
Machiavel conseillait de traiter les troubles à leur naissance, de façon décisive et unique — pour éviter qu’ils ne s’enracinent et ne deviennent incontrôlables. En Product Management, cela se traduit par une vigilance permanente aux signaux faibles, et par la capacité à intervenir rapidement dès qu’un problème émerge, plutôt que d’espérer qu’il se résorbe de lui-même. Retirer temporairement une fonctionnalité qui génère des retours négatifs et communiquer immédiatement sur les correctifs à venir vaut toujours mieux que de laisser le bad buzz s’installer et prendre de l’ampleur.
Les limites de l’analogie – ce qu’il faut savoir laisser de côté
Jusqu’ici, nous avons cherché les convergences. Il est temps d’être honnête sur les divergences — et elles sont réelles, substantielles, et méritent d’être traitées sérieusement.
Sur l’éthique d’abord. Machiavel assume que la morale doit s’effacer devant la raison d’État. Transposé en entreprise sans filtre, ce principe conduit droit aux dérives : déployer des dark patterns pour atteindre des métriques d’engagement, survendre une fonctionnalité non prête pour satisfaire un objectif commercial, manipuler les chiffres pour présenter un tableau plus flatteur à la direction. À court terme, ces tactiques peuvent sembler efficaces. À long terme, elles érodent la confiance des utilisateurs, exposent l’entreprise à des risques réglementaires croissants, et détruisent la réputation de ceux qui les pratiquent. La fin ne justifie pas tous les moyens — surtout quand les moyens finissent par compromettre la fin elle-même.
Sur la confiance ensuite. Machiavel encourage le prince à garder secrets ses véritables intentions, à ne jamais se lier trop étroitement à ses alliés, à instrumentaliser ses conseillers. Dans une équipe produit, cette posture détruit exactement ce qui rend l’intelligence collective possible. Un Product Manager qui monte les équipes les unes contre les autres pour asseoir son autorité, ou qui dissimule des informations cruciales à ses collaborateurs pour mieux les contrôler, crée un climat de suspicion généralisée. La réussite d’un produit tech repose sur la collaboration, la transparence et la confiance mutuelle. Un manager perçu comme opaque ou manipulateur perd rapidement le soutien dont il a besoin pour avancer — et les talents, qui ont des options, partent.
Sur le style de leadership enfin. Le management par la peur — menaces voilées, stress systémique, opacité calculée — peut produire des résultats à court terme dans certains contextes. Mais il est peu soutenable dans la durée, et de moins en moins toléré dans les environnements tech. Un Product Manager qui fait régner la tension permanente finit par perdre les personnes dont il avait le plus besoin. Et comme Machiavel lui-même le prévenait : à vouloir être craint à tout prix, on finit par être haï. En entreprise, le trajet est souvent plus court qu’on ne le croit — et la chute, plus brutale.
Il y a enfin une limite structurelle que l’analogie tend à masquer : Machiavel donne au prince l’image d’un stratège pouvant tout maîtriser par sa ruse et sa volonté. Un Product Manager n’est pas un souverain tout-puissant. Il opère dans des structures complexes où le pouvoir est diffus, partagé, souvent invisible. Vouloir orchestrer chaque variable en coulisses mène au surmenage ou à la micro-gestion inefficace. La puissance de la collaboration et de la confiance mutuelle — que Machiavel sous-estimait profondément — est précisément ce qui permet à une équipe produit de produire quelque chose de supérieur à ce qu’un individu seul, aussi stratège soit-il, aurait pu imaginer.
Mais c’est aussi dans cette interdépendance que réside la vraie force d’un collectif produit bien aligné : aucun stratège ne vaut une équipe soudée qui avance dans la même direction.
Ce que Machiavel apporte vraiment à un Product Manager
Après les parallèles et les limites, que reste-t-il ? Quelque chose de plus précieux qu’un manuel pratique : une grille de lecture.
La lucidité sur les dynamiques de pouvoir. Les organisations ne fonctionnent pas comme leurs organigrammes le laissent croire. Les décisions ne se prennent pas toujours là où on pense qu’elles se prennent. Les intérêts des individus ne coïncident pas toujours avec les intérêts de l’entreprise. Un Product Manager qui a lu Machiavel regarde ces réalités en face, sans naïveté — ce qui lui permet de mieux y naviguer. Comprendre qu’un sponsor peut avoir un agenda caché aide à anticiper les objections plutôt que d’en être surpris. Identifier les véritables centres d’influence permet d’y investir le bon niveau d’énergie. Machiavel invite à décrypter les comportements humains avec réalisme, ce qui, bien utilisé, améliore considérablement la gestion des parties prenantes.
Le courage décisionnel comme discipline. Dans un monde professionnel qui valorise souvent le consensus et l’harmonie, Machiavel rappelle qu’un leader doit parfois décider seul, contre l’avis général, et assumer les conséquences. Pour un Product Manager soumis à la pression permanente de nombreuses parties prenantes, cette légitimation du courage décisionnel peut être salutaire. Elle aide à sortir de l’hésitation paralysante — ce que les Anglo-Saxons appellent l’analysis paralysis — et à trancher en s’appuyant sur les données et la vision, plutôt que de chercher constamment l’approbation de tous. Machiavel libère en quelque sorte le PM de la peur d’être impopulaire à court terme, tant que l’objectif final — le succès du produit — est servi.
L’adaptabilité comme vertu active. La virtù machiavélienne n’est pas un talent inné — c’est une discipline. Celle de rester attentif aux évolutions du contexte, de ne pas se laisser enfermer dans ses certitudes, de changer de méthode quand les circonstances l’exigent. Un PM qui a intégré cette leçon sera peut-être plus attentif aux signaux faibles — comme un prince aux rumeurs de complot — et n’hésitera pas à prendre des décisions drastiques pour éviter la catastrophe : pivot stratégique, arrêt d’un projet non porteur, réorientation rapide face à un concurrent inattendu. Cette réactivité n’est pas de l’impulsivité — c’est la virtù au travail.
La gestion de la perception comme compétence à part entière. Communiquer ne suffit pas. Communiquer de façon à ce que les bonnes personnes comprennent les bonnes choses au bon moment, et soient disposées à agir en conséquence — c’est un art. Machiavel en a fait la théorie avec une franchise qu’on ne retrouve guère dans les manuels de management contemporains. Soigner l’image du produit et celle de son propre leadership n’est pas de la vanité — c’est une condition de l’efficacité.
En guise de conclusion
Il y a quelque chose de légèrement vertigineux à réaliser que les tensions fondamentales du Product Management — l’autorité sans pouvoir hiérarchique, la décision sous incertitude, la gestion des intérêts divergents, la nécessité de contrôler son image tout en restant authentique — n’ont pas été inventées par la Silicon Valley.
Elles ont été décrites avec une précision clinique par un fonctionnaire florentin du XVIe siècle qui avait simplement pris le temps d’observer comment le pouvoir fonctionne réellement, plutôt que de se contenter de la façon dont on aimerait qu’il fonctionne.
Le Prince n’est pas un livre de management. Mais c’est un livre sur les êtres humains aux prises avec le pouvoir, la décision, l’incertitude et la nécessité de faire avancer des choses malgré tout. Et en cela, il parle à quiconque a déjà essayé de faire adopter une vision dans une organisation complexe, de dire non à quelqu’un qui aurait préféré entendre oui, ou de pivoter une stratégie sans perdre la confiance de son équipe.
L’apport de Machiavel doit être filtré – il ne s’agit pas d’en faire un guide moral, mais un miroir grossissant des enjeux de pouvoir. Un Product Manager avisé pourra en tirer des leçons de pragmatisme, de courage et de clairvoyance, tout en rejetant les aspects les plus sombres. Comme le résume avec justesse un spécialiste du sujet, en faisant abstraction des éléments négatifs, les écrits de Machiavel offrent des leçons intemporelles directement applicables aux défis du management – de l’autorité à la gestion d’équipe en passant par l’influence stratégique.
Machiavel ne vous dira pas comment prioriser votre backlog. Mais il vous rappellera, avec l’élégance cruelle du classique, que le leadership n’a jamais vraiment été une question de process.
Et que les hommes qui font bouger les choses – dans les principautés italiennes comme dans les organisations tech – ont toujours été ceux qui acceptaient de regarder la réalité du pouvoir en face, sans se raconter d’histoires.