[et_pb_section fb_built=\u00a0\u00bb1″ admin_label=\u00a0\u00bbSection\u00a0\u00bb _builder_version=\u00a0\u00bb4.22.0″ _module_preset=\u00a0\u00bbdefault\u00a0\u00bb custom_margin=\u00a0\u00bb0px||0px||false|false\u00a0\u00bb custom_padding=\u00a0\u00bb0px||0px||false|false\u00a0\u00bb locked=\u00a0\u00bboff\u00a0\u00bb global_colors_info=\u00a0\u00bb{}\u00a0\u00bb][et_pb_row column_structure=\u00a0\u00bb1_4,3_4″ _builder_version=\u00a0\u00bb4.27.0″ _module_preset=\u00a0\u00bbdefault\u00a0\u00bb custom_padding=\u00a0\u00bb50px||||false|false\u00a0\u00bb custom_css_main_element=\u00a0\u00bbz-index:0!important;\u00a0\u00bb global_colors_info=\u00a0\u00bb{}\u00a0\u00bb][et_pb_column type=\u00a0\u00bb1_4″ disabled_on=\u00a0\u00bbon|on|off\u00a0\u00bb _builder_version=\u00a0\u00bb4.22.0″ _module_preset=\u00a0\u00bbdefault\u00a0\u00bb custom_padding=\u00a0\u00bb||||false|false\u00a0\u00bb sticky_position=\u00a0\u00bbtop\u00a0\u00bb sticky_offset_top=\u00a0\u00bb100px\u00a0\u00bb sticky_limit_bottom=\u00a0\u00bbsection\u00a0\u00bb motion_trigger_start=\u00a0\u00bbtop\u00a0\u00bb global_colors_info=\u00a0\u00bb{}\u00a0\u00bb][et_pb_text admin_label=\u00a0\u00bbindice\u00a0\u00bb _builder_version=\u00a0\u00bb4.27.5″ _module_preset=\u00a0\u00bbdefault\u00a0\u00bb custom_margin=\u00a0\u00bb||0px||false|false\u00a0\u00bb custom_padding=\u00a0\u00bb||14px||false|false\u00a0\u00bb link_option_url=\u00a0\u00bb#1″ global_colors_info=\u00a0\u00bb{}\u00a0\u00bb]<\/p>\n
Sections<\/strong><\/p>\n [\/et_pb_text][\/et_pb_column][et_pb_column type=\u00a0\u00bb3_4″ _builder_version=\u00a0\u00bb4.27.0″ _module_preset=\u00a0\u00bbdefault\u00a0\u00bb custom_css_main_element=\u00a0\u00bbz-index:0!important;\u00a0\u00bb global_colors_info=\u00a0\u00bb{}\u00a0\u00bb][et_pb_text admin_label=\u00a0\u00bbseccion\u00a0\u00bb module_id=\u00a0\u00bb1″ module_class=\u00a0\u00bbittopicscontent\u00a0\u00bb _builder_version=\u00a0\u00bb4.27.5″ _module_preset=\u00a0\u00bbdefault\u00a0\u00bb z_index=\u00a0\u00bb0″ custom_margin=\u00a0\u00bb0px||0px||true|false\u00a0\u00bb custom_padding=\u00a0\u00bb0px||0px||false|false\u00a0\u00bb custom_css_main_element=\u00a0\u00bbfont-family:%22Pandora-Light%22;\u00a0\u00bb locked=\u00a0\u00bboff\u00a0\u00bb global_colors_info=\u00a0\u00bb{}\u00a0\u00bb]Grandir fait mal, comme le disait cette ancienne s\u00e9rie avec Kirk Cameron dont seuls les plus anciens se souviennent. C\u2019est l\u2019une de ces v\u00e9rit\u00e9s (celle sur la croissance, pas sur l\u2019\u00e2ge) que personne ne mentionne lors des r\u00e9unions strat\u00e9giques remplies de graphiques ascendants et de toasts aux nouveaux clients. Mais dans les tranch\u00e9es d\u2019un Managed Service Provider (MSP), une croissance incontr\u00f4l\u00e9e ressemble davantage \u00e0 une lente asphyxie qu\u2019\u00e0 une victoire<\/strong>.<\/p>\n Vu d\u2019en haut, la musique est toujours la m\u00eame : \u00ab Ce n\u2019est pas grave, si nous obtenons dix nouveaux clients, nous embauchons deux techniciens suppl\u00e9mentaires. \u00bb Mais la r\u00e9alit\u00e9 ne fonctionne pas avec des \u00e9quations aussi simples, et la croissance implique n\u00e9cessairement un chaos impr\u00e9visible et non lin\u00e9aire.<\/p>\n Ce qui, avec cinq clients, n\u2019est qu\u2019une petite g\u00eane (\u00ab Javier doit v\u00e9rifier et red\u00e9marrer manuellement les services chaque jour, parce que l\u2019utilisateur est la force la plus destructrice de l\u2019univers \u00bb), avec cinquante clients devient pousser la pierre de Sisyphe en haut de la colline.<\/p>\n Scaler un MSP ne consiste pas \u00e0 accumuler davantage de personnes<\/strong> dans la bataille du Service Desk comme au Moyen \u00c2ge. Il s\u2019agit de changer les r\u00e8gles du jeu afin que la charge de travail ne d\u00e9pende pas du nombre d\u2019actifs g\u00e9r\u00e9s<\/strong>.<\/p>\n Si pour doubler le chiffre d\u2019affaires nous devons doubler les effectifs, nous n\u2019avons pas un mod\u00e8le scalable, mais un cabinet de conseil d\u00e9guis\u00e9 qui, t\u00f4t ou tard, d\u00e9vorera sa marge.<\/p>\n Il existe un point d\u2019inflexion dans le cycle de vie de tout prestataire de services. Au d\u00e9part, le \u00ab mode h\u00e9ros \u00bb fonctionne. Vous avez deux techniciens brillants qui connaissent par c\u0153ur le mot de passe du firewall du client A et les cartes perfor\u00e9es du System\/370 que le client B n\u2019a pas d\u00e9branch\u00e9 depuis 1978. Le service est personnel, rapide\u2026 et artisanal.<\/p>\n Puis le succ\u00e8s arrive, cause fr\u00e9quente de disparition de nombreuses initiatives, car il entra\u00eene davantage de tickets, d\u2019alertes et d\u2019urgences.<\/p>\n Soudain, le \u00ab mode h\u00e9ros \u00bb devient le goulet d\u2019\u00e9tranglement<\/strong>.<\/p>\n Ces techniciens brillants n\u2019ont plus le temps d\u2019impl\u00e9menter des am\u00e9liorations, gaspillant leur savoir avanc\u00e9 \u00e0 \u00e9coper l\u2019eau. De plus, cette connaissance reste enferm\u00e9e dans leurs t\u00eates, les transformant de g\u00e9nies en points uniques de d\u00e9faillance.<\/p>\n Si Javier tombe malade, le client B panique et m\u00eame IBM ne sait plus parler System\/370.<\/p>\n Les MSP chutent g\u00e9n\u00e9ralement \u00e0 cause de conceptions op\u00e9rationnelles m\u00e9diocres<\/strong>, et non par manque de talent.<\/p>\n Cela s\u2019explique par le fait qu\u2019ils op\u00e8rent sous un mod\u00e8le de support r\u00e9actif<\/strong> et attendent que quelque chose casse avant de le r\u00e9parer. \u00c0 petite \u00e9chelle, cela reste g\u00e9rable ; \u00e0 grande \u00e9chelle, c\u2019est un hara-kiri.<\/p>\n Cro\u00eetre sans transformer l\u2019op\u00e9ration est la mani\u00e8re la plus rapide de d\u00e9truire la r\u00e9putation qui nous a permis de cro\u00eetre au d\u00e9part.<\/p>\n Grandir fait mal, comme le disait cette ancienne s\u00e9rie avec Kirk Cameron dont seuls les plus anciens se souviennent. C\u2019est l\u2019une de ces v\u00e9rit\u00e9s (celle sur la croissance, pas sur l\u2019\u00e2ge) que personne ne mentionne lors des r\u00e9unions strat\u00e9giques remplies de graphiques ascendants et de toasts aux nouveaux clients. Mais dans les tranch\u00e9es d\u2019un Managed Service Provider (MSP), une croissance incontr\u00f4l\u00e9e ressemble davantage \u00e0 une lente asphyxie qu\u2019\u00e0 une victoire<\/strong>.<\/p>\n Vu d\u2019en haut, la musique est toujours la m\u00eame : \u00ab Ce n\u2019est pas grave, si nous obtenons dix nouveaux clients, nous embauchons deux techniciens suppl\u00e9mentaires. \u00bb Mais la r\u00e9alit\u00e9 ne fonctionne pas avec des \u00e9quations aussi simples, et la croissance implique n\u00e9cessairement un chaos impr\u00e9visible et non lin\u00e9aire.<\/p>\n Ce qui, avec cinq clients, n\u2019est qu\u2019une petite g\u00eane (\u00ab Javier doit v\u00e9rifier et red\u00e9marrer manuellement les services chaque jour, parce que l\u2019utilisateur est la force la plus destructrice de l\u2019univers \u00bb), avec cinquante clients devient pousser la pierre de Sisyphe en haut de la colline.<\/p>\n Scaler un MSP ne consiste pas \u00e0 accumuler davantage de personnes<\/strong> dans la bataille du Service Desk comme au Moyen \u00c2ge. Il s\u2019agit de changer les r\u00e8gles du jeu afin que la charge de travail ne d\u00e9pende pas du nombre d\u2019actifs g\u00e9r\u00e9s<\/strong>.<\/p>\n Si pour doubler le chiffre d\u2019affaires nous devons doubler les effectifs, nous n\u2019avons pas un mod\u00e8le scalable, mais un cabinet de conseil d\u00e9guis\u00e9 qui, t\u00f4t ou tard, d\u00e9vorera sa marge.<\/p>\n Il existe un point d\u2019inflexion dans le cycle de vie de tout prestataire de services. Au d\u00e9part, le \u00ab mode h\u00e9ros \u00bb fonctionne. Vous avez deux techniciens brillants qui connaissent par c\u0153ur le mot de passe du firewall du client A et les cartes perfor\u00e9es du System\/370 que le client B n\u2019a pas d\u00e9branch\u00e9 depuis 1978. Le service est personnel, rapide\u2026 et artisanal.<\/p>\n Puis le succ\u00e8s arrive, cause fr\u00e9quente de disparition de nombreuses initiatives, car il entra\u00eene davantage de tickets, d\u2019alertes et d\u2019urgences.<\/p>\n Soudain, le \u00ab mode h\u00e9ros \u00bb devient le goulet d\u2019\u00e9tranglement<\/strong>.<\/p>\n Ces techniciens brillants n\u2019ont plus le temps d\u2019impl\u00e9menter des am\u00e9liorations, gaspillant leur savoir avanc\u00e9 \u00e0 \u00e9coper l\u2019eau. De plus, cette connaissance reste enferm\u00e9e dans leurs t\u00eates, les transformant de g\u00e9nies en points uniques de d\u00e9faillance.<\/p>\n Si Javier tombe malade, le client B panique et m\u00eame IBM ne sait plus parler System\/370.<\/p>\n Les MSP chutent g\u00e9n\u00e9ralement \u00e0 cause de conceptions op\u00e9rationnelles m\u00e9diocres<\/strong>, et non par manque de talent.<\/p>\n Cela s\u2019explique par le fait qu\u2019ils op\u00e8rent sous un mod\u00e8le de support r\u00e9actif<\/strong> et attendent que quelque chose casse avant de le r\u00e9parer. \u00c0 petite \u00e9chelle, cela reste g\u00e9rable ; \u00e0 grande \u00e9chelle, c\u2019est un hara-kiri.<\/p>\n Cro\u00eetre sans transformer l\u2019op\u00e9ration est la mani\u00e8re la plus rapide de d\u00e9truire la r\u00e9putation qui nous a permis de cro\u00eetre au d\u00e9part.<\/p>\n Il est facile de pr\u00eacher depuis la chaire de la th\u00e9orie, je le sais, mais en pratique, scaler n\u2019est pas un chemin en descente et nous rencontrerons des mines<\/strong>, dont certaines auront \u00e9t\u00e9 pos\u00e9es par nous-m\u00eames. L\u2019adr\u00e9naline est tr\u00e8s addictive et il existe une satisfaction imm\u00e9diate \u00e0 \u00e9teindre un incendie. Le client vous remercie si vous \u00eates rapide, vous vous sentez utile, vous avez d\u00e9montr\u00e9 vos comp\u00e9tences et prouv\u00e9 au management interm\u00e9diaire que l\u2019IA le remplacera avant de vous remplacer. \u00ab Demande \u00e0 Luis, c\u2019est lui qui sait comment \u00e7a fonctionne. \u00bb Un outil de monitoring pour les r\u00e9seaux, un autre pour les sauvegardes, quelqu\u2019un conserve les mots de passe dans un Excel en violation de multiples r\u00e9glementations, et le logiciel de ticketing est un open source non maintenu parce que l\u2019ancien CTO pensait \u00e9conomiser. Dire oui \u00e0 chaque exigence de chaque client est une strat\u00e9gie commerciale tentante au d\u00e9but, parfois m\u00eame valable, mais elle devient d\u00e9sastreuse sur le plan op\u00e9rationnel et financier \u00e0 long terme<\/strong>. Lorsque Homer Simpson est engag\u00e9 par Hank Scorpio pour optimiser ses op\u00e9rations de domination mondiale, sa strat\u00e9gie principale consiste \u00e0 dire aux techniciens de faire plus vite ce qu\u2019ils sont en train de faire. Pour sortir du cycle r\u00e9actif et construire une op\u00e9ration capable de cro\u00eetre, nous devons atteindre les objectifs suivants :<\/p>\n La seule bonne incidence<\/a> est celle qui ne s\u2019ouvre jamais en tant que ticket. La productisation des services s\u2019est r\u00e9cemment popularis\u00e9e et nous devons nous inspirer de cette philosophie d\u2019entreprise. D\u00e9finir un stack technologique standard et des politiques de configuration de base<\/strong> pour tous les clients permet de mettre en place des scripts et des processus de maintenance valables pour 500 machines comme pour 5. Leurs processus sont tellement standardis\u00e9s que lorsqu\u2019une personne part et qu\u2019un novice la remplace, le go\u00fbt des frites ne change pas, car elles sont toujours pr\u00e9par\u00e9es de la m\u00eame fa\u00e7on. Le nouveau n\u2019a qu\u2019\u00e0 suivre des \u00e9tapes pr\u00e9d\u00e9finies conformes aux meilleures pratiques.<\/p>\n L\u2019automatisation n\u2019est pas une mode, mais une approche consistant \u00e0 identifier des t\u00e2ches r\u00e9p\u00e9titives \u00e0 faible valeur<\/strong> (nettoyage de disques, red\u00e9marrage de services, d\u00e9ploiement de correctifs\u2026) et \u00e0 les confier aux machines<\/strong>. Les outils de monitoring et de gestion<\/a> font toute la diff\u00e9rence, mais nous n\u2019avons pas besoin de celui qui poss\u00e8de le plus de voyants lumineux. Nous avons besoin d\u2019outils con\u00e7us pour les MSP permettant une gestion multi-clients simple<\/strong>. Il ne s\u2019agit plus seulement de dire que l\u2019on ne peut pas g\u00e9rer ce que l\u2019on ne mesure pas ; ce que l\u2019on ne mesure pas se d\u00e9t\u00e9riore aussi, comme une pi\u00e8ce o\u00f9 l\u2019on ne met jamais les pieds. Une op\u00e9ration \u00e0 grande \u00e9chelle se pilote avec des donn\u00e9es, pas avec des sensations<\/strong>. Ou des \u00ab vibes \u00bb, comme on dit aujourd\u2019hui.<\/p>\n D\u00e9tailler toutes les \u00e9tapes vers cette efficacit\u00e9 op\u00e9rationnelle<\/a> transformerait cet article en Le Seigneur des Anneaux.<\/p>\n C\u2019est pourquoi nous avons cr\u00e9\u00e9 un cluster de contenus abordant en d\u00e9tail les domaines cl\u00e9s o\u00f9 se joue la bataille de la scalabilit\u00e9 dans un MSP, et expliquant comment :<\/p>\n Une op\u00e9ration \u00e0 grande \u00e9chelle ne doit pas \u00eatre une \u00eele, mais \u00eatre reli\u00e9e par des vases communicants au reste de la strat\u00e9gie technique et \u00e0 ses dimensions :<\/p>\n Scaler un MSP ne rel\u00e8ve pas de la taille \u2014 m\u00eame si cela compte dans d\u2019autres domaines de la vie \u2014 ni de la force brute, mais d\u2019un design intelligent.<\/p>\n\n
Le v\u00e9ritable d\u00e9fi de la croissance dans les MSP<\/h2>\n
Le v\u00e9ritable d\u00e9fi de la croissance dans les MSP<\/h2>\n
Les principaux freins \u00e0 la scalabilit\u00e9 op\u00e9rationnelle<\/h2>\n
\nPour les \u00e9viter, voici des sch\u00e9mas r\u00e9currents observ\u00e9s chez les MSP stagnants :<\/p>\n1. Le culte du support r\u00e9actif<\/h3>\n
\nMais vivre d\u2019adr\u00e9naline \u00e9puise et vivre en mode r\u00e9action emp\u00eache la pr\u00e9vention<\/strong>.
\nSi notre \u00e9quipe passe 80 % de son temps \u00e0 r\u00e9agir aujourd\u2019hui, personne ne construit l\u2019infrastructure qui \u00e9vitera ces incendies demain.<\/p>\n2. La d\u00e9pendance au savoir personnel et aux g\u00e9nies habituels<\/h3>\n
\nVoil\u00e0 la sentence de mort de la scalabilit\u00e9 et une goutte de plus dans le verre de Luis, qui, entre deux urgences, met \u00e0 jour son CV.
\nSi la connaissance n\u2019est pas document\u00e9e dans une Wiki ou une base de connaissances compl\u00e8te et \u00e0 jour, la rotation du personnel ira \u00e0 Warp 8 et l\u2019int\u00e9gration des nouveaux prendra une \u00e9ternit\u00e9.<\/p>\n3. Outils fragment\u00e9s<\/h3>\n
\nL\u2019absence d\u2019une \u00ab source unique de v\u00e9rit\u00e9 \u00bb oblige les techniciens \u00e0 passer d\u2019une console \u00e0 l\u2019autre, perdant du contexte et du temps \u00e0 chaque changement.
\nSans vision centralis\u00e9e, l\u2019automatisation est impossible.<\/strong><\/p>\n4. Manque de standardisation (le syndrome du \u00ab sur-mesure \u00bb)<\/h3>\n
\nSi chaque client poss\u00e8de une configuration de sauvegarde diff\u00e9rente et une politique de s\u00e9curit\u00e9 unique, nous g\u00e9rerons en permanence des exceptions sans pouvoir automatiser quoi que ce soit<\/strong>.<\/p>\nLes piliers d\u2019une op\u00e9ration MSP \u00e0 grande \u00e9chelle<\/h2>\n
\nIls serrent les dents et s\u2019activent, mais cette strat\u00e9gie ne dure que cinq minutes.<\/p>\n1. R\u00e9duction du support r\u00e9actif gr\u00e2ce \u00e0 la d\u00e9tection pr\u00e9coce<\/h3>\n
\nLa monitorisation moderne ne doit pas se limiter \u00e0 indiquer qu\u2019un serveur est tomb\u00e9 (ce qui arrive toujours trop tard) ; elle doit nous alerter lorsque les sch\u00e9mas d\u2019usage indiquent qu\u2019il va tomber<\/strong> dans deux heures.
\nD\u00e9tecter la d\u00e9gradation du service avant le client est la seule mani\u00e8re de prot\u00e9ger les SLA<\/strong> et la sant\u00e9 cardiaque de l\u2019\u00e9quipe.<\/p>\n2. Standardisation technique et des processus<\/h3>\n
\nId\u00e9alement, nous devrions vendre des produits plut\u00f4t que des projets, car les premiers scalent par nature, tandis que les seconds non.<\/p>\n
\nLa standardisation est le pr\u00e9alable \u00e0 l\u2019automatisation, \u00e0 l\u2019image de McDonald\u2019s ou Burger King.<\/p>\n3. Automatisation \u00e0 impact r\u00e9el<\/h3>\n
\nCette automatisation a un impact mesurable : des heures de techniciens lib\u00e9r\u00e9es<\/strong>.
\nSi un bot bas\u00e9 sur un LLM correctement entra\u00een\u00e9 peut r\u00e9soudre 30 % des tickets simples de niveau 1, nous scalons de 30 % sans recruter.<\/p>\n4. Des outils adapt\u00e9s aux MSP, pas seulement modernes<\/h3>\n
\nLa s\u00e9gr\u00e9gation des donn\u00e9es, les permissions granulaires et la capacit\u00e9 d\u2019appliquer des politiques globales ou sp\u00e9cifiques par client sont des fonctions critiques pour ne pas perdre le contr\u00f4le en passant de 10 \u00e0 100 clients.<\/p>\n5. Mesure continue et obsessionnelle<\/h3>\n
\nCela dit, il faut mesurer les bonnes choses, pas celles qui flattent l\u2019ego<\/strong>.
\nPeu importe combien de tickets nous fermons ; ce qui importe, c\u2019est combien nous en recevons par endpoint. De m\u00eame, le v\u00e9ritable MTTR et la rentabilit\u00e9 par client sont essentiels.<\/p>\nLe chemin vers l\u2019efficacit\u00e9 op\u00e9rationnelle<\/h2>\n
\n
La scalabilit\u00e9 et sa relation avec les autres domaines cl\u00e9s du MSP<\/h2>\n
\n