J’entends souvent parler de carrière comme d’un escalier. Une marche après l’autre, un titre après l’autre, et au bout une sorte de cohérence. Puis je regarde la mienne et ça me fait sourire — je n’y vois pas un escalier. J’y vois plutôt une série de pièces différentes, chacune avec une fenêtre sur un pan du marché des services IT.
Ce n’est pas un récit « motivationnel ». C’est plutôt une note de carnet, presque une anatomie. Parce qu’a posteriori je me rends compte que chaque phase m’a laissé une lentille différente. Et aujourd’hui, comme Head of Tech & partner dans une petite ICT, ces lentilles commencent vraiment à se superposer.
La chose étrange des carrières non linéaires
Les carrières linéaires n’ont peut-être jamais existé vraiment, mais on y a cru un temps. Moi en tout cas. Puis je suis passé d’Interface Developer dans l’un des plus grands groupes e-commerce de luxe européens (avant son entrée dans l’orbite Richemont) à CTO d’une startup deep-tech sur l’oil & gas, jusqu’à gérer aujourd’hui un portefeuille de projets très divers dans une boîte d’environ dix personnes.
Si je devais dire ce qui relie ces étapes, ce ne serait pas la techno. Elle change, et plus vite qu’on n’aime l’admettre. Le fil rouge est ailleurs : chaque rôle m’a fait voir comment on achète et vend des services IT. Et surtout, pourquoi les décisions qui paraissent techniques ne le sont souvent pas.
Phase 1 : dans un grand groupe, côté code
Quand tu es dans une grande organisation et pas dans le management, tu peux croire que certaines dynamiques ne te concernent pas. En réalité, elles te traversent quand même, vues « par reflet ». Moi j’étais dans le code, mais bosser dans un groupe de cette taille te fait voir des choses invisibles depuis l’extérieur.
Par exemple, comment on gère vraiment la relation avec les fournisseurs technologiques. Pas en théorie, pas dans le deck, mais au quotidien. J’ai vu que derrière un choix d’architecture il y a souvent un choix organisationnel, budgétaire, parfois même politique. Et j’ai vu une différence qui m’agaçait au début, puis j’ai compris qu’elle était simplement réelle : un vendor choisi pour ses compétences et un vendor choisi par inertie contractuelle ne sont pas la même chose, mais sur le papier ils paraissent identiques.
La première règle que je garde de cette phase est, peut-être un peu cynique, mais elle me semble vraie.
Le meilleur fournisseur n’est pas celui qui fait la meilleure proposition, c’est celui qui comprend comment fonctionne l’organisation du client.
Une règle difficile à mettre dans un framework. Qualitative, contextuelle. Et qui demande une compréhension des dynamiques internes qu’on n’acquiert souvent qu’en étant là, par osmose. Je me demande encore aujourd’hui combien d’appels d’offres et de sélections échouent, non parce que le prestataire est incapable, mais parce qu’il n’a pas lu le « système nerveux » du client.
Phase 2 : la startup, c’est-à-dire le coût réel des choix
Le saut vers la startup a été, sans exagérer, ce qui m’a le plus changé. Comme CTO d’une deep-tech verticale oil & gas, je me suis retrouvé à tout faire. Stack, recrutement, processus, budget, clients, livraison. Tout ensemble, souvent le même jour.
Et là tu apprends quelque chose qui reste plus diffus dans les grandes boîtes : le coût des décisions n’est pas un concept abstrait. Il est immédiat. Chaque choix a un impact direct sur le compte d’exploitation, sur le time-to-market, sur la soutenabilité de l’équipe.
Dans cette phase, j’ai appris à pricer les services IT non pas « selon le marché » mais selon la structure des coûts réels. Évidence apparente — jusqu’à ce que tu te cognes contre. J’ai appris aussi qu’un service pricé trop bas est plus dangereux qu’un trop cher : tôt ou tard quelqu’un paiera la différence. Et c’est souvent le client, en dette technique, retards, turnover, patches en panique.
Autre morceau important : les contrats. Pas ceux écrits pour gagner une négociation, mais ceux qui permettent de travailler. J’ai compris qu’il existe des contrats qui « protègent » et des contrats qui « marchent ». Les premiers sont pleins de pénalités que personne ne veut appliquer. Les seconds définissent des incitations alignées, une zone de coopération où les deux parties ont intérêt à bien faire.
La deuxième règle, ici, est devenue presque une conviction.
La qualité d’un service IT se joue avant le début du projet, dans les choix d’architecture et les processus que le prestataire met en place.
Quand le code commence à couler, beaucoup de manches sont déjà jouées. Pas toutes. Mais beaucoup.
Phase 3 : le portefeuille multi-client, où les frontières s’estompent
Aujourd’hui je travaille dans une petite ICT, environ dix personnes, comme partenaire technologique B2B. Les clients vont de grandes corporates aux administrations publiques. Mon rôle est un croisement permanent entre leadership technique, sprint planning, DevOps, compliance et architecture. Et c’est un travail « à portefeuille », donc avec des contextes très différents en cohabitation.
Dans la même période, on peut être impliqués sur un système d’information de santé régional, sur une plateforme SaaS de people analytics, sur une infrastructure IoT industrielle, sur des services de cybersécurité comme partenaire certifié d’un éditeur leader, sur des projets de compliance et sur du dev sur mesure pour le secteur public.
Cette phase est celle où les deux précédentes s’emboîtent. D’un côté, la mémoire du grand groupe : je comprends comment raisonnent les clients enterprise, ce qui les inquiète vraiment, leurs contraintes implicites. De l’autre, la sensibilité startup : je sais ce que veut dire faire de l’efficacité avec des ressources limitées, et combien comptent l’automatisation et la discipline opérationnelle.
Mais la leçon nouvelle, inattendue, est ailleurs.
Le marché des services IT est fragmenté de façon que beaucoup de frameworks d’advisory ne capturent pas.
Nous ne sommes pas un system integrator généraliste, mais pas non plus une boutique ultra-spécialisée. Nous sommes cette chose un peu inconfortable à étiqueter : un partenaire technologique agile, à compétences transverses. Et dans certains contextes, nous concourons avec des acteurs dix fois plus gros — non parce que nous sommes « meilleurs » dans l’absolu, mais parce que les processus sont plus légers et, de plus en plus, parce que l’AI-assisted development modifie le rapport entre capacité de production et taille d’équipe.
C’est peut-être là que j’ai mesuré combien la carte ne coïncide pas avec le territoire. Dans les quadrants et les rapports, certaines catégories sont nettes. Dans la vie, beaucoup moins.
Ce que ces phases m’ont appris sur le sourcing IT
Si j’essaie de traduire tout ça en implications concrètes pour le sourcing, trois idées émergent — qui sont aussi trois « défauts » récurrents dans la façon d’évaluer les prestataires.
La première vient du grand groupe : les décisions de sourcing sont souvent des décisions organisationnelles déguisées en décisions techniques. Donc qui fait de l’advisory devrait comprendre les dynamiques internes du client autant que les capabilities du prestataire. Sinon il risque de conseiller le « meilleur sur le papier » et d’obtenir le pire en pratique.
La deuxième vient de la startup : l’économie des services IT est bien plus granulaire que ce qu’en montrent les rapports de marché. La marge d’un prestataire sur un projet peut osciller énormément selon les choix d’architecture, l’automatisation, la maturité des processus. Sans lire ces dynamiques, on ne protège pas vraiment le client. Seulement formellement.
La troisième vient du portefeuille : le marché réel est plus diversifié que ce que suggèrent les frameworks. Les PME tech qui servent le tissu économique européen ne sont souvent pas dans les quadrants, et pourtant elles livrent une part importante des services IT. Ne pas connaître ce segment, c’est offrir au client un set d’options incomplet. Et parfois sans même s’en apercevoir.
La valeur cumulative, et pourquoi elle compte maintenant
Il y a un pattern dans les carrières qui produisent une valeur « non conventionnelle ». Ce n’est pas l’expérience seule qui fait la différence, c’est l’intersection.
Un analyste qui n’a fait que du conseil connaît les frameworks, mais peut n’avoir jamais vécu la livraison quand ça tourne mal. Un technicien qui n’a fait que du dev connaît le code, mais ne voit pas toujours le business. Un manager qui n’a fait que du corporate connaît les jeux politiques, mais risque de perdre le contact avec les coûts réels et avec la fatigue opérationnelle.
Le sens de ma trajectoire, s’il y en a un, est de traverser ces mondes. Et il me semble qu’aujourd’hui, cette capacité de connexion n’est plus un « plus ». Avec l’IA qui entre dans les processus, la compliance européenne qui se durcit, des modèles de pricing qui changent, le reshoring et de nouvelles attentes sur la sécurité et la souveraineté des données — la complexité ne diminue pas. Elle augmente.
Et quand la complexité augmente, les réponses simples deviennent suspectes.
L’étape suivante, avec un peu d’honnêteté
Ces derniers temps, j’ai le sentiment que l’évolution naturelle de ce parcours est d’apporter cette perspective intégrée à ceux qui doivent prendre des décisions de sourcing à fort impact.
Pas comme consultant opérationnel — ça je le fais déjà. Plutôt comme analyste de marché, chercheur, advisor stratégique. Dans un contexte où la profondeur de l’expérience opérationnelle et la capacité à produire des insights actionnables soient le cœur de la proposition.
Le type de rôle que certaines entreprises, avec beaucoup d’efforts et d’investissements, essaient d’incarner correctement.
Pas parce que j’aurais les bonnes réponses. Sur beaucoup de choses, sincèrement, je ne suis même pas sûr d’avoir une réponse unique. Mais je crois avoir les bonnes questions, celles qui viennent d’avoir vu le marché des services IT sous des angles différents. Et c’est peut-être ce qui manque le plus aujourd’hui.
Prochain dans la série : comment la tempête réglementaire européenne redessine les critères d’évaluation des prestataires IT, et pourquoi le marché de l’advisory n’est pas encore prêt.
Ce qu'il faut retenir
Du grand groupe : les décisions de sourcing sont presque toujours des décisions organisationnelles déguisées en choix techniques.
De la startup : la qualité d’un service IT se joue avant le début du projet, dans les architectures et les processus.
Du portefeuille : le marché réel est plus fragmenté que ce que les quadrants savent capturer.
Le meilleur prestataire n’est pas celui qui fait la meilleure proposition, c’est celui qui comprend comment fonctionne l’organisation du client.
Quand la complexité augmente, les réponses simples deviennent suspectes.
Questions & réponses
Pourquoi une carrière dans les services IT est-elle rarement linéaire ?
Parce que chaque étape sert une lentille différente sur le marché. On ne monte pas un escalier, on traverse des pièces : la vue interne d’une grande organisation (comment on achète vraiment de la techno), la vue startup (comment on construit du delivery depuis zéro), la vue portefeuille (comment on gouverne une multiplicité de clients et de contrats). Une carrière « linéaire » ne produit qu’une lentille — utile mais aveugle aux deux autres.
Qu'apprend-on dans un grand groupe que l'extérieur ne voit pas ?
Que les décisions qui paraissent techniques le sont rarement. On apprend la dynamique réelle de la relation aux fournisseurs — procurement, SLA, scope drift, escalade — et comment le pouvoir contractuel, plus que les features, détermine ce qui est réellement livré. Une connaissance que le développeur senior absorbe par osmose, pas par formation.
Pourquoi la phase startup ajoute-t-elle une lentille indispensable ?
Parce qu’aucun service ne « sait déjà comment faire ». Définir des processus de delivery, pricer des services, construire l’architecture depuis zéro dans un domaine peu familier, répondre au premier client sans filet — c’est la différence entre connaître un métier et pouvoir l’enseigner. C’est la phase qui apprend à distinguer processus et théâtre.
Qu'est-ce qui change quand on gère un portefeuille hétérogène ?
Tu commences à reconnaître des patterns transverses. Quand tu vois dans la même semaine un grand opérateur télécom, une multinationale RH, une région et une chambre de commerce, tu comprends que les mêmes erreurs de sourcing se répètent dans des secteurs différents avec assez de variantes pour rendre la généralisation utile. C’est la lentille qui manque à l’advisory traditionnel — il voit un secteur à la fois, pas le pattern commun.
L'auteur
