Marc 00:00:00 – 00:00:14 : Aujourd’hui, je reçois Anatole Parree, cofondateur et CTO de SustainEco. SustainEco est un SaaS qui automatise le calcul et l’optimisation de calcul carbone des bâtiments, qui a été racheté par Aegis, une grande entreprise d’ingénierie internationale. Bonjour Anatole. 

Anatole 00:00:15 – 00:00:15 : Bonjour Marc. 

Marc 00:00:15 – 00:00:19 : Alors Anatole, est-ce que tu peux nous parler un petit peu plus de SustainEco ? 

Anatole 00:00:19 – 00:00:47 : Comme tu l’as dit, le système d’éco est un SAS qui a pour vocation d’optimiser à la fois dans un premier temps le calcul et dans un second temps l’optimisation, l’aide à la décision du calcul carbone et en réalité un peu plus que carbone puisqu’on a environ une vingtaine d’indicateurs environnementaux dans la construction et la rénovation de bâtiments. Aujourd’hui, on est présent en France et on est en train de s’étendre en Europe. 

Marc 00:00:47 – 00:00:49 : Quel était le constat sur le besoin ? 

Anatole 00:00:49 – 00:02:33 : Il y a en réalité trois besoins initialement. Un besoin qui est directement lié à la réglementation. Donc ça, c’est spécifique à la France, puisque depuis deux ans, on a une loi qui s’appelle la RE2020, qui oblige tous les bâtiments neufs à se présenter sous un seuil carbone au moment de la livraison du bâtiment. Donc ce n’est pas une obligation de moyens, ce n’est pas juste faire un bilan carbone, c’est une obligation de résultats. Il faut être sous un certain seuil, et ces seuils vont aller en décroissant durant les prochaines années pour suivre la trajectoire de l’accord de Paris. C’est un des secteurs où on est en ligne avec l’accord de Paris. Ça, c’est le premier besoin, donc une obligation réglementaire. Ensuite, il y a un second besoin qui est dû aux clients, qui est que les personnes qui commandent les bâtiments, que ce soit des mairies, des promoteurs immobiliers, des personnes privées, veulent que ces bâtiments respectent un certain nombre de normes, de certifications, pour ensuite accroître leurs valeurs. C’est tout le questionnement qu’il y a en ce moment avec la finance verte et les actifs échoués, pour ne pas que les bâtiments, dans quelques années, ne valent plus rien, puisqu’en fait, ils seraient des sources de carbone trop importantes. On vise à les rendre durables et vertueux, le plus vertueux possible au moment de leur conception, construction. Troisième besoin, c’est lié au reporting. Un certain nombre d’entreprises, notamment les très grosses entreprises, sont contraintes par du reporting extra-financier. Ou bien c’est des contraintes réglementaires, là encore, avec la taxonomie européenne qui est en train d’arriver. Ou bien des contraintes liées aux grands fonds d’actifs, tels que BlackRock, qui imposent à leur participation de respecter un certain nombre de standards. Tout ça fait qu’aujourd’hui, dans la construction, on ne peut plus construire, en fait, personne ne construit plus sans un calcul carbone associé. Et comme je le disais juste avant, ce n’est pas que carbone. En réalité, il y a 25 indicateurs dans la RE20, mais la plupart des gens ne regardent que le carbone. 

Marc 00:02:34 – 00:02:35 : Il y a quoi d’autre comme indicateur ? 

Anatole 00:02:35 – 00:02:51 : Il y a l’acidification des eaux, il y a l’artificialisation des sols, il y a la consommation de tout un tas d’énergies de types différentes. On se dit que minimiser le carbone permet de minimiser les autres indicateurs, ce qui est vrai au premier ordre. 

Marc 00:02:51 – 00:02:54 : Ok, alors comment a démarré l’aventure ? 

Anatole 00:02:54 – 00:03:44 : L’aventure a démarré de manière pas très originale par une bière pas très loin d’ici à Rémétier. On s’est dit dans un premier temps qu’on voulait faire quelque chose contre le carbone. C’était un peu dans l’air du temps à ce moment-là. Alors dans un premier temps on s’est dit que le plus facile c’était de faire du conseil. D’ailleurs le tout premier rendez-vous qu’on a eu avec Sustain Eco était à deux pas d’ici rue du Zest avec un fonds d’investissement qui possède un certain nombre de participations et on voulait comprendre les enjeux qu’ils avaient par rapport au carbone, notamment par rapport au reporting extra-financier. Donc dans un premier temps on a fait du conseil, on a fait des bilans carbone d’entreprise et on s’est spécialisé dans le bâtiment. Et notre objectif, ce qu’on voulait vraiment faire, c’était de faire un produit. Ça ne nous intéressait pas vraiment de faire que du conseil. Et donc, assez rapidement, au bout de quelques mois, on a pivoté pour avoir uniquement un produit, uniquement sur une verticale. 

Marc 00:03:45 – 00:03:48 : Ok. Sur une verticale qui est le BTP. 

Anatole 00:03:48 – 00:03:54 : Sur la verticale du BTP, complètement. Et en fait, en réalité, plutôt du bâtiment même. Donc, un sous-ensemble du BTP. 

Marc 00:03:55 – 00:03:58 : Ok. Alors concrètement, comment fonctionne votre logiciel ? 

Anatole 00:03:58 – 00:04:47 : L’objectif, c’est de faire le calcul carbone associé à l’ensemble des matériaux de construction d’un bâtiment. En entrée, on a un grand fichier Excel ou bien l’export depuis un autre logiciel qui contient l’ensemble des données de tous les matériaux du bâtiment. Il y a trois infos. C’est quoi le matériau ? C’est quoi la quantité ? Et c’est quoi l’unité ? Associé à chacun de ces matériaux, on va venir placer un facteur carbone, donc combien un mètre cube de béton ou un kilo de béton émettent CO2 durant tout son cycle de vie. Ensuite, on va faire ça pour chaque ligne, donc on va faire plein de multiplications, puis on va tout additionner, et à la fin, en bas à droite, on a un gros total. Et on met ça dans un SAS qui permet aux gens de comprendre les sources de carbone, comprendre les optimisations, on propose des améliorations, des variantes, etc. 

Marc 00:04:47 – 00:04:56 : Ok, alors les données que vous traitez, tu nous as parlé d’un gros Excel, est-ce que c’est tout ? Quelles sources de données vous avez pour construire ces calculs ? 

Anatole 00:04:56 – 00:06:11 : On a deux sources de données qui sont un regard. D’un côté, le Excel dont tu parles, ou qui peut être une API depuis un logiciel de conception, qui sont les données métiers, les données clients. Ce sont des données qui sont très non structurées, puisque ce Excel est très souvent fait à la main par les gens, donc il a des têtes complètement différentes. Très prosaïquement, il commence très rarement en haut à gauche. Les colonnes ne sont pas du tout dans le même ordre, n’ont pas du tout les mêmes noms, ce qui… qui est dans chacune des cellules le nom des matériaux. C’est très souvent des phrases un peu à rallonge pour décrire précisément les choses en employant des mots qui ne sont pas définis, pas finis, pas dans un dictionnaire. Donc à peu près toutes les données peuvent avoir à peu près toutes les formes possibles. Ensuite, on regarde ça, on a les données carbone, qui elles sont très normées, parce qu’elles proviennent de bases de données, en France ça s’appelle INIES, qui sont des bases de données réglementaires, on est obligé d’aller piocher là-dedans, on n’a pas le droit d’aller piocher ailleurs, et pour les industriels, pour mettre leurs données dans cette base de données de référence, c’est assez compliqué aussi. Tout notre travail et notre valeur ajoutée, notamment d’un point de vue technologique, c’est de faciliter la mise en relation entre les données métiers, clients, utilisateurs, d’un côté, et les données de référence ministérielle environnementale, de l’autre. 

Marc 00:06:12 – 00:06:25 : Alors, à quel point c’est fiable de faire des calculs carbone ? Ces données-là, à quel point elles sont fiables par rapport aux matériaux ? Quel est le niveau de fiabilité d’une estimation ? 

Anatole 00:06:25 – 00:07:38 : Il y a plusieurs types d’incertitudes. Il y a l’incertitude des quantités métiers. Quand on dit dans mon mur, il y a tant de mètres carrés ou tant de mètres cubes de béton, forcément, il y a une incertitude qui est globalement très faible puisqu’il y a des coûts qui sont associés. Plus il y a de l’incertitude, plus il y a des coûts qui seront importants. De l’autre côté, il y a l’incertitude qui est liée à la fiche environnementale. Dire que le béton émet tant de CO2, ça dépend en réalité du type exact de béton, du transport, de tout un tas de choses qui font qu’il y a une incertitude. Ça, on ne peut pas y faire grand-chose. Nous, en tant que sustainability, on ne peut pas y faire grand-chose et globalement, le ministère et les utilisateurs, les clients, essayent de les minimiser au maximum. Et nous, il y a une incertitude supplémentaire qui est dans le matching qu’on fait entre les données utilisateurs et les données de référence. Ça arrive, c’est un algo de machine learning, forcément, de temps en temps, ça se trompe. Donc on a entre 90 et 100% de précision, d’accuracie. Donc un peu moins de 10% d’incertitude. Cependant, cette incertitude, ces fausses prédictions, qui déjà sont corrigables par l’utilisateur, on est capable de donner une incertitude, une confiance à chaque prédiction. Et surtout, en général, quand on se trompe, on se trompe de pas beaucoup. Donc c’est pas grave. 

Marc 00:07:38 – 00:07:42 : Le but, c’est d’avoir un ordre de grandeur, de s’assurer d’une trajectoire année après année ? 

Anatole 00:07:42 – 00:08:06 : Alors un peu plus que ça quand même, puisque comme je disais, il y a l’obligation de résultat. Donc si tu te trompes et ça fait que tu passes le seuil alors qu’en réalité tu n’aurais pas dû le passer au moment de la certification, ça risque de ne pas bien se passer. Réciproquement, si tu te trompes et que du coup tu ne passes pas alors que tu aurais dû passer, tu as un surcoût qui est potentiellement assez important pour ton bâtiment. Cependant, l’incertitude des fiches est de 10%, donc on ne peut pas faire beaucoup mieux que ça. 

Marc 00:08:06 – 00:08:12 : Oui. Le certificateur, il fait comme vous ? C’est quoi la méthode qu’il faut se faire certifier après ? 

Anatole 00:08:12 – 00:08:34 : Le certificateur, il va venir sur le chantier, vérifier que les données liées aux factures d’achat pour les matériaux correspondent bien à ce qu’il y a dans le document de certificat que Swiss Tainéco exporte. Et que s’ils ont dit qu’il y avait tant de mètres cubes de béton, il y a réellement tant de mètres cubes de béton qui sont catabilisés dans Swiss Tainéco et qu’on a compté le bon béton. 

Marc 00:08:34 – 00:08:46 : D’accord. C’est plus une sorte d’audit ? Est-ce qu’il y a des grands verrous technologiques, des obstacles que vous avez dû surmonter pour développer votre algorithme ? 

Anatole 00:08:46 – 00:09:07 : Il y a deux problématiques qui sont difficiles. Il y en a une qui est la classification dont je viens de parler. À chaque ligne de matériaux, quel est le facteur environnemental associé ? En fait, il y a plusieurs milliers de facteurs environnementaux. Dans la base française, il y en a quasiment 6000. Donc, c’est la classification extrême multiclasse qui est assez difficile intrinsèquement. 

Marc 00:09:07 – 00:09:11 : Est-ce qu’on peut avoir des exemples ? Qu’est-ce que c’est, par exemple, les facteurs environnementaux ? 

Anatole 00:09:11 – 00:09:49 : C’est, par exemple, une plainte de 5 cm de haut en bois français, de pin, en bois de pin français, c’est tant de CO2 par mètre linéaire. Mais après, tu as aussi la plainte qui fait 7 cm, puis tu as aussi la plainte qui fait 10 cm. Donc, le fait d’être capable de dire pour un matériau, c’est plutôt une plainte de 5 en pin français ou plutôt une plainte de 7 dans tel ou tel type de bois, pas français, ce n’est pas si facile. Donc ça, c’est le premier gros challenge. La seconde difficulté qui s’ajoute à ce problème, c’est qu’on est parti avec zéro données labellisées. Donc pour faire la classification sur 6000 classes, ce n’était pas facile. 

Marc 00:09:49 – 00:09:52 : Du coup, vous avez fait comment ? Je me permets de faire une petite parenthèse. 

Anatole 00:09:52 – 00:10:00 : Et du coup, pour ça, on a fait une première méthode non supervisée. On a ensuite labellisé beaucoup de données. 

Marc 00:10:01 – 00:10:12 : Donc, non supervisé, on faisait quoi ? Des clusters ? On faisait des catégories ? Ça, c’est le même genre de facteur, comme tu les avais appelés. Et donc, une fois qu’on a les catégories, il fallait quand même mettre une étiquette. après ? 

Anatole 00:10:12 – 00:10:52 : Exactement. En fait, on a quand même le nom de l’affiche, donc plainte de 5 cm en pain français. Ça nous donne quand même une info. Et même si on n’a aucun exemple au début ou très peu d’exemples, ça nous permet quand même de se raccrocher un peu aux branches au tout début. Il y a plein de choses qui passent à la trappe parce qu’en fait, ça ne ressemble pas suffisamment, mais il y a quand même un certain nombre de choses auxquelles on peut le rattacher. Et puis ensuite, à la main, on vient corriger les erreurs. Donc au début, on avait une accuracy très très très très faible. Et puis en labellisant des choses, et puis en réentraînant, et au final, en quittant le non-supervisé qui a ses limites et en passant à du supervisé, on finit par arriver à des résultats bons. 

Marc 00:10:52 – 00:10:57 : Et vous devez avoir certaines catégories qui sont très peu représentées, j’imagine, et certaines qui sont massivement représentées. 

Anatole 00:10:58 – 00:11:22 : Exactement. Du coup, on a une distribution en SKU, en loi de puissance, avec effectivement une queue qui est assez longue. 90% des catégories n’ont que quelques exemples, ce qui pose une vraie difficulté. Il y a tout un travail sur comment on est capable d’échantillonner en surtirant ces lignes-là pour qu’elles soient beaucoup plus présentes dans le dataset qu’elles ne le sont dans la réalité. 

Marc 00:11:23 – 00:11:29 : Et en échantillonnant un peu plus ces catégories, on risque pas de trop souvent les faire ressortir. 

Anatole 00:11:32 – 00:12:40 : Là-dessus, typiquement, j’ai parlé tout à l’heure d’accuracie. En réalité, on regarde plusieurs types d’accuracie. Il y a l’accuracie macro et l’accuracie micro. La distinction, c’est est-ce qu’on regarde l’accuracie sur la distribution des données réelles, où les données très présentes vont être surreprésentées, ou est-ce qu’on regarde l’accuracie sur la distribution renormalisée, où une erreur sur une classe très présente versus une erreur sur une classe très peu présente valent la même chose ? Et donc on a un équilibre, un compromis à trouver entre ces deux accuracies. Parce qu’en fait, si on n’est que bon sur ce qui est très présent pour les utilisateurs, c’est un peu l’enfer. Et si on n’est pas suffisamment bon sur les catégories très présentes, il ou elle doit modifier beaucoup de lignes. Peut-être juste. un autre point intéressant, je pense, techniquement, c’est que nos données de référence, donc les données environnementales, forment un arbre. Parce que les plaintes, comme je disais, on a plusieurs types de plaintes, mais on voit bien qu’on peut les regrouper sous une catégorie qui s’appellerait plainte en bois, elle-même dans une catégorie qui s’appellerait plainte, elle-même dans une catégorie qui s’appellerait revêtement de mur ou de sol. Et donc, du coup, on peut s’aider de cette arborescence pour faire notre entraînement. Ok. 

Marc 00:12:41 – 00:13:00 : Vous recevez des données sous format de fichier Excel qui viennent d’un peu partout, dans des formats assez différents, et puis j’imagine que c’est régulier, vous avez tout le temps des nouvelles données à ingérer. Comment est-ce qu’on résout un problème d’harmonisation des formats de fichiers Excel ? Comment est-ce que vous avez attaqué ce problème ? 

Anatole 00:13:00 – 00:13:44 : On l’a mal attaqué initialement parce qu’on a cru qu’avec du machine learning, avec 100% de machine learning, ça allait bien se passer. Ça ne s’est pas très bien passé, pas aussi bien qu’on le voulait. On a un peu sous-estimé la difficulté de ce problème. Ensuite, après pas mal de travail, on est revenu sur des choses plus heuristiques. On a des algos de machine learning, mais on a surtout des règles métiers qui viennent s’amonceler au fur et à mesure qu’on a des nouveaux fichiers qui arrivent. avec du coup une difficulté qui est comment est-ce que quand on a un nouveau fichier qui arrive et qu’on change notre règle métier, on s’assure qu’on casse pas tous les anciens fichiers sur lesquels on a testé. Donc ça nous a pris quasiment un an de trouver le bon réglage. C’était assez minutieux comme travail et aujourd’hui on n’y touche plus trop. 

Marc 00:13:44 – 00:13:52 : D’accord. Et donc l’approche machine learning c’était de faire quoi ? C’était d’utiliser des modèles de langage ? 

Anatole 00:13:52 – 00:14:20 : Oui, on avait des modèles de langage, on a essayé des modèles de layout detection pour comprendre la structure du fichier Excel. Après, ces modèles-là ont beaucoup progressé depuis quelques mois. Je n’ai pas testé les tout derniers YOLO, par exemple, mais les versions un peu plus anciennes de YOLO, ça ne fonctionnait pas suffisamment bien et on avait du mal à être robuste à nos erreurs. Quand ça ne fonctionnait pas, ça partait complètement cacahuète. 

Marc 00:14:22 – 00:14:33 : Donc là, vous avez un modèle qui est plus spécifique au fichier Excel qu’on vous envoie. S’il y avait un nouveau format qui devait se rajouter, vous devriez faire un développement spécifique à ce nouveau format ? 

Anatole 00:14:33 – 00:14:43 : Oui, et d’un autre côté, on a plusieurs centaines de clients. Donc en fait, on est quand même assez robuste à la diversité des formats. 

Marc 00:14:43 – 00:14:50 : Qu’est-ce que ça change d’avoir eu à internationaliser les modèles et donc l’activité ? 

Anatole 00:14:50 – 00:15:39 : D’un point de vue purement technique, il a fallu changer le modèle de base qu’on utilisait, qui était spécifique au français, d’un côté, et puis ça fait qu’on repart avec zéro donnée, puisqu’on n’a plus tout notre dataset. Et donc, finalement, plusieurs possibilités, le fait de traduire le dataset du français à, par exemple, l’anglais, le fait de récupérer un nouveau dataset et de le labelliser, Ce n’est pas une difficulté insurmontable. Ça rajoute pas mal de challenges de ce côté-là. Par ailleurs, le fait de commencer à gérer plusieurs modèles en parallèle avec plusieurs versions dans plusieurs langues, ça nous oblige aussi à être beaucoup plus matures sur l’industrialisation, le monitoring. Et c’est quelque chose d’intéressant. 

Marc 00:15:40 – 00:15:50 : Vous utilisez quoi comme outil, stack logiciel, pour le déploiement, monitoring de modèles ? Stack ML Ops, tu vas dire, c’est quoi ? 

Anatole 00:15:50 – 00:16:11 : Pour l’instant, on n’est pas encore suffisamment mature sur le sujet. On utilise au moment de l’entraînement Wait and Bias. Et ensuite, on déploie tout sur AWS. Mais par exemple, aujourd’hui, on n’a pas une vision claire des performances en production. de nos modèles hormis sur des petits produits qu’on a développés nous-mêmes. 

Marc 00:16:11 – 00:16:16 : ok pourquoi utiliser des gros modèles versus des petits modèles dans votre use case? 

Anatole 00:16:16 – 00:17:10 : alors nous on a fait le choix des petits modèles enfin petits. plusieurs centaines de millions de paramètres mais pas de LLM. ouais Plusieurs raisons, une raison principale qui est la scalabilité, on a plusieurs milliers d’utilisateurs, on doit traiter beaucoup de requêtes sur des très très gros fichiers, donc les données sources qu’on traite c’est plusieurs milliers de lignes assez facilement, à peu près des 10 000 lignes, donc si on utilise des trop gros modèles ça va prendre un temps fou et ça va nous coûter beaucoup trop cher. Ensuite, la base de données de référence, des facteurs d’émission, elle évolue tous les jours. Il y a des fiches qui se rajoutent, des fiches qui s’enlèvent, des fiches qui se changent. Donc on doit refaire les entraînements régulièrement. Si on en a pour plusieurs milliers d’euros et plusieurs semaines d’entraînement à chaque fois, ce n’est pas possible non plus. Ensuite, on arrive à des bons résultats avec des petits modèles. Et donc ça, c’est plutôt le côté sobriété où ça ne sert à rien pour gagner 1% de faire quelque chose qui consomme beaucoup plus. 

Marc 00:17:10 – 00:17:17 : Alors des petits modèles, on parle de choses comme BERT, ce genre de modèles ? 

Anatole 00:17:17 – 00:17:23 : C’est ça, ce genre de modèles, en gros les modèles qui sont juste avant les modèles de LLM. 

Marc 00:17:23 – 00:17:28 : Est-ce que tu pourrais nous parler un petit peu de trucs et astuces côté fine tuning de petits modèles justement ? 

Anatole 00:17:28 – 00:18:40 : Oui, alors, comme on le discutait tout à l’heure, une des grandes difficultés qu’on a rencontrées, c’est le fait que les données ne sont pas équilibrées et qu’il y a des classes qui sont très surreprésentées, des classes très peu représentées. On a testé plusieurs méthodes, donc le fait de pondérer la loss directement, le fait de changer le sample. Au final, dans notre use case, c’est le fait de pondérer le sample qui a le mieux fonctionné, mais ça, j’imagine que ça dépend des use cases. Ensuite, on a testé tout un tas de méthodes pour améliorer l’entraînement. Typiquement, utiliser le fait qu’on a une arborescence. Il y a des méthodes assez intéressantes d’entraînement où on entraîne étage par étage. Il faut s’imaginer que dans son arbre, d’abord on entraîne sur les étages tout en haut. On apprend à distinguer tout ce qui correspond à la toiture versus la structure du bâtiment. Et puis ensuite, une fois qu’on a bien appris ça et qu’on a une très bonne accuracie là-dessus, on va descendre d’un étage et parmi la structure, apprendre à distinguer ce qui correspond à un mur versus à un plafond. Et puis ensuite, on redescend d’un étage et à la fin, on arrive tout en bas. Et ça fait qu’en fait, le learning peut, on va dire, accrocher, entre guillemets, et que les roues ne tournent pas à vide. Ce qui est un peu la difficulté qu’on avait au début avec beaucoup trop de classes, pas assez de données et où ça n’arrivait pas à apprendre du tout. 

Marc 00:18:42 – 00:18:57 : Du coup, ça veut dire que concrètement, votre réseau de neurones, sa dernière couche, c’est l’output, c’est les classes. Et vous démarrez avec un petit nombre de classes, puis vous changez toute la dernière couche pour mettre un plus grand nombre de classes. C’est ça, en gros ? 

Anatole 00:18:57 – 00:19:00 : Oui, c’est ça. On change exactement ça. 

Marc 00:19:00 – 00:19:05 : Vous perdez les poids de la dernière couche, mais ce n’est pas grave parce qu’ils vont être vite réappris ? 

Anatole 00:19:05 – 00:19:17 : Ce qui compte, c’est toute la partie embedding layer qui est capable de représenter notre data domain du mieux possible. Et le pure classifier qui est à la toute fin est beaucoup moins pertinent. 

Marc 00:19:18 – 00:19:22 : Alors qu’est-ce que l’IA générative change ou a changé pour vous ? 

Anatole 00:19:22 – 00:20:30 : L’IA générative n’a pas changé grand-chose d’un point de vue technique, parce qu’on avait déjà développé tout ce qu’on a développé à l’arrivée de ChatGPT, et comme je l’ai dit, on utilisait des modèles qui étaient plus petits. Donc bien sûr, on a testé, et avec les LLM, ça pose des grosses difficultés d’entraînement, ça prend un temps fou à entraîner, donc l’intérêt d’utiliser des LLM n’est pas évident. Ensuite, d’un point de vue plutôt business, il y a une vague IA générative, mais en fait, il y a une vague IA un peu plus large puisque tout le monde ne fait pas vraiment la différence entre les deux. Et de manière générale, nos clients, ils s’en fichent un peu qu’on utilise de l’IA. Ce qui les intéresse, c’est surtout la valeur qu’on peut leur apporter d’un point de vue  , c’est-à-dire… répondre aux trois besoins que j’exposais tout à l’heure et le fait d’acculturer l’ensemble de l’entreprise en permettant à des gens qui ne sont pas spécialistes de l’environnement, du bilan carbone, des acteurs du bâtiment, par exemple des architectes, des économistes de la construction, etc., de prendre en compte ces enjeux parce qu’en fait, ils ont une aide qui est à côté d’eux en permanence. L’état d’esprit, du coup, est un peu similaire à celui de l’IA générative dans le sens où on met de l’IA un peu sous la main de tout le monde. Seulement, nous, on n’a pas besoin de la partie générative. 

Marc 00:20:31 – 00:20:42 : Ok. Alors, qu’est-ce que tu dois beaucoup dire à tes interlocuteurs non tech en termes d’évangélisation ? Qu’est-ce que tu dois beaucoup répéter ? 

Anatole 00:20:42 – 00:21:37 : Ça dépend des gens. Il y a des gens qui sont très engagés par eux-mêmes sur le sujet, pas forcément des experts, mais qui ont envie d’avoir ces compétences, d’apprendre, surtout d’avoir la visibilité sur leurs projets pour prendre les bonnes décisions. Pour cela, le travail est assez direct, assez fluide de notre côté. Ensuite, il y a les gens que ça intéresse un peu moins. Là, ce qu’on essaie de leur montrer, c’est qu’on vient s’intégrer à fond dans leur métier on vient utiliser leurs données exactement comme ils ou elles les ont. ils n’ont absolument pas besoin de les retraiter. ce qui est une des peurs en général des gens c’est qu’il faut s’adapter à l’algorithme plutôt que c’est l’algorithme qui s’adapte à moi et ensuite simplement leur dire qu’aujourd’hui dans le secteur de la construction et en particulier du bâtiment on n’a pas le choix. on est obligé de prendre en compte ces enjeux. ça va être de plus en plus fort et donc de toute façon il va falloir en passer par là autant que ce soit le plus agréable possible. 

Marc 00:21:38 – 00:21:46 : Qu’est-ce que tu peux partager comme erreur avec nous pour qu’on ne les fasse pas et qu’on gagne du temps éventuellement sur des projets similaires ? 

Anatole 00:21:46 – 00:22:02 : Alors on a eu parfois un peu trop tendance à développer des fonctionnalités trop spécifiques à des clients. Je pense que c’est une erreur assez courante dans le milieu des startups un peu jeunes on va dire. 

Marc 00:22:02 – 00:22:03 : Comme quoi par exemple? 

Anatole 00:22:03 – 00:22:26 : ? Comme fonctionnalités ? Des fonctionnalités typiquement de visualisation qui sont spécifiques à une personne qui a un problème, voire même sur un projet. Et en fait, cette visualisation, elle s’en fiche pour le projet suivant. Et bon, on l’a lui fait parce qu’en fait, on ne s’en est pas vraiment rendu compte. Et ce n’est pas un drame, mais ça nous a coûté quelques jours de dev. Et puis, ça ajoute une fonctionnalité dans la plateforme qu’en fait, les gens ne vont pas vraiment utiliser. Ça, c’est une erreur qu’on a pu faire pas mal. Ok. 

Marc 00:22:28 – 00:22:44 : Quelle stratégie tu crois qu’il faut adopter ou quelle stratégie vous avez décidé d’adopter pour conquérir un marché comme celui-là, naissant d’une certaine façon, plutôt bottom-up, top-down ? Est-ce qu’on va chercher les grosses sociétés, les petites sociétés ? 

Anatole 00:22:44 – 00:23:32 : On a tenté les deux approches parce qu’on ne savait pas vraiment laquelle était la meilleure initialement. Au final, ce qui a fonctionné, c’est plutôt la stratégie top-down. de fait, sans qu’on ait réellement… Enfin, nous, on n’avait pas forcément une vision sur ce qui allait bien marcher initialement. La raison qu’on voit, c’est que déjà, les grosses sociétés ont des enjeux, on va dire RSE au sens très large, beaucoup plus forts que les plus petites. Et donc, elles étaient obligées de bouger sur ces sujets-là. Et puis ensuite, elles se parlent beaucoup entre elles et surtout, elles donnent des ordres à leurs prestataires, à leurs fournisseurs. Elles ont un rôle un peu de leader. Et donc, ça fait qu’une fois qu’on a convaincu quelques-unes des très grosses sociétés de construction, c’est beaucoup plus facile d’aller voir les petites et de leur dire, vous voyez, on travaille avec votre client. avec ce nom qui claque. 

Marc 00:23:32 – 00:23:35 : Ça a changé quelque chose d’être intégré à Aegis ? 

Anatole 00:23:35 – 00:23:53 : De ce point de vue-là, pas vraiment. En France, en tout cas, parce qu’on avait déjà comme clients Bouygues, Vinci, Aegis. Donc, on avait des grosses références. À l’international, pour le coup, oui, ça change des choses puisqu’on avait très peu de références internationales et Aegis est très reconnu à l’international. 

Marc 00:23:53 – 00:23:58 : Est-ce que tu as une anecdote à nous partager ? 

Anatole 00:23:58 – 00:24:46 : Oui, un peu la première fois qu’on a montré les slides de notre produit, c’était justement à Bouygues, le responsable outil climat de Bouygues. À ce moment-là, on avait des slides, on lui montre nos slides et il était beaucoup plus intéressé que ce qu’on espérait initialement. et du coup il nous a je crois quasiment au premier rendez-vous donné une date de ok si vous me fournissez cet outil. là à cette date là on lance un test grandeur nature et du coup à ce moment là forcément gros coup de chaud on rameute tous les devs qu’on a et puis on se lance un peu à corps perdu dans le truc. donc c’était c’était une bonne surprise et en même temps ça c’était une période un peu dure. 

Marc 00:24:47 – 00:24:51 : Oui, c’est la bonne dureté, ça. 

Anatole 00:24:51 – 00:25:08 : En fait, à postérieure, on se dit, si on n’avait pas eu cette date-là, on aurait pu continuer à faire nos petites fonctionnalités pas vraiment utiles. Ça nous a vachement aidé à recadrer la roadmap, à se concentrer sur les cinq fonctionnalités cœur qui allaient tout changer. Et puis ensuite, à avoir quelque chose à mettre dans les mains des gens. Et c’est là qu’on commence vraiment. 

Marc 00:25:08 – 00:25:10 : Tu as une opinion à nous partager ? 

Anatole 00:25:10 – 00:25:58 : Une crainte sur le fait que… C’est quelque chose qui me fait un peu plus peur à l’international qu’en France, où on certifie des projets, on garantit qu’ils respectent un certain nombre de seuils carbone, on propose un certain nombre d’optimisations, et puis on associe un peu notre nom au projet, en tout cas à l’impact carbone du projet. Et On sait qu’il y a certains pays où cette partie carbone sert plus à faire du greenwashing et plus à vendre plus cher leurs projets qu’à réellement essayer d’améliorer les choses. Il y a même des projets qui n’ont aucun sens, même s’ils étaient faits en émettant zéro carbone. Le principe du projet n’a en lui-même aucun sens et n’apporte absolument rien. Le fait d’être associé à ces projets-là, en tant que logiciel, on n’a pas notre mot à dire. On ne peut pas refuser un projet et nous rendre complices de greenwashing. C’est quelque chose qui nous inquiète un peu. 

Marc 00:25:59 – 00:26:06 : Oui, la frontière est fine entre la bonne volonté et le greenwashing aussi, donc ce n’est pas facile à déceler. 

Anatole 00:26:06 – 00:26:33 : C’est ça, et d’autant plus quand on est un logiciel et pas une entreprise de conseil, où en fait on n’a même pas la visibilité exacte sur les projets qui sont associés à SustainEco. Les gens qui ont des licences font leur calcul carbone pour leurs projets, pour les projets de leurs clients, et des fois on apprend que SustainEco a été utilisé pour tel projet. En France, tout se passe très bien. Mais il y a certains pays où il y a certains projets où ça ne va pas. 

Marc 00:26:33 – 00:26:37 : Quelles sont les prochaines étapes côté data et côté IA chez vous ? 

Anatole 00:26:37 – 00:26:56 : Donc les deux gros chantiers en cours, c’est l’internationalisation, la finalisation de l’internationalisation d’un côté et toute la partie ML Ops qui est en train de se monter de manière nécessaire. Et donc pour ça, forcément, agrandir l’équipe. On recrute en ce moment et puis structurer un peu le cadre qu’on a. 

Marc 00:26:56 – 00:27:08 : Ok. Écoutez, internalisation, dans vos process, ça se cahit le bien d’utiliser les données ? Est-ce qu’il y a vraiment des synergies entre les pays ou est-ce qu’il faut refaire le travail autant de fois qu’il y a de pays ? 

Anatole 00:27:08 – 00:27:37 : Il faut refaire le travail autant de fois qu’il y a de langue. L’intérêt, c’est qu’il y a beaucoup de pays qui travaillent en anglais. Et autant de fois qu’il y a de bases de données. Et là, pour le coup, quasiment chaque pays a sa base de données. Et puis après, il y a des pays qui ont plusieurs bases de données. Il y a des bases de données qui sont transverses sur plusieurs pays. Donc, notre vraie difficulté, elle est là sur comment est-ce qu’on scale au niveau des bases de données cibles. Est-ce qu’on fait un entraînement avec toutes les bases de données ? Un entraînement par base de données ? 

Marc 00:27:37 – 00:27:42 : Qui est-ce que tu souhaiterais entendre au micro de Data Driven 101 dans un prochain épisode ? 

Anatole 00:27:42 – 00:27:50 : J’ai deux sociétés, trois noms à te proposer. Kevin Briche de Ecofarm, Martin Noël et Binta Gassama de Locimo. 

Marc 00:27:50 – 00:27:52 : Entendu. Merci Anatole. 

Anatole 00:27:52 – 00:27:53 : Merci à toi. 

Marc 00:27:54 – 00:28:08 : Vous venez d’entendre Anatole Parre, cofondateur et CTO de Systemeco. Dans le prochain épisode, je recevrai Thomas Leca, Staff Research Engineer chez InstaDeep, pour nous parler d’applications industrielles de l’IA et du reinforcement learning en particulier dans les sciences de la vie. A très vite !