Repenser la valeur, les métiers et l'organisation à l'ère de l'IA, entretien avec Mathilde Rigabert (CTPO)

Shirley ALMOSNI CHICHE

— 18 min de lecture
Partager
Repenser la valeur, les métiers et l'organisation à l'ère de l'IA, entretien avec Mathilde Rigabert (CTPO)

Après un premier échange qui m'avait donné plein de billes sur l'histoire de la tech, son futur et les jobs de demain, j'avais envie d'aller plus loin avec Mathilde Rigabert, CTPO, sur une question qui me trottait dans la tête depuis : c'est quoi, en vrai, la valeur d'une entreprise tech aujourd'hui ? Son code ? Sa data ? Sa capacité à exécuter, à pivoter ? Quelle est la valeur aussi d’un développeur ou une développeuse en 2026 à l’ère de l’IA ? Quels sont les nouveaux jobs qui se dessinent ?

Voici l’intégralité de notre conversation : 

Qu'est-ce qui fait vraiment aujourd'hui qu'une entreprise tech a de la valeur, en 2026 ? 

Pendant longtemps on a cru que la valeur, c'était le code. En réalité le code n'a jamais été la valeur. Il coûtait cher à produire, donc tu ne pouvais pas te permettre de te tromper trop souvent : une erreur se payait tout de suite, en semaines d'équipe dev. Pour moi, ce qui compte, ça n'a jamais bougé :  savoir identifier le bon problème, le définir précisément, et trouver la bonne solution à ce problème-là et de savoir le “vendre”. On a toutes vu passer des projets ultra bien codés qui ne servaient à rien parce qu'il n'y avait personne en face pour les acheter.

Donc si je comprends bien, dans ce que tu me dis, la valeur d'une entreprise s'oriente presque plus vers les équipes de vente et de marketing ?

Le code du produit reste important, je ne dis pas l'inverse : si tu fais un produit dans la sécurité, il faut que ce soit fiable, ce n'est pas négociable.

Mais à partir du moment où on admet que l'IA va considérablement simplifier le développement, et j'en suis convaincue, le curseur se déplace.  La question, c'est : est-ce qu'il y a un marché prêt à payer pour ce que tu proposes ? Est-ce que tu proposes la bonne chose ? 

Tout part du marché, toujours ! Donc, oui, la valeur d'une boîte, c'est un peu moins le code mais la connaissance profonde du marché : les réseaux, les clients déjà en portefeuille. Ça, tu ne peux pas le copier.

Mais cette connaissance n’est pas le monopole d’une équipe. Les équipes produit et tech ont besoin aussi de très bien comprendre les clients et leurs besoins, autant que sales et marketing. C’est cet alignement qui fait la différence.

Et la data, tu la vois un peu comme un asset aussi ? Comment tu appréhendes, elle, dans tout ça ?

Pour moi elle est clé, la data. C’est justement ça qui fait la différence. C'est un des plus gros changements que je vois en ce moment dans mes propres équipes : on code plus vite, très bien, tant mieux. Sauf que le reste devient le sujet : comment tu branches tes systèmes entre eux, comment tu fais en sorte que la bonne donnée circule vers les bons systèmes, comment tu la mets à disposition via le contexte dont ont besoin les agents pour être efficaces. A ce niveau-là, c'est un terrain de jeu totalement nouveau qu'on n'avait pas avant. Il y a des outils comme Dust et d'autres qui aident. Et la question de la gouvernance devient centrale : qui a accès à quoi. 

Pourquoi ce sujet de la gouvernance prend autant d'essor aujourd'hui, à ton avis ?

Parce que c'est devenu facile de faire n'importe quoi. Un exemple tout bête : tu veux bien connecter ton système RH à un agent, mais tu ne veux certainement pas qu'une procédure disciplinaire en cours sur quelqu'un devienne trouvable par n'importe qui dans les outils de l'entreprise. 

Tu veux aussi savoir ce qui part vers les États-Unis, si tu as des données sensibles, tu ne veux pas qu'elles partent de façon non maîtrisée vers d'autres systèmes. Tu as besoin de garder la main. Et le problème, c'est que c'est tellement simple aujourd'hui de brancher un agent partout que ça devient vite très complexe à maîtriser. 

Il y a aussi tout le volet auditabilité : comprendre qui a eu accès à quoi ? Et quand ? Pourquoi faire ? Et aujourd'hui, tout se connecte tellement facilement que ce sujet-là devient prioritaire.

On parlait aussi, dans notre échange, de la rapidité d'exécution, tu disais que ça simplifie le code, etc. Du coup, comment toi tu redéfinis la notion de productivité, de succès, au sein d'une équipe tech ? Pour toi, une équipe tech productive, dans le succès, c'est quoi ? Qu'est-ce que tu mets derrière ce mot ?

Une équipe peut être très rapide et pas productive du tout : il suffit qu'elle livre la mauvaise chose. Ce que je regarde se passe donc après la mise en production, ce que devient la feature une fois qu'elle est chez le client. Sur ce qui permet d'y arriver : je construis des équipes où le produit est central, et je le faisais déjà avant l'IA. Le développement, au fond, c'est une accumulation de micro décisions, et c'est vrai côté produit aussi. Si tu ne comprends pas finement à qui tu t'adresses et quel est son problème, tu prends ces centaines de décisions à l'aveugle. C'est là, pour moi, que se joue la productivité.

Si je paraphrase ce que tu dis : la productivité, ce serait quelqu'un capable de s'approprier très vite la compréhension produit, de capter rapidement le besoin et les subtilités du produit ?

Oui, avec une nuance sur la vitesse. Les subtilités du produit, ce que tu dois faire pour y arriver, comment tu résous le problème de la personne en face avec une solution pragmatique : tout ça s'obtient en testant des hypothèses et en corrigeant vite, pas en réfléchissant en amont. On peut aller vite ou non. Mais toujours en testant.

Pour toi, quelles sont les expertises attendues de demain ? Qu'est-ce qui ferait la différence sur un CV, mais aussi au sein d'une équipe ? Quel profil, femme, homme, quel rôle va tirer son épingle du jeu ?

Je n'ai pas de certitude, mais je crois aux profils généralistes avec une ou deux zones de forte expertise. Ce qui change, c'est où se place l'expertise : moins sur un langage ou un framework, plus sur la donnée, l'orchestration, la sécurité, la scalabilité.

Ce qui est sûr aujourd'hui, c'est qu'il faut maîtriser ses outils. Même si ton entreprise, elle, freine des quatre fers sur l'IA, si tu veux sortir du lot, il faut faire l'exercice de ton côté. J'encourage les gens à tester chez eux, à expérimenter, à essayer différents modèles, différentes approches. C’est quelque chose que je mets en place dans les entreprises où j’interviens, j’offre un cadre pour expérimenter.  L’important, c'est déjà de maîtriser ces systèmes. J'entends parfois des personnes me dire qu'elles ne veulent pas du tout ou que cela n’intéresse pas d’utiliser l'IA. Ça va devenir compliqué car l’IA s’étend à toute la chaîne, du ticket au déploiement. 

Ce que j'attends, c'est qu'on maîtrise les outils au point de savoir quand ne pas les utiliser. C'est le vrai sujet : c'est facile de s'en servir pour tout. Donc en entretien, je cherche à savoir si la personne a déjà eu un agent qui est allé trop loin, un refactoring beaucoup trop ambitieux par exemple. Parce que si tu n'as jamais perdu le contrôle, c'est que tu n'es jamais allé assez loin dans l'expérimentation.

Et c'est intéressant, tu me parlais aussi des rôles émergents, tu évoquais des trucs comme DevX, il y avait d'autres rôles comme ça que tu voyais vraiment se dessiner ?

Oui, tout ce qui touche à la plomberie, et c'est lié à ce que je disais sur la gouvernance. Parce qu'un système agentique, au fond, c'est du workflow. Et un workflow, ça se maintient. Exactement comme la CI/CD : on a longtemps sous-estimé ce que ça coûtait de les maintenir, et on a fini par être très contents d'avoir des équipes dont c'est le métier qui permettent de soutenir les autres développeurs. Ce sera pareil ici.

Parce que ça va tellement vite que tu ne peux pas demander à une équipe de dev d'être à la pointe du dernier modèle et du dernier pattern, et en même temps ultra pointue sur la connaissance client. Il va falloir une spécialisation : des gens sur la feature, d'autres sur le système qui la supporte. Qui sont capables de gérer la gouvernance, la sécurité… 

D'autres rôles que tu vois comme des piliers pour les équipes de demain ?

J'ajouterais le côté FinOps IA, parce que ça coûte, et ça coûte très vite beaucoup plus cher que ce que l’on imagine. C’est un métier en soi, pour garantir le ROI. Quelqu'un qui suit ce que chaque usage consomme, qui arbitre entre les modèles, qui va voir les équipes quand un agent consomme trop et qu’il faut optimiser la consommation des tokens. 

Quand tu dis optimisation des tokens, ça peut aller jusqu'à une vraie analyse comparative des outils, ou c'est plutôt savoir se dire “ça, j'en ai besoin, ça, je n'en ai pas besoin” ?

Les deux, mais surtout : quel modèle pour quelle tâche, et de façon automatisée. Parce que quand tu développes, tu ne vas pas t'amuser à changer de modèle tous les quatre matins. Donc avoir une sélection de modèle optimisée pour chaque agent/tâche qui permet de sélectionner le modèle le plus cohérent devient clé.

L'idée, c'est d'optimiser les coûts, parce que dès que tu sors des formules d'abonnement et que tu commences à payer au token, ça devient cher, vite. Et surtout, si ton seul indicateur c'est le nombre brut de tokens, tu te trompes de combat, parce que ce qui compte réellement, c'est le coût à la tâche. 

Un modèle qui coûte trois fois rien mais qui te demande quinze allers-retours pour arriver à la bonne réponse te revient plus cher qu'un modèle deux fois plus cher qui y arrive du premier coup. C'est très difficile à estimer. Sur des boucles agentiques bien identifiées, on peut commencer à le faire, tu peux par exemple tagger sur les différentes gateway pour avoir une estimation par tag, mais ça pose la question de comment tu définis tes tags (par équipe, par cas d’usage…) pour que ça soit pertinent.

Et côté qualité, est-ce que ça ne risque pas de créer un peu de dette technique dans tout ça ?

Oui, ça va en créer. Je ne vais pas dire le contraire : quand tu produis plus vite, tu produis aussi plus de choses à maintenir, et la duplication augmente si personne ne regarde.

Mais clairement, ça aide aussi énormément. Le temps gagné, ça me permet de faire plus de tests, de faire des choses que je n'aurais pas eu le temps de faire avant, ou pas aussi bien. Si le temps regagné reste uniquement sur la production de feature, alors oui, la dette va augmenter. C'est plutôt un bon argument, du coup, pour ceux qui redoutent que “l'artisanat se perde”. On peut quand même rester dans un esprit craft.

Et sur les profils juniors qui entrent sur le marché, est-ce que tu en recrutes, tu en croises ? Quel conseil leur donnerais-tu ? Qu'est-ce qui change pour eux en rejoignant une équipe avec des gens seniors ? Qu'est-ce que tu attends d'eux ?

Je recrute surtout des profils senior ou staff, donc je les vois plus de l'extérieur que du dedans. J'ai vu des juniors patiner avec un agent, parce que ça arrive qu'un agent tourne en rond, sans avoir le réflexe de découper le problème et de le résoudre bloc par bloc. C'est d'ailleurs le seul conseil que j'aurais à leur donner : quand ça tourne, arrête, découpe, avance par morceaux. Ça vaut avec un agent comme sans. Mais peut-être que moi aussi, à la sortie de l'école, sans IA, j'étais capable de tourner des heures en rond sur un bug sans m'en rendre compte, simplement parce que j'étais junior. 

Le sujet est ailleurs. Les features simples, les agents les font quasiment seules, et c'était exactement ce qu'on confiait aux juniors : tu découpais, tu leur donnais un bloc. Est-ce qu'on est en train de scier la branche sur laquelle on est assis ? Je crois que oui. Si on ne forme plus nos juniors, on aura un problème.

Justement, formation de juniors absente : c'est quoi les risques, selon toi ?

Il faut qu'on ait des juniors pour avoir des mid, et qu'on ait des mid pour avoir des seniors dans dix ans. Si on arrête de recruter et de former les premiers, on n'a plus rien à la sortie, et ça se voit trois ou quatre ans plus tard, pas tout de suite. 

Après, est-ce que ces postes vont disparaître ou se déplacer ?. Pour moi, l'IA va les déplacer : les métiers vont changer.

Tu dis “elle va les déplacer”,  ça veut dire quoi concrètement ?

Elle va déplacer les gens vers la gouvernance, vers la data, vers d'autres briques du système. On le voit déjà, il y a moins de temps sur la génération du code et plus sur la relecture de specs ou de code. On va s’éloigner du dev pur (ie écrire le code).

C'est quoi tes red flags, toi, dans un entretien culture fit ou même technique, quand tu rencontres des candidats en 2026 ? Les points rédhibitoires, que ce soit dans le discours, la stack, ou la culture ?

J'en ai deux, qui sont très basiques, et j'ai encore eu le cas récemment. Le premier : se renseigner sur la boîte. Si tu arrives sans rien savoir de l'entreprise, c'est non, même avec un très bon profil sur le papier. Ça prend un quart d'heure aujourd'hui, avec ou sans assistant IA. C'est une marque de respect, et surtout ça te permet de savoir si tu as envie d'y aller. Je suis toujours surprise du nombre de gens qui ne savent pas dire pourquoi ils sont là. 

Le deuxième : la façon de raconter les départs précédents. Sur la majorité des départs, il y a eu un désaccord quelque part, sur la vision, sur la paye, peu importe. Ce que je regarde, c'est si la personne a réfléchi à ce qui s'est passé. Dire du bien ou du mal m'importe peu. Quelqu'un qui me dit "j'ai mis huit mois à comprendre que je ne changerais rien, je suis parti" me raconte quelque chose. Quelqu'un qui enchaîne les griefs sans jamais dire ce qu'il en a compris ne me raconte rien. Ce que je cherche, c'est des gens capables d'apprendre dans la plupart des situations, parce qu'on ne sait pas de quoi demain sera fait : un changement de base de code, un pivot complet.

Et en troisième point, tu en as un troisième ?

Dans nos métiers, la stack, je ne la maîtrise pas forcément par cœur, et ce n'est pas grave. J'ai fait de l'entrepreneuriat, je fais de la cyber aujourd'hui, je n'étais experte ni de l'un ni de l'autre en arrivant, les langages changent souvent d’une mission à l’autre. Notre compétence, c'est d'apprendre vite.

Donc je regarde le rapport à l'IA : qu'est-ce qui a été testé, jusqu'où, et qu'est-ce qui en a été retiré. La réponse elle-même m'importe assez peu, je peux ne pas être d'accord. Ce que je cherche, c'est quelqu'un capable de dire "ça, ça m'inquiète" ou "ça, ça m'emballe" en sachant pourquoi. Y compris un rejet, s'il a été éprouvé. Une opinion qui vient de quelque part.

Est-ce que la rapidité à laquelle l'IA évolue rend ta roadmap et tes décisions un peu obsolètes ?

Pas encore. Là où je vais plus vite que prévu, c'est sur la production. Là où je vais moins vite, c'est sur tout le reste : décider, embarquer les gens, faire évoluer les process. Et ce n'est pas l'IA qui débloque ça.

Ce qui va changer, en revanche, c'est l'horizon. Une roadmap à 2 ans avait du sens quand livrer prenait des mois. Quand ça prend des semaines, l'exercice devient différent : il faut réviser plus souvent et s'engager moins loin. Je le vois déjà dans les petites structures, où j'avance nettement au-delà de ce que j'avais anticipé, et j'avais pourtant vu large.

Tu as un ordre d'idée, en chiffres ou en confort, de ce que ça veut dire “aller plus vite” concrètement ?

Sur un cas précis, un facteur dix. Mais il faut voir les conditions : une toute petite structure, un domaine que je connais par cœur, et je suis quasiment seule à décider. Ce qui me prenait dix jours m'en prend un, voire moins.

Je précise, parce que ce chiffre ne veut rien dire ailleurs. En ce moment je travaille surtout avec des série A et série B, et là on est très loin du compte : le code va plus vite, accélérer le reste c’est le plus gros challenge.

Et en quoi le rôle même de CTPO a-t-il changé ces deux dernières années ? Des compétences managériales que tu n'avais pas besoin de mobiliser hier et qui te servent aujourd'hui ? Des choses que tu attends moins, ou plus, qu'avant ?

Il y a tout l'accompagnement au changement, et c'est nouveau. Comment tu accompagnes quelqu'un qui a passé vingt ou trente ans à devenir expert d'un domaine, et qui voit ce domaine devenir en partie accessible à quelqu'un qui n'y connaît rien ? Pas au niveau d'un expert, mais suffisamment pour que la question du statut se pose. Donc un deuxième chantier de mentoring s'ouvre, en plus de celui des juniors. Il s'adresse à des gens qu'on prend pour des réfractaires alors qu'ils ont surtout peur, et ils ont de bonnes raisons : c'est leur place dans l'entreprise qui vacille, une expertise qui était valorisée et qui l'est moins. On a le droit d'avoir peur de ça. Le travail consiste à les réinscrire dans une trajectoire, alors même qu'on est incapable de dire avec certitude ce qui fera la différence demain. 

Ce que j'attends moins qu'avant, c'est la maîtrise technique pointue, même s'il en faut encore. Ce que j'attends plus, c'est le pilotage. Maintenant que tout le monde peut aller très vite, garder un produit cohérent au lieu d'un Frankenstein demande beaucoup plus d'attention qu'avant. Ce n'est pas parce que tu peux que tu dois.

Est-ce que tu penses que ça sera un des enjeux de demain, justement, de poser des guidelines, des bonnes pratiques ?

Oui, mais surtout côté produit. Les cadres techniques existent déjà en masse, on sait faire. Ce qui manque, ce sont les bonnes pratiques sur la façon de décider quoi construire, maintenant que construire coûte moins cher.

Et je crois que ça va plus loin que des bonnes pratiques : les métiers tech et produit vont se rapprocher. Le rôle de PM s'est construit sur une spécialisation qui avait un sens économique : quand écrire du code coûtait cher, séparer celui qui décide de celui qui construit se justifiait. Quand ce coût baisse, la boucle se resserre et la séparation devient un frein.

Ça ne plaira pas à tout le monde, et c'est légitime : on demande à des gens d'élargir un métier qu'ils ont choisi pour ce qu'il était. Mais je pense qu'on va voir émerger beaucoup de postes plus transverses.

De ce que tu vois depuis ta fenêtre, quels sont les plus grands pièges ou aveuglements collectifs dans lesquels tombent les entreprises tech aujourd'hui avec l'IA ?

Le plus gros, c'est de traiter l'IA comme un sujet d'outillage alors que c'est un sujet d'organisation. On déploie des outils, on forme les équipes tech, et on ne touche ni à la taille des équipes, ni aux rituels, ni à la façon dont les décisions se prennent. Résultat, on va très vite sur la production mais on a peu d’impact sur le process au global.

De façon générale, se méfier des positions extrêmes. Sur une petite start-up qui se lance, un pari tout IA, pourquoi pas. Sur des structures installées, ça se discute.

Quand tu dis « les extrêmes », ça veut dire quoi concrètement ?

Je pense aux boîtes qui ont fait des vagues de licenciements massives en misant tout sur l'IA. Il y a eu des cas médiatisés d'entreprises qui ont annoncé remplacer une grande partie de leur support, puis qui sont revenues en arrière, parce qu'il y a derrière une connaissance métier qu'on ne remplace pas comme ça. Il ne faut pas oublier non plus que l'IA est non déterministe : tu as peut-être la bonne réponse dans 90% ou plus des cas, mais qu'est-ce que tu fais des 10 % restants ? Le choix entre ce qui doit être déterministe et ce qui peut ne pas l’être est essentiel. 

Il y a aussi un point qu'on sous-estime : ce qu'on accepte des humains, on ne l'accepte pas des machines. Un accident de voiture autonome fait beaucoup plus de bruit que des accidents de la route bien plus nombreux et souvent plus graves. La différence tient à la responsabilité : dans un cas, on sait à qui l'imputer.

Cette phrase est intéressante, “ce qu'on accepte des humains, on ne l'accepte pas des machines”, que veux-tu dire exactement ?

L'humain est responsable au sens propre : tu lui confies une mission, il échoue, tu peux lui demander des comptes. Avec une IA, il y a toujours une porte de sortie. On peut toujours te dire que c'est toi qui as mal prompté.

Et comme la responsabilité ne se transfère pas à la machine, elle reste sur celui qui l'a mise là. C'est valable pour moi comme pour n'importe qui : si un agent fait n'importe quoi en production, ce n'est pas l'agent qu'on va voir.

Après, il y a aussi quelque chose de moins rationnel. Même quand on te prouve chiffres à l'appui qu'une machine conduit mieux qu'un humain fatigué, très peu de gens lâchent le volant.

Projection : est-ce que l'IA aura, à terme, définitivement absorbé le développement produit et tech tel qu'on le connaît aujourd'hui ? Ou est-ce qu'on assistera plutôt à un retour de balancier vers l'artisanat numérique et le 100 % humain ?

Ni l'un ni l'autre, je crois. Le développement ne va pas disparaître, il se déplace : moins d'écriture, plus de décisions sur ce qu'on laisse passer et sur la façon dont les systèmes se branchent entre eux. C'est ce que je vois déjà dans mes équipes. Il y avait ce livre, je ne sais pas si tu connais, “La troisième révolution industrielle”, de Jeremy Rifkin je crois, que j'avais lu il y a très longtemps, donc je ne garantis pas la précision de mes souvenirs. Mais il disait en substance que les gens allaient se retourner vers l'économie sociale, la culture, une fois que tout serait suffisamment automatisé. Franchement, je n'ai aucune certitude là-dessus.

Pourquoi il fait ce lien-là, à ton avis, entre automatisation et besoin de se retrouver dans une forme de créativité ?

Il faudrait que je revérifie exactement ce qu'il dit, mais pour moi, son raisonnement, c'est qu'à un moment il n'y aura plus assez de travail salarié pour tout le monde. Et ce n'est plus une hypothèse de livre. En juin dernier, le patron d'Anthropic a publié un texte demandant aux gouvernements de taxer les entreprises d'IA, la sienne comprise, pour financer un revenu de base : 3 % du chiffre d'affaires généré. Il anticipe dix à vingt pour cent de chômage d'ici un à cinq ans, en touchant d'abord les postes d'entrée en col blanc. Quand une boîte propose de se taxer elle-même, c'est qu'elle a vu quelque chose.

Cela dit, je reste prudente : les annonces sont nombreuses, les preuves d'une bascule massive du marché du travail le sont beaucoup moins. Et ce que j'observe va plutôt contre l'idée d'un grand remplacement. Plus une entreprise est grosse, moins l'IA apporte proportionnellement, parce que ce qui coûte cher dans une grosse boîte, c'est la communication, l'organisation, la structuration des échanges. Je le vois très concrètement entre une série B et une start-up qui démarre. Sur la start-up, ça va incroyablement vite. Sur la série B, ça aide beaucoup sur le code, et tout le reste, les rituels d'équipe, l'organisation existante, l'organigramme, il faut y embarquer les gens un par un.

Le métier émergent en série B, ce serait plutôt tout ce qui touche à l'organisation, repenser les process ?

Oui. En série B, ce qui bloque n'est plus la production, c'est la coordination. Il y a énormément de réunions dont l'objet est simplement de s'assurer que tout le monde vise la même chose.

Et beaucoup de ces réunions existaient pour une bonne raison : il fallait trancher avant de construire, parce que construire coûtait cher et qu'une erreur se payait en semaines d'équipe. Quand construire devient rapide, l'équilibre change. Il devient souvent moins coûteux de tester que de réunir pour décider.

Donc oui, il y a un métier là-dedans. Quelqu'un dont le travail est de regarder l'organisation existante et de dire ce qui n'a plus lieu d'être : quelles réunions, quels circuits de validation, quels périmètres. C'est le travail le moins outillé de tous, et probablement le plus déterminant.

Est-ce que tu voudrais rajouter d'autres choses que j'aurais peut-être oublié d'évoquer ?

Pour moi, l’enjeu est de repenser complètement nos entreprises, la façon dont on les a organisées. C'est pour ça que la distinction tech / produit va devenir beaucoup plus poreuse très vite. Et surtout, ce qui me frappe, c'est qu'on est en train d'implémenter l'IA dans des entreprises qui n'ont pas encore vraiment compris que c'est une transformation qui va largement au-delà du dev et du produit. 

En réalité, c'est l'entièreté de l'organisation qu'il faut changer : la taille des équipes, la façon dont elles sont organisées, les intitulés de poste, les périmètres de responsabilité. C'est un énorme chantier.

Un immense merci à Mathilde Rigabert pour cet échange d'une richesse folle. Un sujet qui mérite clairement d'être approfondi, peut-être même autour d'une conférence dédiée aux carrières tech à l'ère de l'IA, tant les inquiétudes et le flou sont réels sur le terrain.

À propos de Mathilde Rigabert

Mathilde Rigabert est CTO/CTPO Freelance, avec un parcours qui l'a menée de l'entrepreneuriat à la direction technique et produit, notamment chez Jolimoi, avant de se spécialiser aujourd'hui sur des sujets de cybersécurité et d'accompagnement des entreprises (série A/B en particulier) dans leur transformation IA. Elle intervient régulièrement en conférence et partage ses réflexions sur les mutations des métiers tech et produit.

Vous pouvez la retrouver ici :

Lire la suite