Simulateur d’intégration post-acquisition : guide complet

En bref

Le simulateur met en scène 40 ingénieurs pendant 156 semaines. Ils doivent terminer une migration et, dans le même temps, maintenir la plateforme existante. Cinq idées suffisent pour lire tout le reste.

• Une intégration peut s’emballer par une chaîne de causes : des départs réduisent la capacité de l’équipe, la migration prend du retard, l’incertitude monte, d’autres personnes partent.
• Le modèle contient trois chaînes de ce type et trois protections : une prime de rétention pour les personnes clés, un budget glissant qui finance les remplacements, et une exploitation en parallèle de l’ancien et du nouveau système.
• À l’attrition observée sur le cas de référence (3 départs hors personnes clés sur trois ans), le modèle ne produit aucune spirale, avec ou sans les protections. Le cas de référence se situait donc loin du seuil de basculement.
• Ce résultat ne prouve pas que les protections étaient inutiles. Sans protection, la moitié des simulations bascule en spirale vers trois fois l’attrition observée. Avec les trois protections, il faut environ dix fois cette attrition.
• Toutes les valeurs numériques sont synthétiques. Le modèle aide à poser les bonnes questions avant de signer une acquisition. Il ne calcule aucune prévision.

Le modèle d’un coup d’œil

Chaque flèche relie une cause à son effet. Un plus signifie que les deux grandeurs évoluent dans le même sens, un moins qu’elles évoluent en sens inverse. La carte regroupe l’avancement de la migration et son retard dans une seule boîte. Les liens en pointillé sont présents dans le modèle. Le cas de référence n’a montré aucune attrition de clients : l’exposition du revenu y est restée théorique.

Le modèle contient trois boucles de renforcement, des chaînes de causes où chaque effet alimente sa propre cause.

Les trois leviers freinent ces boucles : la prime de rétention agit sur les départs, le budget glissant sur la capacité, l’exploitation parallèle sur le revenu exposé.

Une semaine dans la simulation

Le programme avance semaine par semaine. Chaque semaine, il exécute les mêmes huit calculs dans le même ordre, puis passe à la suivante.

1. Capacité libre. Le programme additionne la productivité des ingénieurs présents, puis retire la charge d’exploitation et, si l’exploitation parallèle est active, 8 % de la capacité de départ.
2. Partage. Tant que la migration n’est pas terminée, 25 % de la capacité libre réduit la dette et 75 % fait avancer la migration. Une fois la migration terminée, toute la capacité libre réduit la dette.
3. Avancement. Le travail réalisé s’ajoute au total. Le retard est l’écart positif entre l’avancement d’un plan linéaire sur 156 semaines et l’avancement réel. Dans la version 2, chaque départ ajoute du travail de reprise au travail total.
4. Dette. Elle baisse avec l’effort de résorption et remonte avec le retard, car une équipe en retard prend des raccourcis.
5. Revenu. Tant que la migration n’est pas terminée, une part du revenu est exposée. Sans exploitation parallèle, un retard fait perdre des clients. Avec elle, 95 % de cette perte est évitée.
6. Incertitude. Elle se rapproche chaque semaine d’une cible qui additionne l’inquiétude due à l’annonce (elle s’estompe avec le temps), le retard, la pression sur le revenu et les départs des douze dernières semaines.
7. Départs. Chaque ingénieur tire au sort son départ. La probabilité dépend du taux de base, de l’incertitude et de la sensibilité personnelle. La prime de rétention divise par près de sept celle des personnes clés pendant 104 semaines. Dans la version 2, un freelance ne peut partir qu’à la fin de son contrat.
8. Arrivées. Avec le budget glissant, une personne partie est remplacée avec trois chances sur dix chaque semaine, tant que l’effectif est sous 40. La recrue atteint sa pleine productivité en 16 semaines.

Une simulation répète ce cycle 156 fois. Le programme en lance ensuite d’autres, avec des tirages au sort différents, pour voir la dispersion des résultats.

Calibrer : ancrer le modèle sur le cas observé

Calibrer, c’est régler un paramètre du modèle jusqu’à ce qu’il reproduise un fait observé. Le fait retenu est l’attrition du cas de référence : environ 3 départs hors personnes clés sur les trois ans, dans une équipe d’une quarantaine de personnes. Cet énoncé admettait deux lectures. La lecture A compte 3 départs au total sur trois ans. La lecture B compte 3 départs par an, soit 9 au total. La personne qui a conduit le cas a confirmé la lecture A, qui est celle retenue partout dans ce guide.

La méthode est une recherche par dichotomie. Un facteur multiplie ensemble la probabilité de départ de base et la réaction à l’incertitude, en conservant leur rapport. Le programme lance 50 à 60 simulations avec un facteur donné, compte les départs hors personnes clés, puis resserre le facteur jusqu’à obtenir une moyenne de 3. On obtient les valeurs suivantes.

Deux limites méritent d’être connues avant de continuer. D’abord, le modèle a un seul réglage et une seule observation : l’accord entre les deux est acquis par construction, il ne teste rien. Ensuite, le partage entre le taux de base et la réaction à l’incertitude est une hypothèse, que la calibration ne peut pas trancher.

Comment lire ces résultats

Trois lectures sont légitimes. Trois autres semblent naturelles et ne le sont pas.

Ce que les résultats permettent d’affirmer.

• Le mécanisme de spirale existe dans le modèle : il apparaît dès que l’attrition dépasse un seuil, et les leviers repoussent ce seuil.
• Chaque levier agit à un endroit distinct. L’exploitation parallèle protège le revenu, le budget glissant protège l’effectif, la prime de rétention protège les personnes clés.
• Le cas de référence, avec 3 départs sur trois ans, se situe loin du seuil.

Ce que les résultats ne permettent pas d’affirmer.

• Que les protections étaient inutiles. Loin du seuil, elles ne changent rien à la stabilité. Elles gardent leur valeur d’assurance contre une attrition plus forte.
• Qu’une équipe de freelances distribuée est plus robuste. Ce résultat découle de deux hypothèses : un départ possible seulement à l’échéance du contrat, et une contagion des départs réduite de moitié par la distance.
• Que le modèle prédit une intégration future. Il compare des scénarios sur des valeurs synthétiques, il ne calcule aucune probabilité réelle.

Un dernier point de méthode : le cas de référence est un succès. Un modèle calibré sur un seul succès peut afficher la bonne issue sans que ses mécanismes soient exacts. Un cas d’intégration échouée, même anonymisé, apporterait l’information qui manque : il permettrait de tester le modèle de l’autre côté du seuil.

Utiliser le code

Le code est écrit en Python avec la bibliothèque Mesa, conçue pour les simulations à agents. Il a été exécuté avec Python 3.13 et Mesa 3.5.1. Les fichiers se placent dans un même dossier, car certains en importent d’autres.

Code source et résultats : dépôt thierrysays/integration-attrition-simulator ou archive integration-attrition-simulator-v1.1.zip (450 Ko, scripts Python, résultats, figures, notice en français et en anglais). Code sous licence Apache 2.0 ; résultats, figures et notice sous licence Creative Commons Attribution 4.0.

Installation

pip install mesa==3.5.1 matplotlib

Les fichiers

Les commandes

python3 run_scenarios.py
python3 calibrer_attrition.py
python3 run_v2.py

Chaque commande affiche ses tableaux à l’écran et écrit ses fichiers de résultats dans le dossier. La durée n’a pas été mesurée avec précision : il faut compter quelques minutes pour les calibrages, qui lancent plusieurs centaines de simulations.

Modifier une valeur et relancer

Toutes les valeurs du modèle sont des champs d’une classe Params. Un exemple qui reconstruit l’équipe de freelances distribués de la version 2, avec l’attrition calibrée, puis lance une simulation sans prime de rétention :

from dataclasses import replace
from pmi_model_v2 import IntegrationModel, Params

s = 0.1623  # facteur de calibrage, freelances distribués
p = replace(
    Params(),
    freelance_share=0.65, coordination_penalty=0.10,
    onboarding_weeks=24, w_dep=1.5,
    base_quit=0.002 * s, quit_gain=0.012 * s,
    retention_bonus=False,
)
resultat = IntegrationModel(p, seed=1).run().summary()
print(resultat)

Le paramètre seed fixe les tirages au sort : la même valeur redonne exactement le même résultat. Les scripts utilisent les valeurs 1000 et suivantes pour les scénarios, 5000 et suivantes pour le calibrage.

Lire les colonnes de résultats

Questions ouvertes et suite

Quatre informations restent à recueillir. Chacune règle une hypothèse du tableau des limites.

• Quel préavis et quelle durée de contrat avaient les freelances ?
• La migration a-t-elle respecté le calendrier de trois ans ? La réponse fixe l’effort perdu en coordination.
• Quelle part des contrats freelances avait une échéance commune ?
• Existe-t-il un cas d’intégration échoué, même anonymisé, pour tester le modèle de l’autre côté du seuil ?

Les étapes suivantes, dans l’ordre :

1. Remplacer la contrainte d’échéance des freelances par un départ possible à tout moment après préavis, puis relancer la courbe de basculement.
2. Définir la spirale par l’accélération des départs plutôt que par le niveau final de l’effectif.
3. Tester un second cas d’intégration sans réajuster les paramètres, puis confronter le modèle à un cas échoué.
4. Soumettre la carte causale et les hypothèses à deux personnes qui ont vécu une intégration.
5. Constituer un jeu de cas anonymisés : c’est l’actif durable du projet, bien plus que le code.

Les valeurs de ce guide sont synthétiques et le cas de référence est anonymisé. Pour échanger sur le modèle ou soumettre un cas d’intégration anonymisé, écrire à thierry@glossolalie.pro · linkedin.com/in/thierrys.