--- type: "use_case" title: "Comment Shine et Cegid construisent leur stack suite à un build-up réussi ?" locale: "fr" client: "Shine" interviewee: "Yanis Boukhrissi" interviewee_role: "Revenue Operations, périmètre exact à confirmer" interview_date: "[à confirmer]" publication_date: "[à confirmer]" canonical: "https://www.softatlas.io/fr/use-case/shine-cegid-stack-revenue" updated_at: "2026-10-14T06:52:03.713Z" --- # Comment Shine et Cegid construisent leur stack suite à un build-up réussi ? Cet article a été rédigé par Atlas à la suite d’une interview avec Yanis Boukhrissi, Global Revenue Operations Director chez Shine/Cegid , menée le 21 Septembre 2026. Il documente la rationalisation de la stack Revenue, data et web d’un groupe constitué par acquisitions successives. Le groupe Shine regroupe aujourd’hui environ **2 500 collaborateurs et génère 450 millions d’euros d’ARR répartis entre 12 et 15 marques**, avec presque autant de stacks historiques. Cette diversité vient d’une succession de rapprochements et d’acquisitions. **Shine** avait précédemment rejoint Ageras, qui regroupait plusieurs entreprises et autant de stacks différentes, avant le rapprochement avec Cegid. Le périmètre comprend aujourd’hui des marques et produits comme **EBP, Sevdesk, Billy, Employes, Salary, Storebuddy, Contasimple, Vendus, Quadra ou Loop.** Pour l’équipe Revenue Operations, le chantier est conséquent : accompagner les différentes business units sur leurs outils existants tout en faisant progressivement converger CRM, sites web, outils de lifecycle, solutions de téléphonie, CPQ et systèmes de facturation. > « Petit à petit, mon équipe va à la fois aider individuellement toutes ces business units sur leur stack existante et [...] uniformiser les websites, les stacks Revenue, les CRM, les outils de lifecycle, les CPQ, etc. » > > Yanis Boukhrissi, Global Revenue Operations Director @Shine L’enjeu n’est cependant pas de remplacer mécaniquement dix outils par un seul. Le groupe adresse des clients et des motions commerciales très différents. La stack cible doit donc trouver un équilibre entre standardisation et spécialisation. ## Comment les Revenue Operations sont-ils organisés chez Shine et Cegid ? L’organisation décrite par Yanis repose sur trois piliers. - Le premier est celui des **systèmes et de l’automation**. L’équipe connecte la donnée, construit les environnements HubSpot, met en place les automatisations avec n8n et accompagne les équipes Revenue, Sales et Customer Success dans leur utilisation quotidienne des outils. Cette équipe travaille également avec les événements générés dans les produits. Un clic ou un événement de lifecycle peut, par exemple, déclencher un workflow HubSpot, prévenir un commercial ou alimenter un scénario de prévention du churn. - Le deuxième pilier correspond au **Sales Ops** : définition des territoires, compensation plans, forecast du pipeline et suivi de la performance commerciale. Il comprend également des sujets de Risk & Compliance et de Sales Enablement. - Enfin, le troisième pilier est le **Web**, un périmètre moins courant dans une organisation Revenue Operations. L’équipe rassemble des développeurs et des chefs de projet web, mais couvre aussi le CRO, le tracking et l’analytics. Cette organisation permet aux Revenue Operations de garder la main sur une grande partie du funnel, ce qui est particulièrement important pour les activités **Product-Led Growth** où le site constitue directement la porte d’entrée du business. Les équipes Marketing restent, elles, principalement organisées dans les pays et les business units. ## Pourquoi la stack doit-elle gérer à la fois du Product-Led Growth et des ventes complexes ? La difficulté de la rationalisation vient notamment de la coexistence de trois motions commerciales. - Le **Product-Led Growth** concerne principalement les micro-entreprises et les entrepreneurs. Une grande partie du parcours est réalisée en self-service. Les commerciaux peuvent néanmoins intervenir sur certains moments précis, par exemple lorsqu’un prospect abandonne un parcours de création de compte bancaire particulièrement long. - Le **Small Business** est davantage sales-led et adresse des entreprises allant jusqu’à environ 50 salariés, avec des tickets plus élevés. - Enfin, le segment des **experts-comptables** se rapproche davantage d’une logique mid-market ou enterprise, avec des cycles de vente pouvant atteindre six mois. Cette diversité explique pourquoi la cible n’est pas nécessairement d’avoir un logiciel unique par catégorie. Un outil très efficace sur un parcours PLG peut être moins adapté à un catalogue complexe ou à une vente accompagnée par plusieurs commerciaux. La rationalisation consiste donc autant à supprimer le legacy qu’à identifier les différences d’outillage qui correspondent réellement à des différences de métier. ## Comment Snowflake et Hightouch alimentent-ils la stack Revenue ? La data de l’entreprise repose sur Snowflake, mais les Revenue Operations n’interviennent volontairement pas directement dans le data warehouse. L’équipe Data leur met à disposition un miroir des tables nécessaires (reverse ETL). Cela permet aux équipes Revenue d’exploiter la donnée sans intervenir sur l’infrastructure centrale. C’est à partir de Hightouch que l’équipe de Yanis commence réellement à manipuler les données. Le reverse ETL permet d’aller chercher les informations disponibles dans Snowflake et de les envoyer vers les outils opérationnels, notamment HubSpot. L’équipe avait auparavant travaillé avec Segment, depuis racheté par Twilio. Sans avoir lui-même utilisé Hightouch en profondeur, Yanis rapporte un retour positif de son équipe. > « On arrive à faire ce qu’on veut. On arrive à avoir de la data fraîche, pas trop chère en termes de refresh de données. Donc ça marche plutôt bien. » > > Yanis Boukhrissi, Global Revenue Operations Director @Shine Databricks a également été utilisé auparavant côté Cegid. Yanis souligne surtout son coût, tout en précisant que son équipe intervenait peu directement dans l’outil. La philosophie de l’architecture est donc claire : laisser l’infrastructure data à l’équipe spécialisée, puis exposer aux Revenue Operations une couche suffisamment simple pour qu’ils puissent construire leurs workflows. ## Pourquoi HubSpot devient-il le CRM central de Shine et Cegid ? Après Hightouch, la donnée arrive dans ce qui doit devenir le centre de la stack Revenue : HubSpot. Le choix est assumé. Yanis a travaillé sur plusieurs CRM et exprime une préférence nette pour HubSpot. > « J’ai bossé sur à peu près tous les CRM et je pense que HubSpot est mon favori. » > > Yanis Boukhrissi, Global Revenue Operations Director @Shine La cible consiste à construire une instance HubSpot suffisamment importante pour supporter plusieurs pays, business units et motions commerciales. Cette convergence est encore en cours. Salesforce reste notamment utilisé sur une partie de Cegid Small Business et sur le périmètre experts-comptables. EBP utilise déjà HubSpot, avec environ **100 utilisateurs**. Les migrations ne présentent pas toutes la même difficulté. Sur le Product-Led Growth, relativement peu de commerciaux utilisent directement le CRM. La migration porte donc principalement sur les pipelines et les connexions avec les bases de données afin de conserver une donnée fraîche. Le chantier devient beaucoup plus lourd avec Cegid et EBP, qui représentent ensemble près de **250 commerciaux** à prendre en compte dans les migrations. L’équipe maîtrise techniquement ce type de projet, mais ne dispose pas de suffisamment de ressources internes pour absorber seule la charge. Elle prévoit donc de s’appuyer sur **KANÔ**, une agence RevOps fondée par des anciens de PayFit que Yanis connaissait déjà et sur laquelle il avait reçu de bons retours. La consolidation du CRM illustre ainsi une logique récurrente dans la transformation : le problème n’est pas uniquement de sélectionner un logiciel, mais d’absorber la complexité organisationnelle de la migration. ## Comment HubSpot et Braze se répartissent-ils le CRM et le lifecycle ? HubSpot n’a pas vocation à couvrir tous les usages. Pour les communications liées directement au comportement dans le produit, l’équipe utilise Braze. L’outil permet notamment de déclencher des communications à partir d’événements : une action donnée dans le produit peut entraîner l’envoi d’un message spécifique. L’équipe utilise surtout l’in-app et les communications trigger-based. L’email est déjà utilisé et WhatsApp est également en cours de lancement. Yanis apprécie notamment la relative simplicité du setup, avec un SDK connecté au produit. La répartition avec HubSpot suit les motions commerciales. Pour les activités sales-led, les field marketers, les événements ou les webinars, **HubSpot** reste l’outil naturel. Sur le Product-Led Growth, **Braze** prend davantage le relais. Cette séparation répond aussi à un enjeu économique. HubSpot étant notamment facturé en fonction du nombre de contacts marketing adressables, déplacer une grande partie des contacts PLG vers Braze permet, selon Yanis, de faire fortement baisser la facture HubSpot. Techniquement, Braze est relié à HubSpot, Hightouch et directement au produit. Les événements produit peuvent ainsi alimenter les scénarios sans nécessairement transiter par un seul système. ## Pourquoi Aircall et Genesys sont-ils complémentaires pour la téléphonie ? La téléphonie montre bien pourquoi la rationalisation ne conduit pas nécessairement à sélectionner un seul outil. - Chez Shine, Aircall est utilisé pour le calling, avec des retours plutôt positifs, notamment sur les appels sortants. - EBP utilise également Genesys, qui pourrait rester dans la stack cible pour l’appel entrant. Le groupe gère en effet des volumes importants d’appels entrants. Selon les retours reçus par Yanis, Genesys est plus robuste sur ce type d’usage et permet notamment de faire remonter rapidement la fiche du contact. Aircall semble à l’inverse mieux adapté au sortant. La décision de tout migrer vers une solution unique n’est donc pas prise. Les usages sont suffisamment différents pour que la coexistence puisse avoir du sens. Une logique similaire existe sur le support. Intercom est notamment utilisé chez Shine, tandis que Zendesk reste présent dans certaines entités. Ici aussi, le chantier consiste à distinguer ce qui relève d’un besoin réel de ce qui n’est que de la fragmentation historique. ## Pourquoi l’enrichissement et l’intent data sont-ils moins importants dans cette stack ? Contrairement à de nombreuses organisations B2B, l’enrichissement n’est pas un chantier central. Sur le PLG, les entreprises sont souvent trop petites pour être facilement enrichies. Sur le Small Business, les volumes sont importants et concernent notamment des verticales comme les garages automobiles ou la construction, où les entreprises peuvent être difficiles à identifier dans les bases classiques. Le cas des experts-comptables est encore différent : Yanis estime leur nombre à environ **12 000 en France** et considère que le groupe connaît déjà suffisamment bien ce marché pour avoir moins besoin d’outils d’enrichissement. L’intent data n’a donc pas encore fait l’objet d’un chantier important, même si Yanis estime que le sujet pourrait devenir pertinent sur le segment des experts-comptables. ## Pourquoi Shine et Cegid évaluent-ils DealHub pour remplacer Salesforce CPQ ? Le **CPQ** devient particulièrement important dès que l’on quitte les parcours Product-Led Growth. Une partie du groupe utilise encore Salesforce CPQ. Yanis reconnaît que le produit fonctionne correctement, mais souligne une limite classique de l’écosystème Salesforce : sa maintenance nécessite beaucoup de technicité et de ressources. > « Salesforce CPQ marche, sincèrement, même plutôt bien. C’est juste que, comme tout avec Salesforce, ça demande une technicité et un nombre de personnes assez fous pour le maintenir. » > > Yanis Boukhrissi, Global Revenue Operations Director @Shine Cette complexité contribue à la volonté de sortir progressivement de Salesforce. HubSpot est considéré comme plus accessible, mais ses fonctionnalités CPQ ne sont pas jugées suffisamment robustes pour les besoins actuels. L’équipe discute donc avec DealHub. L’intégration native avec HubSpot et les deal rooms intéressent l’équipe, mais un autre cas d’usage pourrait être encore plus structurant. EBP travaille avec **plus de 500 revendeurs**. Leur attribuer à tous une licence CPQ serait difficilement envisageable. DealHub propose une API qui pourrait permettre de mettre à leur disposition un CPQ sans devoir payer une licence individuelle pour chacun. L’objectif serait aussi d’homogénéiser la manière dont les revendeurs construisent leurs propositions et d’éviter des factures trop hétérogènes. DealHub n’est toutefois pas encore utilisé. Le produit reste en phase d’évaluation. Yanis souligne également un pricing élevé, tout en estimant qu’une négociation significative semble possible. ## Pourquoi Chargebee et Zuora pourraient-ils continuer à coexister ? La facturation et la gestion des subscriptions reflètent elles aussi les différences entre PLG et sales-led. Chargebee est utilisé chez Shine, principalement dans un environnement Product-Led Growth. Zuora est utilisé sur des activités davantage sales-led, notamment chez EBP et Cegid. Yanis ne pense pas nécessairement qu’une solution unique s’imposera. Chargebee lui semble plus léger lorsque les catalogues deviennent complexes, alors que certaines activités sales-led du groupe disposent de catalogues particulièrement difficiles à administrer. La complexité est telle que certaines personnes travaillent spécifiquement à la gestion de ces catalogues. L’objectif reste néanmoins de simplifier cette organisation. D’autres solutions existent encore dans certaines entités, notamment Frisbii en Allemagne et Moneybird. Elles illustrent l’ampleur du travail de rationalisation restant à mener. ## Comment Affilae est-il utilisé pour gérer les partenariats ? La stack comprend également Affilae, utilisé pour les partenariats et l’affiliation. Yanis s’est lui-même intéressé au sujet en cherchant à comprendre le niveau de dépense associé à l’outil. Les partenariats les plus stratégiques sont gérés directement en one-to-one. Affilae semble plutôt répondre au besoin de gérer à plus grande échelle de nombreux petits partenariats avec d’autres marques, notamment pour l’envoi de leads ou de business. L’outil s’inscrit donc moins dans une logique d’influence que dans une infrastructure permettant d’industrialiser une partie des partenariats. ## Comment GA4 (Google Analytics), AppsFlyer et Mixpanel se répartissent-ils l’analytics ? L’analytics repose sur plusieurs outils qui observent des étapes différentes du parcours utilisateur. Google Analytics (GA4) reste principalement utilisé pour analyser le site internet. Mixpanel est davantage tourné vers le produit. Il permet d’analyser les événements et comportements une fois que l’utilisateur est dans l’application. Yanis le décrit simplement comme l’équivalent d’un GA pour le produit, avec également des possibilités d’A/B testing et de session replay. AppsFlyer couvre une problématique différente : l’attribution mobile. Tous les produits étant disponibles sous forme d’applications, certains utilisateurs ne passent jamais par le site avant de télécharger l’app. AppsFlyer permet alors de comprendre d’où viennent ces conversions et de mieux suivre les parcours entre web et mobile. > « **AppsFlyer** nous permet de boucler la boucle. » > > Yanis Boukhrissi, Global Revenue Operations Director @Shine L’équipe vient de revoir son contrat AppsFlyer et se dit satisfaite de l’outil pour son usage actuel. Yanis le juge notamment plus adapté que GA4 à l’attribution croisée mobile-web, web-to-app ou mobile-to-app. Braze utilise de son côté les mêmes types d’événements produit, mais dans une finalité différente. Là où Mixpanel les lit pour analyser les comportements, Braze les utilise pour déclencher des actions. Cette distinction évite de chercher artificiellement un outil unique : la même donnée alimente plusieurs logiciels spécialisés selon le besoin. ## AB Tasty, Convert ou Webyn : quel outil d’A/B testing choisir ? L’A/B testing fait encore partie des catégories en cours de rationalisation. Cegid utilisait AB Tasty, tandis que Shine utilise Convert. Les deux solutions présentent des compromis différents. Yanis considère AB Tasty comme relativement coûteux et un peu léger pour certains besoins. Convert fonctionne, mais reste selon lui complexe à gérer. L’équipe benchmarke donc plusieurs solutions. Parmi les alternatives évoquées figure Webyn, identifié par le responsable Web de Yanis. L’outil semble notamment permettre de créer de nombreuses variations, tests et flows. Ce choix prend une importance particulière dans le contexte actuel. La convergence des marques implique de repenser la navigation des sites : faut-il une double, triple ou quadruple navigation ? Comment exposer plusieurs produits sans rendre l’expérience trop complexe ? Les équipes Revenue Operations travaillent sur ces questions avec les équipes Brand et Design. L’A/B testing doit permettre de confronter les différentes options aux comportements réels des utilisateurs. ## Pourquoi Shine utilise-t-il Prismic et Strapi, tandis qu’EBP utilise WordPress ? Le patrimoine web reflète directement l’histoire des acquisitions. Deux sites sont aujourd’hui particulièrement importants. - **Shine France utilise **Prismic**.** Le site restera pour l’instant spécifique à la France et doit progressivement accueillir les différents segments et produits destinés au marché français. - **Shine.co utilise **Strapi pour tous les autres pays. Yanis ne porte pas de jugement définitif sur Prismic. Il souligne surtout que l’environnement est très custom, en partie parce que le site est ancien et a historiquement été développé de manière spécifique. Cela réduit la capacité à donner facilement la main aux équipes non techniques. Strapi offre davantage de flexibilité sur les templates. L’équipe centrale peut créer la navigation, les widgets et les templates avec l’équipe Brand, puis laisser davantage d’autonomie aux Product Marketing Managers et Content Managers locaux. Les pays peuvent ainsi prendre la main sur les landing pages nécessaires à leurs campagnes, mais également sur certaines pages de blog ou pages produit à partir de templates prédéfinis. Les sites legacy suivent encore une autre logique. Une partie importante a été déplacée vers WordPress, notamment parce que l’outil est simple à construire et qu’il est beaucoup plus facile de trouver des freelances capables d’intervenir dessus. L’équipe externalise une partie de ces sites et privilégie donc une technologie très largement maîtrisée sur le marché. **EBP.com** fait notamment partie de ces environnements. Enfin, **sevdesk** utilise Webflow. À court terme, la stratégie Web ne consiste donc pas à imposer un CMS unique, mais à faire converger progressivement les sites tout en tenant compte du coût de maintenance, de l’autonomie des pays et de la disponibilité des ressources techniques. ## Comment Claude Enterprise aide-t-il les migrations CRM ? L’utilisation de l’IA ne se limite pas aux interfaces clients. Les équipes disposent d’un plan Claude Enterprise avec des allocations mensuelles et des restrictions sur les applications auxquelles l’IA peut se connecter. Claude est notamment utilisé avec les MCP de n8n et HubSpot. L’un des principaux cas d’usage concerne la qualité des données : nettoyage, déduplication et préparation des migrations. > « Claude nous fait gagner un temps de malade en termes de déduplication et de cleaning de données. Pour les migrations aussi, ça va beaucoup nous aider. » > > Yanis Boukhrissi, Global Revenue Operations Director @Shine Dans une organisation qui doit faire converger de nombreux CRM et bases historiques, cet usage est directement lié au chantier de rationalisation. L’adoption s’est faite de manière assez organique. Les équipes se sont principalement formées elles-mêmes et partagent entre elles des skills, notamment ceux qu’elles trouvent sur GitHub. ## Pourquoi Modjo est-il apprécié mais sous-utilisé ? Modjo est utilisé pour enregistrer et analyser les appels commerciaux. Le jugement de Yanis sur l’outil est particulièrement intéressant parce qu’il distingue la qualité du logiciel de son niveau réel d’adoption. La récupération de données à partir des conversations est bien utilisée. Le potentiel de coaching, en revanche, est plus difficile à exploiter pleinement. Même lorsqu’une entreprise dispose d’une équipe Sales Enablement, il faut que les managers et les commerciaux trouvent suffisamment de temps pour revenir sur les appels et utiliser réellement les fonctionnalités proposées. Pour Yanis, la limite n’est donc pas tant le produit que la bande passante qu’il demande aux utilisateurs. > « Modjo est un super outil. Ça demande juste plus de bande passante côté utilisateurs que ce qui est vendu, je pense. » > > Yanis Boukhrissi, Global Revenue Operations Director @Shine C’est un enseignement plus général sur la stack Revenue : la valeur théorique d’un outil avancé ne se transforme pas automatiquement en usage réel. ## Comment Linear et Teamtailor complètent-ils la stack ? Pour le ticketing interne et les roadmaps Web et Produit, les équipes utilisent Linear. Yanis avait initialement le sentiment que l’outil pouvait être surdimensionné par rapport à des solutions comme Asana ou Monday. Son avis a évolué avec l’usage : dès lors qu’une organisation gère beaucoup de développement, Linear lui paraît pertinent pour structurer tickets, roadmaps et demandes internes. Slack est utilisé pour la communication interne. Côté recrutement, Yanis utilise actuellement Teamtailor, dont il juge l’expérience agréable. La rationalisation des outils RH reste cependant moins avancée que celle de la stack Revenue. Plusieurs outils coexistent encore selon les équipes, notamment pour la gestion des congés. Hi**Bob** est évoqué dans cet environnement, mais Yanis ne sait pas encore vers quelle cible l’organisation RH se dirigera. ## Quelle architecture cible se dessine pour la stack Revenue ? La transformation en cours ne semble pas conduire vers une suite unique capable de remplacer tous les logiciels du groupe. Elle dessine plutôt une architecture organisée autour d’un **socle central**, complété par des outils spécialisés lorsque les différences d’usage le justifient. Snowflake centralise la donnée. Hightouch permet aux Revenue Operations de l’exploiter sans intervenir directement dans le data warehouse. HubSpot devient progressivement le CRM central pour les activités Sales et Customer Success. **Braze** prend en charge une grande partie du lifecycle Product-Led Growth. Autour de ce noyau, certains outils conservent un rôle spécifique : **AppsFlyer** pour l’attribution mobile, **Mixpanel** pour le product analytics, **Aircall** pour certains appels sortants, **Genesys** pour les flux entrants importants ou encore **Chargebee** et **Zuora** pour des modèles de billing différents. D’autres catégories sont encore ouvertes : **DealHub** est évalué pour le CPQ, **Webyn** fait partie des options envisagées pour l’A/B testing et Rose pourrait être testé comme agent conversationnel. Cette architecture permet aussi de mieux comprendre la rationalisation menée par l’équipe. L’objectif n’est pas uniquement de réduire le nombre de logiciels, même si Yanis estime pouvoir supprimer à terme environ **200 000 euros de licences**. Le véritable travail consiste à distinguer les différences de stack justifiées par les modèles commerciaux de celles héritées de l’histoire du groupe. Dans une organisation construite par acquisitions, standardiser pour standardiser peut simplement déplacer la complexité. La cible consiste plutôt à construire quelques briques centrales solides et à conserver des outils spécialisés lorsqu’ils répondent à un besoin réellement différent. ## The stack of Shine One row per workflow: a tool appears as many times as it serves distinct jobs. Declared in an interview on [à confirmer]. | Workflow | Tool | Usage | Status | | --- | --- | --- | --- | | Data warehouse | [Snowflake](/snowflake-inc.md) | Centralisation de la donnée | in use | | Data warehouse historique | [Databricks](/databricks.md) | Utilisé auparavant sur certains périmètres Cegid | in use | | Reverse ETL | [Hightouch](/hightouch.md) | Mise à disposition des données Snowflake dans les outils Revenue | in use | | CRM | [HubSpot](/hubspot-inc.md) | CRM cible et marketing automation | in use | | CRM legacy | [Salesforce](/salesforce.md) | Encore utilisé sur certains périmètres Cegid | in use | | Automation | [n8n](/n8n.md) | Automatisations et connexions entre systèmes | in use | | Lifecycle | [Braze](/braze.md) | In-app, email et communications déclenchées par les événements produit | in use | | Calling sortant | [Aircall](/aircall.md) | Téléphonie, particulièrement pour les appels sortants | in use | | Calling entrant | [Genesys](/genesys.md) | Gestion des volumes importants d’appels entrants | in use | | Support | [Intercom](/intercom.md) | Support notamment chez Shine | in use | | Support legacy | [Zendesk](/zendesk-inc.md) | Encore présent dans certaines entités | in use | | CPQ | Salesforce CPQ | CPQ encore utilisé sur une partie du groupe | in use | | CPQ en évaluation | [DealHub](/dealhub.md) | CPQ, deal rooms et potentiel usage pour les revendeurs | in use | | Billing | [Chargebee](/chargebee.md) | Billing/subscription notamment sur les activités PLG | in use | | Billing | [Zuora](/zuora.md) | Billing des activités davantage sales-led | in use | | Billing | [Frisbii](/frisbii.md) | Présent notamment en Allemagne | in use | | Billing / comptabilité | [Moneybird](/moneybird.md) | Présent dans certaines entités | in use | | Affiliation | [Affilae](/affilae.md) | Gestion de l’affiliation et de partenariats | in use | | Web analytics | [GA4](/google-marketing-platform/products/google-analytics.md) | Analytics des sites | in use | | Mobile attribution | [AppsFlyer](/appsflyer.md) | Attribution et suivi des conversions app | in use | | Product analytics | [Mixpanel](/mixpanel.md) | Analyse des comportements dans le produit | in use | | A/B testing | [AB Tasty](/ab-tasty.md) | Solution historique côté Cegid | in use | | A/B testing | [Convert](/convert.md) | Solution utilisée côté Shine | in use | | A/B testing en évaluation | [Webyn](/webyn.md) | Solution considérée dans le benchmark en cours | in use | | CMS | [Prismic](/prismic.md) | CMS de Shine France | in use | | CMS | [Strapi](/strapi.md) | CMS de Shine.co | in use | | CMS legacy | [WordPress](/wordpress.md) | Utilisé pour plusieurs sites legacy | in use | | CMS | [Webflow](/webflow.md) | Utilisé notamment par sevdesk | in use | | Agent conversationnel en évaluation | [Rose](/rose.md) | POC envisagé pour la lead generation | in use | | IA | [Claude Enterprise](/anthropic.md) | Data cleaning, déduplication et migrations | in use | | Call intelligence | [Modjo](/modjo.md) | Analyse des appels et coaching | in use | | Project management | [Linear](/linear.md) | Ticketing et roadmaps Web et Produit | in use | | Communication interne | [Slack](/slack-technologies-llc.md) | Communication des équipes | in use | | ATS | [Teamtailor](/teamtailor.md) | Recrutement | in use | | RH | [Bob](/hibob.md) | Présent dans l’environnement RH, cible non arrêtée | in use | Source: https://www.softatlas.io/fr/use-case/shine-cegid-stack-revenue