Pour ce premier épisode de la série « Behind the Stack », nous retrouvons Cécile Ritte, Head of Engineering chez Pigment. La scale-up, qui développe une plateforme d’IA dédiée à la planification et à la gestion de la performance, doit concilier deux impératifs : innover vite et garantir la fiabilité de ses services. Elle fait aussi évoluer son infrastructure pour répondre aux exigences des grands comptes, tout en cultivant une culture d’ingénierie à la fois rapide et exigeante.

L’entretien est aussi l’occasion d’aborder l’un des sujets les plus structurants de la tech aujourd’hui : l’essor de l’IA. Des expérimentations menées en sandbox à l’intégration directe dans les workflows, les dirigeants de Pigment expliquent comment ils s’approprient cette révolution, tout en gardant le cap sur une vision architecturale de long terme et sur la création de valeur pour leurs clients.

Section 1 : Leadership et vision

Comment alignez-vous la roadmap engineering avec la vision stratégique globale de l’entreprise dans un environnement de forte croissance comme celui de Pigment ?

À plusieurs moments clés de l’année, la direction redéfinit les priorités produit et les axes d’investissement. Ces choix guident aussi bien le recrutement que l’allocation des ressources d’ingénierie.

Cette stratégie descendante est ensuite confrontée aux retours produits, techniques et organisationnels, collectés chaque trimestre à partir de feedbacks qualitatifs et de KPIs. C’est à ce moment-là que sont identifiés et arbitrés les projets d’ingénierie jugés critiques. Certains sont directement liés aux clients, comme la montée en charge de l’infrastructure. D’autres concernent la productivité des équipes ou l’efficacité des coûts. L’enjeu est toujours de rester cohérent avec la roadmap globale de l’entreprise.

Ce processus se veut aussi transparent que possible pour les équipes engineering. L’idée est de trouver le bon équilibre entre une vision prescriptive venue du haut et l’autonomie des équipes, qui doivent pouvoir partager leurs retours, proposer leurs propres projets et organiser leur plan de delivery trimestriel. Pour favoriser une prise de décision réellement collaborative, chaque proposition doit être argumentée et, autant que possible, accompagnée d’une estimation chiffrée de son impact sur le business.

Sur quels principes vous appuyez-vous pour concilier innovation et fiabilité opérationnelle ?

La meilleure façon d’éviter les erreurs serait de ne rien faire. Mais chez Pigment, où l’innovation est au cœur de notre ADN, ce n’est évidemment pas une option. Notre principe est plutôt de créer un cadre où l’on peut échouer en toute sécurité… et apprendre vite de ces échecs. Pour nos équipes d’ingénierie, cela signifie concevoir des systèmes et des processus qui limitent au maximum le coût et l’impact des erreurs. La réversibilité est aussi essentielle : si un problème survient, nous devons pouvoir revenir rapidement en arrière.

Concrètement, un ingénieur ne devrait pas se demander s’il doit déployer un changement risqué, mais plutôt : « à quelle vitesse pourrai-je l’annuler si nécessaire ? ». Pour cela, nous misons sur des feature flags, des outils d’observabilité et des capacités de rollback quasi instantanées.

C’est la même logique pour nos ingénieurs et data scientists qui explorent l’IA. Ils disposent de leur propre sandbox, où ils peuvent déployer ce qu’ils veulent en quelques secondes. Cela leur permet de tester librement de nouvelles idées sans avoir à passer par un pipeline CI/CD complet.

Quelles sont, selon vous, les qualités essentielles d’un CTO moderne pour réussir aujourd’hui ?

Le rôle de Chief Technology Officer a beaucoup évolué. Aujourd’hui, un CTO performant doit combiner une expertise technique approfondie avec une vision stratégique, des qualités humaines et un sens aigu du business. Selon moi, trois qualités essentielles se démarquent :

• Un mélange de curiosité technique et de pragmatisme:

Un bon CTO sait maîtriser les grandes tendances technologiques tout en discernant quand éviter les effets de mode ou les impasses. C’est particulièrement crucial dans des domaines en évolution rapide comme l’IA. Un bon CTO est capable d’appréhender tout le spectre de ce qui est possible, mais aussi de faire des choix tranchés sur ce qui apportera réellement de la valeur.

• Le sens du business et l’empathie client:

La technologie n’existe pas dans le vide. Un bon CTO doit comprendre en profondeur le produit, le marché et les utilisateurs. Cela implique de pouvoir challenger certaines décisions de projet, contribuer à façonner les roadmaps et concevoir des architectures qui permettent de construire la meilleure solution pour résoudre les bons problèmes.
Chez Pigment, par exemple, lorsque nous concevons notre infrastructure, nous devons avoir une compréhension fine des différents cas d’usage de nos clients : sont-ils orientés data ou calculs, subissent-ils une forte saisonnalité, etc.

• L’aptitude à travailler avec les personnes:

Le leadership technologique moderne concerne autant l’humain que la technologie. Un CTO devrait consacrer 20 à 30 % de son temps au recrutement, et investir activement dans la création de relations transverses, le mentorat, le networking, ainsi que dans le partage et la capacité à mobiliser les équipes autour d’une vision commune.

Section 2 : Croissance de l’infrastructure

Quelles ont été les décisions les plus critiques que vous avez prises au début de Pigment pour concevoir une infrastructure capable d’accompagner la croissance de vos clients ?

Dès le départ, nous avons fait plusieurs choix architecturaux clés afin que la plateforme puisse évoluer en toute fluidité et répondre aux besoins des grands comptes.

Nous avons développé un moteur sparse, spécifiquement conçu pour gérer efficacement de vastes ensembles de données clairsemées. C’est un atout majeur dans le cadre de la planification financière, où de nombreux points de données ne s’appliquent pas à toutes les combinaisons de dimensions. Ce moteur excelle autant dans les calculs que dans la visualisation de données multidimensionnelles.

Plutôt que de chercher à augmenter la puissance d’une seule machine, nous avons privilégié une architecture distribuée permettant une croissance horizontale. Concrètement, cela nous offre la flexibilité d’ajouter des ressources supplémentaires à mesure que les volumes de données augmentent, tout en garantissant une continuité de service. Cela signifie que nous pouvons évoluer au même rythme que nos clients, sans avoir à repenser le cœur de la plateforme.

Enfin, nous avons conçu le système de manière à ce que les utilisateurs puissent toujours accéder et saisir leurs données, même lors des réévaluations de modèles. Cette continuité d’accès est essentielle pour répondre aux standards des grandes entreprises.

Comment Pigment fait-il évoluer son architecture, du MVP initial jusqu’à une plateforme capable de répondre aux exigences des grandes entreprises ?

À mesure que Pigment évolue, notre priorité est double : assurer l’évolutivité de la plateforme et répondre aux standards des grandes entreprises. Cela signifie renforcer continuellement notre architecture pour offrir plus de confiance et de gouvernance, avec des fonctionnalités comme la gestion des versions ou du cycle de vie. Nous élargissons aussi notre écosystème avec des intégrations d’entreprise, des API publiques qui permettent d’automatiser et de personnaliser, et des dispositifs de sécurité avancés comme le contrôle d’accès finement paramétrable ou l’authentification unique (SSO). L’objectif : donner aux clients la certitude que Pigment peut soutenir leur croissance tout en respectant leurs exigences de conformité et de sécurité.

Y a-t-il eu des moments charnières chez Pigment où vous avez dû repenser vos hypothèses techniques de base ?

Oui ! Nous avons connu plusieurs moments clés qui nous ont poussés à revisiter et à faire évoluer notre architecture technique.

Au départ, nous avons complété PostgreSQL avec SingleStore pour gérer de lourdes charges analytiques, car PostgreSQL montrait ses limites en matière de sparsité des données et de performance sur de grands volumes. Avec la montée en usage, nous avons investi dans un moteur de données multi-couches qui sépare le calcul du stockage, ce qui nous permet de faire évoluer chaque couche indépendamment afin de mieux gérer la saisonnalité et la diversité des cas d’usage. Grâce à cette approche, nous favorisons un partage de données optimisé entre les machines et offrons une capacité de mise à l’échelle horizontale pratiquement illimitée.

Nous avons également repensé notre approche du traitement des calculs. Avec le temps, nous avons optimisé le système pour donner la priorité aux zones visibles et utiliser un smart batching capable de combiner intelligemment les changements.

Section 3 : Culture d’ingénierie et équipes

Quelles stratégies mettez-vous en place pour maintenir un fort rythme de livraison sans sacrifier la qualité du code ?

Tout d’abord, nous évitons de surcharger nos ingénieurs avec des processus inutiles. Nous n’adoptons pas de frameworks simplement parce qu’ils sont standards ou utilisés ailleurs.  Nous maintenons un surcroît de processus minimal afin de rester agiles et réactifs face au changement.

Nous encourageons également une prise de décision aussi bottom-up que possible. Nous cultivons un état d’esprit de responsabilité collective grâce à une communication transparente, à la collaboration et à la rotation des responsabilités. Par exemple, les ingénieurs se relaient pour s’assurer que notre pipeline de livraison reste toujours opérationnel et que nous publions en production au moins une fois par jour, en nous appuyant fortement sur les tests automatisés.

Pour renforcer ce sens de la responsabilité et de l’ownership, nous rendons visibles publiquement certains KPIs clés : le temps nécessaire pour qu’un code atteigne la production, la durée des tests end-to-end ou encore notre taux de réussite des déploiements.

Comment structurez-vous vos équipes pour accompagner la croissance ? Favorisez-vous des équipes plateforme, des squads produit, ou un autre modèle ?

Quand Pigment n’était encore qu’une petite équipe d’une quinzaine d’ingénieurs, nous gardions les choses très flexibles, en réorganisant les équipes chaque trimestre pour rester réactifs face aux priorités changeantes.

Avec la croissance, le besoin de stabilité et de spécialisation s’est renforcé. Aujourd’hui, nous comptons 80 ingénieurs répartis en 12 équipes, qui sont un mélange de squads produit et d’équipes plateforme. Les équipes plateforme exposent des services aux squads produit, ce qui leur permet d’abstraire la complexité de la plateforme et de se concentrer sur la livraison de fonctionnalités orientées utilisateur.

Nous avons conçu la structure actuelle des équipes pour qu’elle reflète notre architecture logicielle, en regroupant les équipes au sein de « communautés » lorsque leur travail est fortement lié. Cela optimise la collaboration et réduit la surcharge d’information inutile.

Comment assurez-vous l’excellence technique au sein d’une organisation d’ingénierie en croissance ?

Tout commence évidemment par le recrutement des meilleurs talents, sans jamais transiger. Nous n’avons jamais abaissé le niveau d’exigence chez Pigment. Nos ingénieurs ont mis en place une hiring guild qui travaille en continu avec les recruteurs pour affiner nos processus d’entretien, renforcer notre marque employeur et approcher proactivement les meilleurs candidats.

En grandissant, nous avons également reconnu l’importance d’un onboarding structuré, bien au-delà d’un simple accueil et d’une documentation à jour. Pigment a débuté avec un noyau d’ingénieurs très soudés qui savaient exactement quoi faire. Mais avec la croissance, la culture implicite doit devenir explicite : les faits et les chiffres doivent primer sur l’intuition pour définir une stratégie partagée, et les attentes doivent être clarifiées. Dès l’arrivée d’un nouvel ingénieur, voire avant, il est essentiel qu’il comprenne pourquoi nous faisons ce que nous faisons, à quoi ressemble un code de qualité, et ce qui définit la réussite d’un ingénieur chez Pigment.

Enfin, nous portons une attention particulière à la rétention et au développement des meilleurs talents. Les ingénieurs doivent sentir que Pigment est l’endroit idéal pour apprendre, résoudre des problèmes complexes et évoluer aux côtés de pairs exceptionnels.

Comment gérez-vous la dette technique dans un environnement de startup en forte croissance ?

Certaines entreprises traitent le code legacy et la dette technique en allouant chaque année des ressources fixes. Ce n’est pas notre approche. Nous n’avons pas d’idée préconçue sur la manière dont les équipes doivent passer leur temps. À la place, nous partons des problèmes à résoudre et nous essayons de prendre les bonnes décisions en fonction de la valeur que le travail va créer, que ce soit immédiatement ou à plus long terme, pour nos clients.

Notre capacité à bien gérer ce sujet repose sur un partenariat solide entre ingénieurs et product managers, qui fonctionnent comme une seule et même équipe. Ensemble, ils cadrent les arbitrages, évaluent l’impact et s’assurent que les investissements techniques sont toujours guidés par la valeur apportée aux clients.

Section 4 : Systèmes legacy et vision long terme

Quels sont les choix architecturaux clés que vous avez faits dès le départ pour éviter les problèmes de legacy à long terme ?

Nous avons pris plusieurs décisions architecturales délibérées dès le début, notamment :

• Maintenir un dépôt de code unique. D’après notre expérience, diviser les codebases crée des comportements défensifs et des frictions entre équipes, ce qui freine la collaboration et la croissance rapide.
  
  
• Utiliser autant que possible des composants cloud standards et limiter le recours à des technologies propriétaires, afin d’éviter le vendor lock-in.
  
  
• Adopter l’Infrastructure as Code très tôt pour éviter les configurations manuelles sources d’erreurs, réduire les tâches répétitives et rendre les développeurs autonomes dans leurs besoins d’infrastructure courants.

Quels sont les plus grands défis que vous anticipez pour la stack technologique de Pigment dans les 12 à 18 prochains mois ?

Au-delà de la poursuite de la montée en performance, l’un des plus grands défis viendra de l’avancement de notre vision agentique afin de résoudre des cas d’usage concrets pour nos clients.

L’un des enjeux majeurs avec l’IA est qu’elle n’est pas déterministe, ce qui soulève de nombreuses questions :

• Où faut-il utiliser des fonctionnalités déterministes vs non déterministes pour répondre au mieux aux besoins des utilisateurs ? Et, par conséquent, qu’est-ce qui reste valable dans notre produit et qu’est-ce qui doit être réévalué ?
  
  
• Comment proposer cette fonctionnalité dans une expérience utilisateur optimale ?
  
  
• Et comment la livrer de façon cohérente, fiable et avec une latence minimale, tout en itérant et en combinant plusieurs cas d’usage et modèles ?
  
  

Ces problématiques ne relèvent pas toujours de l’ingénierie traditionnelle. Elles nécessitent de nouvelles approches en matière de tests, de benchmarks et d’orchestration, ainsi qu’une collaboration croissante avec les data scientists et les ingénieurs en machine learning. C’est un défi passionnant que nous avons hâte de relever !

Quelles technologies ou patterns architecturaux vous enthousiasment le plus en ce moment ?

Probablement la manière dont l’IA est en train de transformer en profondeur notre façon de travailler.

Chez Pigment, nous avons la volonté de rester à la pointe de cette transformation. Nous intégrons déjà l’IA dans nos processus opérationnels, que ce soit pour aider les ingénieurs à écrire un meilleur code, détecter et résoudre les problèmes en production, ou encore diffuser la documentation au sein des équipes. Et ce n’est que le début !

L’essor des agents autonomes et des copilotes pourrait redéfinir des workflows entiers. C’est extrêmement enthousiasmant, mais aussi un peu intimidant et même déroutant ! En adoptant l’IA, nous devons aussi réfléchir à son impact, par exemple sur notre capacité à penser de manière critique ou sur nos modes d’interaction. C’est, je crois, un sujet encore trop peu discuté aujourd’hui.

Quel conseil donneriez-vous à un CTO qui occupe ce rôle pour la première fois et qui doit accompagner la croissance d’une entreprise de la Série A à la Série D ?

Comprenez en profondeur le business, et sachez toujours ce qui est le plus important pour votre entreprise à un instant donné. Est-ce le product-market fit, le time-to-value, la rentabilité ? Et arbitrez en conséquence.

1. Anticipez ce qui risque de casser ensuite. Demandez-vous régulièrement, avec vos équipes : et si nous étions multipliés par 10, utilisateurs, données, développeurs, que se passerait-il ? Ce type de réflexion vous permet de travailler à une vision long terme tout en prenant, au quotidien, des décisions pragmatiques. Ne visez pas la perfection : prenez des décisions qui tiendront suffisamment longtemps… et soyez prêts à les revoir plus tard.
   
   
2. Faites confiance à vos équipes et encouragez la responsabilisation dès le départ, en partageant des attentes claires et en donnant aux gens la pleine propriété à la fois des problèmes et des solutions. Apprenez quand intervenir, et quand lâcher prise. Et méfiez-vous de la culture du héros : vous ne voulez pas que l’organisation grandisse plus vite que votre équipe… ou plus vite que vous.
   
   
3. Qu’il s’agisse de repenser l’infrastructure, de créer un environnement où l’échec est possible et instructif, ou de préparer un futur agentique, la vision de Cécile met en lumière un thème central : les meilleures organisations d’ingénierie sont celles qui savent s’adapter, évoluer et apprendre en continu.

Pour les futurs leaders, ces enseignements constituent à la fois un guide pratique et une invitation à élargir leur horizon : construire une technologie pérenne dans un monde en perpétuelle mutation.

👉 Rendez-vous dans le prochain épisode de notre série d’interviews… 🤫 mais il faudra un peu patienter!