Comment réussir l’externalisation de sa production dans un contexte fortement dégradé ? Ce retour d’expérience est basé sur un cas réel. L’entreprise concernée n’a pas souhaité que son nom soit révélé.
Le contexte : une forte dégradation
Un groupe de grande distribution a un système d’information basé sur un ERP, pour la gestion des entrepôts et des magasins, et sur des outils classiques, pour le back office (paie, comptabilité, SIRH, dématérialisation des factures…). Historiquement, la salle machine était gérée en interne par l’équipe en place.
Un nouveau DSI est nommé et il engage une opération d’externalisation de sa production, suite à un triple constat : d’abord, beaucoup de projets mis en œuvre n’avançaient pas comme prévu. En outre, les projets structurants pour l’entreprise n’étaient pas lancés.
Ensuite, les chefs de projets avaient également la responsabilité de la production. Conséquence : lorsque la production informatique dysfonctionne, cela prend le pas sur les projets qui, de fait, se trouvent ralentis dans leur exécution. Enfin, la production n’était pas structurée par une approche industrielle, ni dans une logique de pérennité.
Le soutien de la direction générale est évidemment crucial dans ce type d’opération. Objectifs de l’externalisation : redonner confiance aux utilisateurs, étendre les couvertures fonctionnelles et repositionner les projets structurants dans la stratégie d’entreprise.
Une situation à risques
Dans un tel contexte, il y a d’abord un risque de dérive complète de la production, qui n’était pas sous contrôle. Avec des dysfonctionnements récurrents et des temps de réaction trop longs, par exemple en cas d’attaques virales. Par ailleurs, le fait que tout le monde, à la DSI, puisse se connecter sur le système d’information entraîne un manque de visibilité et de reporting sur le travail des équipes de production. Autrement dit, la production était sous le contrôle de collaborateurs que le DSI ne contrôlait pas, tout en étant tenu responsable des incidents.
L’un des risques les plus visibles est la panne de messagerie, outil névralgique pour l’entreprise, surtout lorsque l’on travaille dans plusieurs pays et avec de nombreux collaborateurs mobiles. « Si elle n’est plus disponible, pendant le premier quart d’heure, les utilisateurs s’en amusent ; au bout d’une demi-heure, ils sortent de leur bureau, et au-delà d’une heure d’indisponibilité, ils sont tous dans mon bureau », explique le DSI.
Autre exemple de risque : le réassort des magasins, qui doit parvenir aux entrepôts. Auparavant, il était réalisé vers neuf ou dix heures du matin, parce que le système « plantait » en amont, alors que les entrepôts commencent à travailler à sept heures ! Les dérives précédentes avaient pour origine le fait que les investissements nécessaires n’avaient pas été engagés et que l’entreprise a grossi trop vite.
Les premières décisions
La première décision du DSI a été d’arrêter tous les projets, afin d’identifier quels étaient les vrais besoins. Seconde décision : séparer la production des études, en restructurant l’équipe. Une fois que cette opération a été menée à bien, l’objectif était d’externaliser la production pour la mettre sous contrôle et en sécurité.
Le DSI fait appel à un cabinet de conseil pour poser les bons jalons qui conduisent à l’externalisation. Cet accompagnement est important dans la mesure il n’existait aucun document d’exploitation, ni procédures. En outre, le support utilisateur étant assuré en interne, par les équipes de la DSI, il n’était pas optimisé. Ainsi, il existait un backlog important, d’où une insatisfaction des utilisateurs.
Externaliser la production : les bonnes pratiques
D’abord, il faut décrire les processus qui n’avaient jamais été écrits, ne serait-ce que le planning de production, afin de constituer un vrai dossier d’exploitation. On décrit ce que l’on a pour répondre à la question fondamentale : que veut-on externaliser ? Cela suppose de décrire la cible opérationnelle, avec toutes les définitions des besoins, à travers des SLR (Service Level Requirements), par exemple pour la logistique, pour la comptabilité… de manière à formuler les niveaux de services pour chaque objectif. On passe ainsi d’une approche de type « quel est mon système ? » à une approche de type « que veut-on en faire ? ».
Cette activité de description est, certes, un travail laborieux, mais enrichissant, car elle oblige à se poser les bonnes questions et à définir les responsabilités de chacun : celles de l’entreprise, de l’hébergeur, et des tiers tels que les éditeurs et les mainteneurs. « Auparavant, le manque de clarté aboutissait à une situation dans laquelle personne n’était responsable de rien », résume le DSI.
Le principe essentiel est de ne jamais accepter de rentrer dans une logique d’obligation de moyens, de la part des prestataires, mais de toujours rester dans une logique d’obligation de résultats. Les prestataires tentent en permanence d’imposer à leurs clients une obligation de moyens. Par exemple, lorsqu’un prestataire prend en charge le support des utilisateurs, la facturation est basée sur le volume d’appels.
Il est préférable de payer non pas en fonction du nombre d’appels, mais du nombre d’utilisateurs, donnée plus facile à contrôler. En parallèle, les prestataires doivent s’engager à améliorer la qualité de service, afin de faire diminuer le nombre d’appels pour être dans une norme acceptable, par exemple moins d’un appel par mois et par utilisateur, à charge pour le prestataire de s’adapter.
Imposer de telles conditions à un prestataire n’est jamais facile dans la mesure où ceux-ci avancent toutes les bonnes raisons pour expliquer qu’ils ne peuvent pas faire ce qui est demandé. Ils font donc pression pour modifier les contrats dans leur intérêt. En outre, confie le DSI, « il faut éviter de tomber dans le travers qui consiste à privilégier les matériels sur les applications. Si nous avons externalisé, c’est précisément pour que le prestataire rende un service, en termes d’applications, et que l’on puisse calculer le coût analytique par application (logistique, comptabilité, dématérialisation…) », précise le DSI.
C’est donc la responsabilité du prestataire de proposer des unités d’œuvre de gestion et de support qui permettent de calculer ces coûts. « L’unité d’œuvre, c’est l’application, pas la machine. Je sais que si je retire une application, j’économie x euros. Je peux ainsi comparer une application avec une autre et offrir à l’entreprise un coût analytique du système d’information. Ce n’est évidemment pas dans l’intérêt des prestataires », poursuit le DSI.
Pour résister à la pression des prestataires, il est pertinent d’aller jusqu’au bout de l’appel d’offres en ayant toujours deux challengers. Chacun procède à une due diligence et le DSI rédige un contrat avec chacun d’entre eux, comme s’ils avaient remporté l’appel d’offres ! Pendant la phase de « due diligence » les équipes respectives des prestataires se croisent dans les locaux. « De fait, chacun a aussi l’impression d’avoir perdu, explique le DSI. Pour conserver la maîtrise du contrat, je suis transparent avec les prestataires et leur dit que chacun des deux restant en short list peut gagner. Cette stratégie m’a permis de négocier de meilleures conditions. Et, surtout, d’être certain que les prestataires ne me rajoutent pas leurs propres clauses, ils sont quand même spécialistes de cette pratique. Les prestataires signent donc mon contrat… et n’aiment pas ça du tout ! »
Ce n’est effectivement pas habituel car, en général, les DSI ne proposent pas leur propre contrat et s’en remettent à ceux des fournisseurs. « Pourquoi certains d’entre eux proposent-ils des contrats très épais ? Parce qu’ils sont les seuls à les comprendre : pourquoi faudrait-il signer ce genre de document ? Et-ce que vous vous mariez avec quelqu’un dont vous ne comprenez rien à ce qu’il vous dit ? Non… Nous appliquons ce même principe, même si c’est plus difficile pour acquérir un logiciel très précis ou contracter avec des fournisseurs en situation de quasi-monopole », souligne le DSI.
L’un des points cruciaux concerne la réversibilité : « Sur ce plan, les prestataires ligotent les entreprises », assure le DSI. Si les mécanismes et conditions de la réversibilité ne sont pas clarifiés, avec un prix identifié au départ, l’entreprise est en situation de risque. « Nous avons un prix connu à l’avance et le prestataire a une obligation de résultats, sinon, il paie des pénalités. Si vous ne demandez rien, vous n’avez aucune chance de l’obtenir », résume le DSI.
« Il faut savoir jusqu’où aller, sachant que les prestataires ne vendront jamais à perte, par définition, et qu’on ne connaît pas leurs coûts. Tant que le prestataire ne refuse pas une proposition c’est qu’il a une marge de manœuvre. » Mais la relation humaine reste fondamentale : avant le choix d’un prestataire, il importe d’être certain que ses équipes sont capables de travailler avec celles de la DSI.
Une autre règle a été appliquée par cette entreprise : la signature du contrat doit intervenir impérativement avant le démarrage. « Je préfère décaler si le contrat n’est pas signé. Sinon, les équipes du prestataire commencent à travailler, celui-ci en profite pour renégocier et vous n’avez pas le choix. Il n’acceptera jamais vos clauses.
En outre, en phase de démarrage, on a franchement autre chose à faire que de regarder les détails d’un contrat. Et, intellectuellement, si on ne l’a pas fait avant, on ne le fera jamais bien. Un contrat est fait pour se projeter, pour concevoir l’ensemble des évolutions possibles. Vous ne le faites pas après le démarrage du projet. Personne n’a fait son testament après sa mort ! »
Travailler en mode « homard » ou en mode « singe »
« Les DSI doivent être plus proactifs que réactifs. Autrement dit, agir comme un singe plutôt que comme un homard. Tous les animaux qui ont une structure défensive à l’extérieur sont là pour recevoir des coups. Si le coup est trop dur, la carapace rompt et… tant pis ! Il n’y a aucune agilité. Plongez un homard dans l’eau bouillante, il ne fera rien, il attendra… Le singe, lui, est très vulnérable par son enveloppe corporelle, mais il a l’intelligence de pouvoir réagir rapidement à des situations inattendues. Il n’est pas réactif, il est proactif, il est souple et anticipe. Un DSI ne doit plus travailler en « mode homard », mais en « mode singe » ».