Inside Google Labs

Publié le 15 novembre 2006 et mis à jour le 18 août 2012 - 9 commentaires -
PDF Afficher une version imprimable de cet article
  

J’ai assisté récemment à une présentation d’Alice Bonhomme-Biais, une ingénieur française en développement logiciel chez Google. Elle était destinée à des élèves de l’option technologies de l’information de l’Ecole Centrale Paris où j’enseigne sur les Stratégies de l’Innovation.

 

 

En une heure, Alice a dressé un portrait fort intéressant de la manière dont le développement et les opérations fonctionnent chez Google.

En voici un apperçu, complété par un peu de lecture personnelle, avec tout d’abord quelques remarques générales:

  • Tout d’abord, Google a des labos de développement bien répartis dans le monde. Rien qu’en Europe, ils en ont un à Dublin où se trouve également un data center européen, un à Londres, un à Zurich et un autre à Trondheim, en Suède. Alice est elle-même basée à New York dans un autre labo. Donc, Google a beau être un classique succès de la Silicon Valley, basé à Mountain View, ils ont rapidement éclaté géographiquement leurs développements. C’est permis par une organisation du développement logiciel en petites équipes : de 2 à 10 personnes, et 5 en moyenne. Il y a d’un côté des services qui requièrent effectivement des équipes de cette taille, comme le Calendrier sur lequel travaille Alice Bonhomme-Biais. Et de l’autre, le gros du développement qui est orienté sur le search est lui-même découpé en autant de modules nécessitant des équipes de cette taille. L’éclatement géographique du développement répond à une logique de recrutement assez simple consistant à chercher les talents là où ils sont au lieu de leur proposer tous de déménager à Mountain View. Au passage, cela permet de contourner les limitations du nombre de visas pour l’entrée de travailleurs aux USA. C’est donc bien vu! Et certains éditeurs de logiciels pourraient s’en inspirer! Donc, Google continue de recruter à tour de bras et les ingénieurs français les intéressent, même s’il n’y a pas encore de labo de R&D en France même.
  • Le développement de nouveaux services est (serait?) piloté par les équipes produits, indépendamment de toute démarche marketing ou de modèle économique. Le point clé est de créer des services qui ont une grande valeur d’usage pour les utilisateurs et de générer du trafic. Une fois seulement usage et trafic générés se pose la question de la monétisation. Sachant qu’en plus, Google fait très peu de marketing de ses offres. Elles se diffusent en mode viral et grâce au trafic généré par le moteur lui-même. Ce découplage produit / marketing est sommes toutes encore plus fort que ce que j’ai constaté chez Microsoft Corp. Il est contre-intuitif pour ceux – comme moi – qui pensent que le marketing doit être impliqué le plus en amont possible de la création d’un produit pour assurer son alignement avec un besoin marché et avec un business qui tienne la route. Google peut éviter cette démarche pour un certain nombre de facteurs dont peu d’entreprises bénéficient: une marge énorme générée par le coeur de métier qui permet de financer (souvent à perte) de nombreux tests de nouveaux produits, le trafic généré par le site Google qui permet d’aspirer de nouveaux clients pour ces services, et un modèle de revenu indirect basé sur la publicité et la vente de mots clés qui permet de fournir des services gratuits au plus grand nombre.
  • Certains projets comme Gmail sont bien nés du fameux “20% de temps libre” pour des projets de son choix. Mais la part relative des nouveautés de Google qui en proviennent et celle qui est issue d’acquisitions n’est pas claire! La dernière étant assez conséquente en nombre de services mais pas forcément en effectifs de développement puisqu’il semble qu’une grosse part de la R&D de Google soit encore focalisée sur le coeur du métier: la recherche (voir “Innovation ou marketing?” un de mes posts du printemps dernier).

Nous avons dans cette conférence surtout fait le tour du coeur de métier de Google, le search. Qui est découpé en tranches:

  • Le crawlerqui scanne les sites Web pour y détecter tous les mots clés utilisés. Il s’appuie sur des milliers de serveur qui scannent de façon récursive tous les liens de toutes les pages de tous les sites Web détectés. Toutes les URL d’Internet ne peuvent être récupérées. Google s’aide de différents artifices, notamment des Sitemaps qui permettent aux sites d’informer Google de leur structure et de leur mise à jour.
  • L’indexqui pour chaque mot liste les pages et les positions dans les pages où on les trouve. Il fonctionne en mode multilingue et stocke également les informations de lieu et de temps sur les pages indexées. Le lieu s’identifie probablement via l’adresse IP des sites. Il y plusieurs copies de l’index réparties géographiquement et elles tiennent toutes en RAM sur les serveurs. En 2006, Google indexerait environ trois fois plus de pages que ses principaux concurrents (donc: Yahoo et Microsoft). Ils indexent aussi 2 milliards d’image, 35 millions de documents non HTML et un milliard de messages UseNet. L’ensemble fait des Teraoctets, bien évidemment. L’indexation d’une nouvelle page qui apparait sur Internet prend entre 15 minutes et quelques heures selon l’importance et le trafic du site.
  • Le ranking des mots, PageRank, qui évalue la pertinence des pages liées à la combinaison de mots clés d’une recherche en fonction de différents critères, notamment le nombre des liens qui aboutissent à cette page, et la position des mots dans les pages. Pourquoi les sites de commerce arrivent-ils presque toujours au début des résultats lorsque l’on recherche un produit? Ce ne serait pas lié à de la vente de placement, mais à une bonne optimisation de ces sites qui connaissent bien le fonctionnement de PageRank. La force de PageRank, c’est d’exploiter la mine d’or générée par l’index et par l’usage. Tout repose sur des analyses statistiques.
  • L’affichage, tout ce qui relève de la présentation des résultats dans un navigateur Web, et l’intégration des autres composants de nature publicitaire dans les pages. Pour tester les évolutions de son interface, Google dispose d’un “usability lab” à l’échelle planétaire. Ils “servent” les nouveautés à tester à un faible pourcentage de leurs utilisateurs (genre 1%), mais qui suffit à en avoir des millions, et ils comparent les résultats: temps passé dans la recherche, taux de clic, etc. Souvent, une modification mineure ne serait-ce que d’un seul pixel d’interlignage peut avoir des répercussions significatives. La force du nombre leur apporte des données statistiques extraordinaires. Quant au “spell check” de Google qui propose une orthographe différente aux termes recherché, il s’appuie lui-aussi sur des statistiques et non pas sur un dictionnaire travaillant sur la distance des mots, approche trop limitée pour la gestion des noms propres. Ils s’appuient donc sur des algorithmes de probabilité de concomittance (probabilistic co-occurrence)! Une simple recherche sur Google génère côté serveurs la lecture de plusieurs centaines de Mo de données et le site en reçoit des milliers par seconde!

L’architecture serveur s’appuie sur quelques caractéristiques originales et maison qui font des labos de Google une sorte de véritable laboratoire de R&D de système d’exploitation et de middleware réseau et de gestion de données distribués:

  • Les racks de serveur sont bâtis sur une architecture physique optimisant leur remplacement ainsi que celui des disques durs: au lieu de vis pour les fixations, ils utilisent du Velcro ! En effet, sur 5000 machines environ par data center, il y a régulièrement une dizaine de pannes par jour. Donc, cela fait gagner du temps. Ces serveurs sont des lames standard de type PC tournant sous Linux. Ce sont des machines “peu fiables” aux diresde Google, mais peu importe, c’est l’architecture logicielle qui apporte la fiabilité à l’ensemble. Ce ne sont pas les machines les plus puissantes du moment, mais celles qui apportent le meilleur rapport puissance/prix du moment. Les racks ont 40 à 80 serveurs chacun, connectés entre eux en 100 mbits/s, le rack étant lui-même en liaison Gigabit avec les autres. Chaque serveur a une durée de vie de 2 à 3 ans. L’alimentation électrique et le refroidissement de ces racks sont des défis de taille à eux seuls qui entrainent moutle calculs techniques et économiques pour optimiser l’ensemble, la facture d’électricité de Google étant l’une de ses plus grosses charges d’exploitation!
  • Il y a plusieurs clustersd’environ 5000 serveurs répartis dans le monde entier, ce qui apporte une forte tolérance aux pannes de réseau sur Internet. La répartition de charge s’effectue au niveau DNS pour identifier le cluster le plus proche de l’utilisateur au niveau temps de latence réseau.
  • Google s’est créé son propre système de gestion de fichiers distribué, qui tourne sous Linux: le Google File System. Il distribue les recherches de fichiers sur plusieurs serveurs de façon extrêmement efficace. C’est un peu grâce à lui que le résultat d’une recherche aboutit dans notre navigateur en quelques millisecondes de traitement.
  • GFS est complété par BigTable, une sorte de base de données hiérarchique (donc non relationnelle) scalable pour la gestion de gros volumes de données qui doivent être accédés très rapidement. Cela sert notamment à Google Analytics (l’outil d’analyse du trafic sur son propre site Web où l’on a placé de la publicité Google AdSense, 200 teraoctets de données rien que pour le stockage des clicks sur les sites abonnés au service), Google Earth et à Personnalize Search, une fonction méconnue qui personnalise les résultats de la recherche pour les utilisateurs qui sont identifiés sur le moteur de recherche par un logon, le logon commun à Gmail et autres services personnels de Google.
  • Ils ont défini leur propre architecture de parallélisation des traitements avec le Global Work Queue et MapReduce qui permet de découper un traitement en morceaux. MapReduce est utilisé au travers d’un langage de programmation maison Sawzall. Au passage, l’architecture de Google bénéficie donc à plein des nouveaux processeurs à hyperthreading et multi-coeurs qui permettent de paralléliser les traitements sur une même machine.

Nombre de ces aspects sont documentés dans des publications scientifiques des Google Labs disponibles sur leur site : http://labs.google.com/papers/. Ce domaine est passionnant et on pourrait y passer des heures pour décortiquer son fonctionnement. Certaines sociétés de service en ont d’ailleurs fait leur métier pour aider les sites Web à bien se faire référencer sur Internet! Il sera aussi intéressant de voir documenter la gestion des vidéos maintenant qu’il ne s’agit plus que de les indexer avec Google Video, mais également de les stocker et de les diffuser, via YouTube!

Comparaison inévitable avec Microsoft. L’éditeur a également une grande tradition de publication de travaux scientifiques, notamment par le truchement du site de Microsoft Research. Mais la partie du site qui relève du search évoque la création d’un laboratoire commun sur le search avec MSN en Chine, mais rien de plus. Et cela ne concerne pas ce qui est en exploitation comme Google. La partie est difficile pour Microsoft car rattraper le savoir faire de Google, quand on se plonge dedans, est loin d’être évident. Microsoft parie surtout sur des évolutions d’interface comme pour la recherche de photos présentée de façon sympathique avec la possibilité de choisir la taille des “thumbnails”. Mais c’est loin d’être suffisant pour faire la différence. C’est un sujet à creuser car le manque d’informations de la part de Microsoft ne veut pas dire qu’ils sont inactifs en R&D sur le search, loin s’en faut!

J’évoquais au début cette marge énorme de Google lui permettant de financer des tests de services sans se soucier trop de logique économique au départ. Google “crache” en effet aujourd’hui une profitabilité nette de 27%, soit celle la moyenne de celle de Microsoft ces dernières années. Soient presque $3B pour 2006, extrapolés des $2046m sur les 9 derniers mois. Leur bilan en octobre 2006 comprenait environ $10B de cash disponible. Mais tout ceci, c’est le profit et le cash générés après les dépenses en R&D, en infrastructure et en acquisitions évoquées dans cet article! Ils ont donc un sacré mou pour prendre des risques. C’est le grand privilège des numéro un dont la taille critique leur permet d’absorber la valeur de leur secteur!

Alice Bonhomme faisait cette conférence aux élèves centraliens dans le cadre de ses 20% de temps consacré à des projets libres de son choix. Car Google recrute à tour de bras pour supporter sa croissance qui n’en finit pas. Mais elle a oublié de citer le bénéfice du “free lunch” à ces recrues potentielles. Car chez Google, c’est boisson et repas gratuits, en plus du plaisir de pouvoir venir travailler accoutré comme bon vous semble! Tout du moins dans les labs… :).

Ce post faisait lui aussi partie de mon “20% de temps libre”… pour de la veille technlologique!

RRR

 
S
S
S
S
S
S
S
img
img
img

Publié le 15 novembre 2006 et mis à jour le 18 août 2012 Post de | Google, Internet, Microsoft, Technologie | 18893 lectures

PDF Afficher une version imprimable de cet article     

Reçevez par email les alertes de parution de nouveaux articles :


 

RRR

 
S
S
S
S
S
S
S
img
img
img

Les 9 commentaires et tweets sur “Inside Google Labs” :

  • [1] - Jeremy Fain a écrit le 15 novembre 2006 :

    Bonsoir Olivier,

    Bravo et merci d’avoir eu le courage de retranscrire cette session très intéressante. Avoir accès à des gens de Google qui parlent de Google est suffisamment rare pour être souligné, voire fêté.

    J’ai beaucoup aimé la dernière phrase de votre “L’éclatement géographique du développement répond à une logique de recrutement assez simple consistant à chercher les talents là où ils sont au lieu de leur proposer tous de déménager à Mountain View. Au passage, cela permet de contourner les limitations du nombre de visas pour l’entrée de travailleurs aux USA. C’est donc bien vu! Et certains éditeurs de logiciels pourraient s’en inspirer!”));

    Si vous le permettez, je souhaiterais compléter votre très exhaustif compte-rendu par deux points qui m’ont paru importants:

    1) le fait que les équipes projets soient formées d’ingénieurs purs et durs; sans ‘project manager’, sans réelle hiérarchisation. C’est à mon avis très bénéfique pour le nombre de projets en incubation, et ça favorise certainement l’homogénéisation vers le haut des pratiques de développement logiciel. Maintenant, j’y vois un élément négatif majeur: combien y a-t-il de projets appelés pour combien d’élus? Si Google s’est inspiré des méthodes d’autres éditeurs de logiciels, alors ce n’était pas une best practice à retirer. Il faut bien à un moment que le client dicte sa loi, que les ingénieurs répondent à un réel besoin de niche ou de masse. Sinon la plupart des projets sont condamnés à rester dans des placards, ou à devenir des logiciels de geeks pour geeks.

    2) ça peut paraître complètement symbolique et futile, mais chez Google, les marketeurs sont tous “Sales Engineers” et les ingénieurs tous “Software Engineers”. Ca me fait toujours marrer, par exemple dans les banques de voir les titres des gens dans les sociétés. Au moins chez Google, et je trouve ça vraiment très positif, tout le monde est logé à la même enseigne et l’entreprise peut vraiment se proclamer méritocratiques.

    Voilà, c’était ma maigre contribution à votre magnifique post. Et puis j’oubliais: le t-shirt Google éveille pas mal la curiosité (j’ai eu l’occasion de le porter en jouant au foot, je ne vous raconte pas les plaisanteries à chaque fois que mes passes ne trouvaient pas preneur).

  • [2] - Olivier Ezratty a écrit le 16 novembre 2006 :

    Sur le 1), cela m’étonnerait que Google fonctionne entièrement sur le modèle de l’autogestion. Il est probable que le modèle s’inspire de certains modes de fonctionnement du développement de logiciels libres. Même s’il n’y a pas forcément formellement de project managers, il doit certainement y avoir dans chaque équipe quelqu’un qui par sa séniorité et son charisme joue ce rôle tacitement. Tout groupe de travail autogéré génère sa propre méritocratie, au minimum.

    Et oui, le fait que les ingénieurs travaillent sans lien direct avec le client ou approche marketing peut choquer. Ceci étant, ils sont directement reliés aux clients et peuvent tester en temps réel leur approche. Il serait bon de creuser le modèle d’évaluation des collaborateurs de Google pour mieux comprendre cela.

    Ce qui me tracasse, et il y a un “pattern” voisin à celui de Microsoft, c’est effectivement la capacité à lancer des projets indépendamment de toute logique économique. L’ensemble étant financé par la ou les vaches à lait de la société. Ce n’est pas forcément une bonne discipline d’un point de vue business. Mais comme le nom de la R&D de Google l’indique (Google Labs), Google est peut-être le premier laboratoire de R&D directement connecté à son marché et largement autofinancé qui existe en informatique!

    Sur le 2), le titre de “Sales Engineer” semble aligné sur “Sofware Engineer”, fine. Mais en France, dans les boites d’informatique qui font du btob, on dit bien “Ingénieur d’Affaire” au lieu de “Commercial”. C’est du pareil au même! Et ces commerciaux sont sommes toutes assez classiques :q ils vendent de l’espace au kilo à des annonceurs.

  • [3] - Jeremy Fain a écrit le 16 novembre 2006 :

    J’avais effectivement posé la question sur le 1); l’un des membres de l’équipe joue le rôle d’interface avec le monde extérieur, mais ce n’est pas forcément le plus expérimenté ni le plus charismatique.

    Sur le 2): certes pour le commercial, mais dans les SSII, on commence ‘ingénieur d’affaires’, puis on est ‘gestionnaire de grand-compte’ (ex. responsable des ventes Carrefour), puis directeur d’agence, puis…Le titre en était presque devenu un moyen de rétribution. Chez Google, du junior sales au VP Sales, tout le monde est Sales Engineer sans passer par les cases junior ou VP. Et je trouve ça plutôt sain, mais ce n’est que mon humble avis.

  • [4] - Olivier Ezratty a écrit le 16 novembre 2006 :

    Il y a quand même des Vice President chez Google! Il ne faut pas croire qu’une boite de cette taille (bientôt 10 milliards de $) puisse s’en passer.

    Cf http://www.google.com/corporate/execs.html qui liste leurs VP et Exec VP.

  • [5] - Jeremy Fain a écrit le 16 novembre 2006 :

    Bien sûr, j’épaississais le trait…

  • [6] - Lim C a écrit le 5 décembre 2006 :

    Ce n’est pas exactement ça, même si la boite est orientée ‘Engineers’ et reste une boite technologique, il y a quand même une fonction Marketing, une fonction Sales, etc. Les revenus restent des revenus publicitaires. Tout le monde n’est pas Sales Engineer ou Software Engineer 😉
    Je n’ai pas pu assister à cette conférence que j’avais contribuée à organiser, mais ce compte-rendu est excellent. Merci Olivier !

  • [7] - Olivier Ezratty a écrit le 5 décembre 2006 :

    Il y a effectivement du sales, mais avec une caractéristique propre au modèle économique de nombreux sites web: la vente ne consiste pas à commercialiser le produit final aux utilisateurs, mais de l’espace publicitaire à des annonceurs. Par contre, le marketing, assez discret et donc certainement efficace, contribue à générer de l’usage chez les internautes.

  • [8] - Jeremy Fain a écrit le 5 décembre 2006 :

    Bonjour Limvirak! Vous blogger? Quelle bonne surprise. Bravo si vous aviez co-organisé la conférence, c’était tout à fait éclairant. J’ai beaucoup rit à la lecture de “Je bosse dans une start-up qui a bien grandi” sur votre blog…)))

  • [9] - David Aubespin a écrit le 8 décembre 2006 :

    Juste pour clarifier. Le titre de Sales Engineer est loin d’etre le titre par defaut a Google et pour tout dire, il n’y en a que tres peu. Les titres sont un peu les memes que dans toutes les autres compagnies, et il y a de meme plusieurs niveaux parmi les Sales Engineers. A ce propos, et si vous etes interesses par cette position, n’hesitez pas!
    http://www.google.com/support/jobs/bin/answer.py?answer=46403




Ajouter un commentaire

Vous pouvez utiliser ces tags dans vos commentaires :<a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong> , sachant qu'une prévisualisation de votre commentaire est disponible en bas de page après le captcha.

Last posts / derniers articles

Free downloads

Understanding Quantum Technologies 2024, a free 1,554 pages ebook about all quantum technologies (computing, telecommunications, cryptography, sensing):

image

Understanding Quantum Technologies 2024 Short version, a 26 pages version with key takeaways from the eponymous book.

image

The Two-Spin Enigma: From the Helium Atom to Quantum Ontology, a quantum foundations paper coauthored with Philippe Grangier, Alexia Auffèves, Nayla Farouki and Mathias Van den Bossche (paper backstory).
image

Voir aussi la liste complète des publications de ce blog.

Derniers commentaires

“Bravo Olivier! Quel boulot tu m’épates totalement et je t’adresse mes plus sincères félicitations! Je ne suis pas sûr de tout lire car je suis maintenant 100% dans l’art et la poésie et mon seul rapport à la...”
“[…] to Olivier Ezratty, author of Understanding quantum technologies 2023, the challenge for Europe is to position itself outside of where the US and China are likely end up...”
“Désolé, je suis passé à l'anglais en 2021 sans revenir au français. Traduire un tel ouvrage (1366) pages d'une langue à l'autre est un travail herculéen, même avec des outils de traduction automatique. Sachant...”
“Je suis un artiste conceptuel, certes je garde la grande majorité de mon travail dans ma tête par défaut d'un grand mécène. Mon travail de base se situe sur le "mimétisme" qui mène aux itérations et de nombreux...”
“Better than a Harry Potter! Thanks Olivier...”

Abonnement email

Pour recevoir par email les alertes de parution de nouveaux articles :


 

RRR

 
S
S
S
S
S
S
S
img
img
img

Derniers albums photos

Depuis juillet 2014, mes photos sont maintenant intégrées dans ce site sous la forme d'albums consultables dans le plugin "Photo-Folders". Voici les derniers albums publiés ou mis à jour. Cliquez sur les vignettes pour accéder aux albums.
albth
QFDN
Expo
791 photos
albth
Remise Légion d'Honneur Philippe Herbert Jul2021
2021
15 photos
albth
Vivatech Jun2021
2021
120 photos
albth
Visite C2N Palaiseau Mar2021
2021
17 photos
albth
Annonce Stratégie Quantique C2N Jan2021
2021
137 photos
albth
Maison Bergès Jul2020
2020
54 photos
albth
Grenoble Jul2020
2020
22 photos

image

Avec Marie-Anne Magnac, j'ai lancé #QFDN, l'initiative de valorisation de femmes du numérique par la photo. Elle circule dans différentes manifestations. J'ai réalisé entre 2011 et mi 2023 plus de 800 portraits photographiques de femmes du numérique avec une représentation de tous les métiers du numérique.

Les photos et les bios de ces femmes du numérique sont présentées au complet sur le site QFDN ! Vous pouvez aussi visualiser les derniers portraits publiés sur mon propre site photo. Et ci-dessous, les 16 derniers par date de prise de vue, les vignettes étant cliquables.
flow
Gaëlle Rannou
Gaëlle est étudiante à 42 Paris et tutrice de l’équipe pédagogique (en 2021).
flow
Jehanne Dussert
Jehanne est étudiante à l'école 42, membre d'AI For Tomorrow et d'Open Law, le Droit ouvert. Elle est aussi fondatrice de "Comprendre l'endométriose", un chatbot informant sur cette maladie qui touche une personne menstruée sur 10, disponible sur Messenger. #entrepreneuse #juridique #santé
flow
Chloé Hermary
Chloé est fondatrice d'Ada Tech School, une école d'informatique alternative et inclusive dont la mission est de former une nouvelle génération de talents diversifié à avoir un impact sur le monde. #entrepreneuse #formation
flow
Anna Minguzzi
Anna est Directrice de Recherche au CNRS au Laboratoire de Physique et Modélisation des Milieux Condensés (LPMMC) à Grenoble. #quantique
flow
Maeliza Seymour
Maeliza est CEO et co-fondatrice de CodistAI, qui permet de créer une documentation du code informatique par une IA.
flow
Candice Thomas
Candice est ingénieure-chercheuse au CEA-Leti, travaillant sur l’intégration 3D de bits quantiques au sein du projet Quantum Silicon Grenoble. #recherche #quantique
flow
Stéphanie Robinet
Stéphanie dirige un laboratoire de conception intégrée de circuits électroniques du CEA-Leti qui travaille sur des systèmes sur puces intégrés, des interfaces de capteurs, des interfaces de contrôle de qubits et de la gestion intégrée de l'énergie. #recherche #quantique
flow
Sabine Keravel
Sabine est responsable du business development pour l’informatique quantique chez Atos. #quantique #IT
flow
Céline Castadot
Céline est HPC, AI and Quantum strategic project manager chez Atos.
flow
Léa Bresque
Léa est doctorante, en thèse à l'institut Néel du CNRS en thermodynamique quantique, sous la direction d'Alexia Auffèves (en 2021). #quantique #recherche
flow
Emeline Parizel
Emeline est chef de projet web et facilitatrice graphique chez Klee Group, co-fondatrice TEDxMontrouge, gribouilleuse à ses heures perdues, joue dans une troupe de comédie musicale, co-animatrice de meetups et est sensible à l’art et à la culture. #création
flow
Elvira Shishenina
Elvira est Quantum Computing lead chez BMW ainsi que présidente de QuantX, l'association des polytechniciens du quantique. #quantique
flow
Marie-Noëlle Semeria
Marie-Noëlle est Chief Technology Officer pour le Groupe Total après avoir dirigé le CEA-Leti à Grenoble. #recherche
flow
Gwendolyn Garan
Gwendolyn est travailleuse indépendante, Game UX Designer, Game UX Researcher (GUR) et 2D Artist pour le jeu vidéo, étudiante en Master 2 Sciences du Jeu, speaker et Formatrice sur l'autisme et la neurodiversité, l'accessibilité et les systèmes de représentation dans les jeux vidéo. #création #jeuvidéo
flow
Alexandra Ferreol
Alexandra est étudiante d'un bachelor Game Design à L'Institut Supérieur des Arts Appliqués (année scolaire 2019/2020) #création #jeuvidéo
flow
Ann-elfig Turpin
Ann-elfig est étudiante en deuxième année à Lisaa Paris Jeux Vidéos (Technical artist, 3D artiste), année scolaire 2019/2020. #création #jeuvidéo