{"id":2749,"date":"2014-04-02T16:08:53","date_gmt":"2014-04-02T16:08:53","guid":{"rendered":"http:\/\/kasperskydaily.com\/france\/?p=2749"},"modified":"2020-02-26T15:46:46","modified_gmt":"2020-02-26T15:46:46","slug":"la-creation-de-kaspersky-anti-virus-6-0","status":"publish","type":"post","link":"https:\/\/www.kaspersky.fr\/blog\/la-creation-de-kaspersky-anti-virus-6-0\/2749\/","title":{"rendered":"La cr\u00e9ation de Kaspersky Anti-Virus 6.0"},"content":{"rendered":"

L\u2019un des moments essentiels qui a permis \u00e0 Kaspersky Lab d\u2019acqu\u00e9rir une renomm\u00e9e internationale dans le secteur de la s\u00e9curit\u00e9 fut la sortie du produit r\u00e9volutionnaire Kaspersky Anti-Virus 6.0<\/a>. Officiellement lanc\u00e9 en 2006, le produit fut un v\u00e9ritable succ\u00e8s sur le march\u00e9 international des antivirus, et a permis d\u2019\u00e9tablir Kaspersky comme un leader en mati\u00e8re de technologies pour les ann\u00e9es \u00e0 venir. Dire que le produit est la meilleure solution au monde<\/a> ne serait pas tr\u00e8s modeste, mais c\u2019est ce que de nombreux magazines et entit\u00e9s ind\u00e9pendantes<\/a> ont d\u00e9clar\u00e9.<\/p>\n

La route vers le succ\u00e8s n\u2019a pas \u00e9t\u00e9 de tout repos \u2013 et peut-\u00eatre qu\u2019un jour un sc\u00e9nariste d\u2019Hollywood reprendra cette histoire, mais en attendant, nous essaierons de partager notre succ\u00e8s avec vous en vous montrant des photos, des notes et des souvenirs provenant de l\u2019\u00e9quipe de d\u00e9veloppeurs originale. Nous esp\u00e9rons que cette histoire servira d\u2019exemple aux jeunes d\u00e9veloppeurs qui cr\u00e9ent de nos jours de nouvelles applications et services \u2013 s\u2019ils souhaitent devenir les meilleurs, comme les cr\u00e9ateurs de \u00ab\u00a0Six\u00a0\u00bb.<\/p>\n

\"coreteam\"<\/a>

Une c\u00e9l\u00e8bre photo faite le jour du lancement de la version \u00a0\u00bb Six \u00ab\u00a0<\/p><\/div>\n

Probl\u00e8mes en 2003<\/b><\/p>\n

Le succ\u00e8s de \u00a0\u00bb Six \u00a0\u00bb trouve son origine dans la catastrophe que fut la version pr\u00e9c\u00e9dente. Cette cinqui\u00e8me version n\u2019a d\u2019ailleurs jamais vu le jour.<\/p>\n

Pour comprendre l\u2019essence de la catastrophe, nous devons retourner en 2002 : Windows XP venait alors \u00e0 peine de sortir, les CPU \u00e9taient enfin capables d\u2019atteindre une fr\u00e9quence d\u2019horloge de 1GHz et la tr\u00e8s jeune industrie antivirus devait encore d\u00e9couvrir toute une vari\u00e9t\u00e9 de menaces. Toutes les soci\u00e9t\u00e9s antivirus ont alors \u00e9tendu les capacit\u00e9s de leurs produits : \u00e0 l\u2019\u00e9poque, une solution comp\u00e9titive devait inclure un pare-feu, une surveillance constante des fichiers syst\u00e8mes et des douzaines d\u2019autres fonctionnalit\u00e9s.<\/p>\n

Apr\u00e8s avoir construit un puissant moteur d\u2019analyse dans les ann\u00e9es 1990, l\u2019\u00e9quipe de d\u00e9veloppement de Kaspersky Lab a admis qu\u2019ajouter toute une s\u00e9rie de fonctionnalit\u00e9s \u00e0 la solution la rendrait extr\u00eamement lente \u2013 m\u00eame le V4.0 de l\u2019\u00e9poque \u00e9tait d\u00e9j\u00e0 condamn\u00e9 par les utilisateurs (il y avait \u00e0 l\u2019\u00e9poque toutes sortes d\u2019all\u00e9gations affirmant que le produit de Kaspersky \u00e9tait lent). C\u2019est la raison pour laquelle le processus de d\u00e9veloppement du nouveau V5.0 a \u00e9t\u00e9 approch\u00e9 avec beaucoup de pr\u00e9cautions, en consid\u00e9rant seulement les \u00e9l\u00e9ments essentiels : un nouveau responsable des technologies a \u00e9t\u00e9 d\u00e9sign\u00e9, une nouvelle structure de d\u00e9veloppement a \u00e9t\u00e9 employ\u00e9e et une nouvelle architecture antivirus a \u00e9t\u00e9 choisie.<\/p>\n

La soci\u00e9t\u00e9 a utilis\u00e9 toutes ses ressources pour supporter le projet. Malgr\u00e9 cela, rien ne garantissait que dans un an, toutes ces nouvelles r\u00e8gles de d\u00e9veloppement permettraient de cr\u00e9er un produit comp\u00e9titif. Le syst\u00e8me cr\u00e9\u00e9 qui reprenait les applications client-serveur de niveau professionnel (une architecture choisie par le responsable des technologies) n\u2019\u00e9tait pas capable de r\u00e9pondre aux exigences des produits antivirus sur le march\u00e9. Il \u00e9tait lent et lourd et le nombre de bugs ne cessait de s\u2019accroitre alors que l\u2019\u00e9quipe testait le produit.<\/p>\n

\u00a0\u00bb J\u2019ai commenc\u00e9 \u00e0 demander aux gens, aux v\u00e9t\u00e9rans de la soci\u00e9t\u00e9, ce qu\u2019ils pensaient. Ils ont dit que tout se jouait dans l\u2019architecture. C\u2019\u00e9tait comme un ch\u00e2teau de cartes : en fixant un c\u00f4t\u00e9, vous d\u00e9truisez tout le ch\u00e2teau \u00a0\u00bb a admis Eug\u00e8ne Kaspersky. Il ne servait donc \u00e0 rien de continuer avec le projet tel qu\u2019il \u00e9tait. Il devait \u00eatre compl\u00e8tement d\u00e9moli et reconstruit \u00e0 partir de z\u00e9ro.<\/p>\n

Nous pouvons le faire !<\/b><\/p>\n

L\u2019\u00e9quipe de d\u00e9veloppement de Kaspersky Lab s\u2019est divis\u00e9e en deux groupes : l\u2019un \u00e9prouvait des difficult\u00e9s \u00e0 r\u00e9parer le produit \u00e0 cause de sa mauvaise architecture, et l\u2019autre se chargeait de sortir le V4.0 dans un nouveau produit.<\/p>\n

Au m\u00eame moment, un groupe de quatre a d\u00e9cid\u00e9 de cr\u00e9er un tout nouveau produit qui ne respectait pas seulement les exigences du march\u00e9 mais qui r\u00e9sisterait \u00e9galement aux exigences futures. L\u2019objectif, qui avait \u00e9t\u00e9 fix\u00e9 par l\u2019\u00e9quipe de d\u00e9veloppement \u00a0\u00bb Six \u00ab\u00a0, \u00e9tait simple \u00e0 expliquer mais difficile \u00e0 atteindre. La nouvelle version devait emp\u00eacher tous les virus et les menaces de s\u2019infiltrer dans le syst\u00e8me, elle devait \u00eatre rapide, agile et transparente, et\u2026 elle devait \u00eatre attrayante.<\/p>\n

\u00a0\u00bb Nous voulions juste cr\u00e9er le meilleur produit de tous les temps \u00ab\u00a0, se souvient l\u2019\u00e9quipe de d\u00e9veloppeurs \u00a0\u00bb Six \u00ab\u00a0. Une tr\u00e8s petite \u00e9quipe confront\u00e9e \u00e0 une t\u00e2che monumentale : c\u2019est comme cela que les 200 autres employ\u00e9s la consid\u00e9raient. La petite \u00e9quipe avait n\u00e9anmoins de bonnes raisons d\u2019\u00eatre optimiste : les fondateurs de la soci\u00e9t\u00e9, Eug\u00e8ne Kaspersky et Alexey De-Monderik, cherchaient \u00e0 l\u2019\u00e9poque de nouvelles alternatives d\u2019architecture \u2013 et ils allaient bient\u00f4t d\u00e9couvrir qu\u2019une alternative existait et celle-ci a \u00e9t\u00e9 invent\u00e9e par l\u2019\u00e9quipe de Kaspersky Lab elle-m\u00eame.<\/p>\n

De l\u2019aide en provenance de Prague<\/b><\/p>\n

\"Prague-1024x682\"<\/a><\/p>\n

Il est important de mentionner que deux noyaux antivirus (aussi appel\u00e9s \u00a0\u00bb moteurs \u00ab\u00a0) fonctionnaient d\u00e9j\u00e0 dans un paquet inclus dans V4.0. La v\u00e9rification des fichiers \u00e9tait r\u00e9alis\u00e9e par l\u2019ancien mais encore tr\u00e8s capable (et massivement support\u00e9 par des entreprises internationales telles que G-Data et F-Secure) moteur V3.0 d\u00e9velopp\u00e9 en 1996. La nouvelle t\u00e2che de r\u00e9aliser la filtration du trafic Internet \u00e9tait g\u00e9r\u00e9e par le puissant nouveau m\u00e9canisme qui avait \u00e9t\u00e9 con\u00e7u lors d\u2019une session de brainstorming \u00e0 Prague en 1998.<\/p>\n

Le moteur a fini par \u00eatre surnomm\u00e9 \u00a0\u00bb Prague \u00ab\u00a0, bien qu\u2019il ait \u00e9t\u00e9 d\u00e9velopp\u00e9 \u00e0 Moscou par Andrey Doukhvalov qui n\u2019\u00e9tait pas pr\u00e9sent lors de la session de brainstorming dans la capitale tch\u00e8que. Les id\u00e9es cl\u00e9s trouvent n\u00e9anmoins leurs origines \u00e0 Prague et Andrey a rejoint l\u2019entreprise pour compl\u00e9ter ces id\u00e9es et faire que Prague voit le jour.<\/p>\n

Prague \u00e9tait cens\u00e9 devenir un noyau antivirus mais les objectifs pr\u00e9vus pour ce dernier \u00e9taient tellement ambitieux que la flexibilit\u00e9 et l\u2019ing\u00e9niosit\u00e9 du nouveau moteur furent suffisantes pour faire fonctionner les syst\u00e8mes les plus complexes. La question de savoir s\u2019il \u00e9tait possible de cr\u00e9er la totalit\u00e9 du produit<\/b> \u00e0 partir de Prague inqui\u00e9tait Eug\u00e8ne Kaspersky alors qu\u2019il parlait avec les d\u00e9veloppeurs. Il se souvient :<\/p>\n

\u00a0\u00bb Une fois, j\u2019ai demand\u00e9 \u00e0 Victor Matyushenko comment Prague s\u2019en sortait \u00e0 l\u2019int\u00e9rieur du produit, et il m\u2019a r\u00e9pondu qu\u2019il \u00e9tait \u00a0\u00bb solide comme un roc ! \u00ab\u00a0. Ce fut le point d\u00e9cisif. J\u2019ai ensuite formul\u00e9 ma question. Je suis rentr\u00e9 dans la pi\u00e8ce o\u00f9 Graf (De-Monderik) et Petrovich (Doukhanalov) travaillaient et je leur ai pos\u00e9 la question suivante : \u00a0\u00bb Pourquoi ne basons-nous pas enti\u00e8rement le produit sur Prague ? \u00ab\u00a0. Graf a r\u00e9pondu quelque chose comme \u00a0\u00bb impossible, Prague n\u2019est pas fait pour \u00e7a \u00ab\u00a0, mais Petrovich a h\u00e9sit\u00e9. Le matin suivant, il est arriv\u00e9 \u00e0 notre bureau avec un petit tas de feuilles et il m\u2019a dit : \u00a0\u00bb Tu sais, j\u2019ai cod\u00e9 certains cas d\u2019utilisation sur Prague. \u00a0\u00bb Graf l\u2019a regard\u00e9 et a dit : \u00a0\u00bb nous devons avoir une discussion \u00ab\u00a0. Ensuite, apr\u00e8s en avoir parl\u00e9, ils sont revenus me voir et m\u2019ont confirm\u00e9 que cela valait la peine d\u2019essayer. \u00a0\u00bb<\/p>\n

L\u2019essai a commenc\u00e9 avec une \u00e9quipe tr\u00e8s restreinte qui a \u00e9crit les premi\u00e8res lignes de code qui deviendraient plus tard la version \u00a0\u00bb Six \u00ab\u00a0.<\/p>\n

\u00a0\u00bb Nous avons commenc\u00e9 \u00e0 chercher des personnes cr\u00e9atives qui pourraient contribuer et nous avons r\u00e9uni une \u00e9quipe importante \u00ab\u00a0, se souvient De-Monderik. \u00a0\u00bb Prenez, par exemple, Pavel Mezhuev, c\u2019\u00e9tait un codeur novice mais il \u00e9tait brillant. Il y avait \u00e9galement Mike Pavlyuschik avec qui nous travaillions depuis longtemps. Il \u00e9tait capable de trouver des id\u00e9es et des concepts originaux. Pour moi, il s\u2019agissait de l\u2019un des cr\u00e9ateurs les plus talentueux et les plus appliqu\u00e9s de l\u2019industrie. \u00a0\u00bb<\/p>\n

\"dec2003-ppp-1024x768\"<\/a><\/p>\n

Apr\u00e8s deux mois de d\u00e9bats et de codage exp\u00e9rimental, nous avons d\u00e9cid\u00e9 d\u2019en faire une solution commerciale. Tout ce dont nous avions besoin \u00e9tait d\u2019un responsable de projet.<\/p>\n

\u00a0\u00bb Vous vous souvenez de Nikolay Grebennikov du bureau d\u2019\u00e0 c\u00f4t\u00e9 ? Il lit beaucoup, il est jeune et il est nouveau dans l\u2019entreprise. Prenons-le ! \u00a0\u00bb s\u2019est exclam\u00e9 Andrey Doukhvalov en se souvenant d\u2019une conversation qu\u2019il avait eu avec De-Monderik. Andrey Sobko, un ing\u00e9nieur en logiciels rejoindra le groupe plus tard.<\/p>\n

Qu\u2019est-ce que \u00a0\u00bb Prague \u00a0\u00bb ?<\/b><\/p>\n

Cette section est certainement plus int\u00e9ressante pour les ing\u00e9nieurs en logiciel. Le reste de nos lecteurs peut tout \u00e0 fait la passer.<\/p>\n

\"\"<\/a><\/p>\n

\"\"<\/a><\/p>\n

\"\"<\/a><\/p>\n

\"\"<\/a><\/p>\n

\"\"<\/a><\/p>\n

\"\"<\/a><\/p>\n

\"\"<\/a><\/p>\n

M\u00eame au d\u00e9but des ann\u00e9es 90, alors que l\u2019industrie antivirus venait \u00e0 peine de voir le jour, il existait des virus qui n\u2019\u00e9taient pas d\u00e9tectables \u00e0 partir de leur signature. Par exemple, un virus polymorphe, qui chiffre son code diff\u00e9remment pour chaque infection n\u2019est pas d\u00e9tectable \u00e0 partir de sa signature. Alors que les logiciels deviennent plus complexes dans un monde o\u00f9 la p\u00e9n\u00e9tration Internet a atteint des sommets et o\u00f9 les cr\u00e9ateurs de malwares ne cherchent plus seulement \u00e0 se divertir mais offrent leurs services au march\u00e9, les malwares sont eux aussi devenus de plus en plus sophistiqu\u00e9s et de plus en plus malveillants. M\u00eame avec un moteur comprenant d\u2019autres fonctionnalit\u00e9s que l\u2019algorithme de d\u00e9tection des signatures, comme c\u2019\u00e9tait le cas chez Kaspersky Lab, les d\u00e9veloppeurs \u00e9taient oblig\u00e9s de mettre \u00e0 jour l\u2019antivirus sans cesse et non pas uniquement ses bases de donn\u00e9es dans le cas o\u00f9 un malware utiliserait de nouveaux principes. Cela ralentissait de mani\u00e8re significative le temps de r\u00e9action aux nouveaux virus, et le succ\u00e8s de Kaspersky Lab alors qu\u2019ils ont trouv\u00e9 l\u2019antidote au c\u00e9l\u00e8bre virus Tchernobyl (CIH) a prouv\u00e9 que r\u00e9duire le temps de r\u00e9action en valait vraiment la peine.<\/p>\n

M\u00eame au d\u00e9but des ann\u00e9es 90, alors que l\u2019industrie antivirus venait \u00e0 peine de voir le jour, il existait des virus qui n\u2019\u00e9taient pas d\u00e9tectables \u00e0 partir de leur signature.<\/div>\n

\u00c0 la suite de cela, en 1998, Eug\u00e8ne Kaspersky a sugg\u00e9r\u00e9 \u00e0 ses coll\u00e8gues qu\u2019il \u00e9tait temps de partir pour travailler sur un nouveau moteur antivirus. Mais o\u00f9 allaient-ils aller ?<\/p>\n

\u00a0\u00bb La compagnie n\u2019avait pas beaucoup d\u2019argent \u00a0\u00bb a expliqu\u00e9 Eug\u00e8ne Kaspersky, \u00a0\u00bb et nous devions trouver l\u2019endroit le moins cher pr\u00e8s de Moscou pour quitter la ville et s\u2019\u00e9loigner du bruit et de l\u2019agitation. L\u2019endroit devait \u00eatre compl\u00e8tement d\u00e9connect\u00e9. Il n\u2019y avait pas de Wi-Fi \u00e0 l\u2019\u00e9poque. L\u2019endroit le moins cher s\u2019est av\u00e9r\u00e9 \u00eatre la capitale europ\u00e9enne, Prague. \u00a0\u00bb<\/p>\n

En r\u00e9fl\u00e9chissant \u00e0 la nouvelle version du moteur antivirus, l\u2019\u00e9quipe de Kaspersky Lab est arriv\u00e9e \u00e0 la conclusion qu\u2019une approche centr\u00e9e compl\u00e8tement sur les objets \u00e9tait la meilleure solution pour le moteur : en d\u2019autres termes, chaque fichier ou objet analys\u00e9 devraient \u00eatre diss\u00e9qu\u00e9 suivant sa structure et les objets \u00e0 l\u2019int\u00e9rieur devraient \u00eatre d\u00e9tect\u00e9s, analys\u00e9s et v\u00e9rifi\u00e9s. La gestion des objets devrait aussi \u00eatre ex\u00e9cut\u00e9e en temps r\u00e9el.<\/p>\n

Tous les environnements d\u2019objets existants ont \u00e9t\u00e9 d\u00e9battus et rejet\u00e9s car ils n\u2019\u00e9taient pas flexibles, qu\u2019ils occupaient trop de m\u00e9moire ou qu\u2019ils \u00e9taient trop lents. Une id\u00e9e a \u00e9merg\u00e9 au cours de la discussion : pour d\u00e9velopper notre propre environnement, qui int\u00e9grerait des capacit\u00e9s de gestion de la m\u00e9moire et d\u2019autres services, nous aurions besoin de donner \u00e0 l\u2019antivirus l\u2019habilit\u00e9 de diss\u00e9quer et d\u2019analyser un potentiel code de malware de mani\u00e8re rapide et efficace.<\/p>\n

Cette id\u00e9e fut cr\u00e9\u00e9e \u00e0 Prague par De-Monderik et Andrey Krykov et fut support\u00e9e par les premi\u00e8res lignes de code fournies par Doukhvalov et Kryukov.<\/p>\n

Ensuite et pendant plus d\u2019un an, Doukhnalov continua d\u2019\u00e9laborer Prague \u2013 c\u2019\u00e9tait apr\u00e8s tout la raison pour laquelle Kaspersky Lab l\u2019avait embauch\u00e9. Gr\u00e2ce \u00e0 son expertise d\u2019architecte, Dukvalov a permis \u00e0 Prague d\u2019\u00eatre flexible, adaptable et facile \u00e0 mettre en place au sein du produit sans rencontrer de limites architecturales. L\u2019objectif final \u00e9tait de construire une solution multiplateforme.<\/p>\n

Il fut difficile de supprimer les bugs de hi\u00e9rarchie des objets mais un syst\u00e8me d\u2019\u00e9change de messages entre les objets et une interface de programmation minimaliste ont fait de Prague une architecture int\u00e9gr\u00e9e facile \u00e0 utiliser.<\/p>\n

Il fut difficile de supprimer les bugs de hi\u00e9rarchie des objets mais un syst\u00e8me d\u2019\u00e9change de messages entre les objets et une interface de programmation minimaliste ont fait de Prague une architecture int\u00e9gr\u00e9e facile \u00e0 utiliser.<\/div>\n

\u00a0\u00bb Nous avions pr\u00e9vu une approche par composant \u00ab\u00a0, note fi\u00e8rement Doukhvalov. \u00a0\u00bb Cela signifie que des composants pourraient \u00eatre ajout\u00e9s \u00e0 un programme existant. Le syst\u00e8me \u00e9tait tr\u00e8s ouvert, avec la possibilit\u00e9 d\u2019ajouter des \u00e9l\u00e9ments et de changer certains comportements. \u00a0\u00bb<\/p>\n

Une architecture bas\u00e9e sur les composants, compacte et qui n\u2019utilise pas beaucoup de ressources \u00e9tait, d\u2019un commun accord, la base pour introduire une toute nouvelle s\u00e9rie de technologies \u00e0 KAV 6.0. Elles furent mises en place facilement. De plus, quand Prague a \u00e9t\u00e9 utilis\u00e9 comme base pour le produit, et non plus uniquement comme un moteur antivirus, Pavel Mezuev, a largement contribu\u00e9 \u00e0 cette architecture :<\/p>\n

\u00a0\u00bb Nous avons mis en place une solution architecturale suppl\u00e9mentaire en d\u00e9ployant un mod\u00e8le s\u00e9parant la logique op\u00e9rationnelle et l\u2019interface. De plus, Doukhnalov et Mezhuev ont cr\u00e9\u00e9 un gestionnaire des t\u00e2ches capable de contr\u00f4ler n\u2019importe quel processus au sein du produit, et le processus de r\u00e9ciprocit\u00e9 fut tr\u00e8s simple \u00ab\u00a0, d\u00e9clare Nikolay Grebennikov, le responsable de projet de KAV 6.0.<\/p>\n

\"\"<\/a><\/p>\n

\"\"<\/a><\/p>\n

\"\"<\/a><\/p>\n

\"\"<\/a><\/p>\n

\"\"<\/a><\/p>\n

\"\"<\/a><\/p>\n

\"\"<\/a><\/p>\n

\"\"<\/a><\/p>\n

\"\"<\/a><\/p>\n

\"\"<\/a><\/p>\n

Le principe de \u00a0\u00bb Six \u00ab\u00a0<\/b><\/p>\n

\u00c9tant donn\u00e9 que la p\u00e9riode d\u2019essai et l\u2019\u00e9tape initiale de d\u00e9veloppement ont toutes deux \u00e9t\u00e9 r\u00e9alis\u00e9es par un petit groupe, il est devenu clair que les \u00e9normes approches de gestion du projet ne fonctionneraient pas pour l\u2019\u00e9quipe. Par cons\u00e9quent, une approche similaire \u00e0 SCRUM a \u00e9t\u00e9 mise en place : les d\u00e9veloppeurs seraient assis dans un open space, afin de pouvoir constamment interagir \u2013 bien qu\u2019ils avaient d\u00e9j\u00e0 trait\u00e9 tous les aspects du processus de d\u00e9veloppement. Voici la fa\u00e7on dont l\u2019\u00e9quipe de d\u00e9veloppement \u00a0\u00bb Six \u00a0\u00bb a travaill\u00e9 :<\/p>\n

SCRUM<\/b><\/p>\n

SCRUM est une approche de gestion de projet pour un environnement de d\u00e9veloppement logiciel flexible. Elle est bas\u00e9e sur le principe que le client (l\u2019utilisateur) ne conna\u00eet pas exactement ce dont il a besoin et que les n\u00e9cessit\u00e9s du projet peuvent changer au cours du processus. Cela signifie que le processus de d\u00e9veloppement est caract\u00e9ris\u00e9 par la pr\u00e9sence de plusieurs cycles : construire \u2013 appliquer \u2013 analyser des r\u00e9sultats \u2013 mise \u00e0 jour de la version.<\/p>\n

Mais la distribution des r\u00f4les de SCRUM a \u00e9t\u00e9 revue de mani\u00e8re consid\u00e9rable. Kaspersky Lab a d\u00e9fini six roles :<\/p>\n

L\u2019architecte<\/b><\/p>\n

Il s\u2019agit d\u2019une personne (activement impliqu\u00e9e dans le processus de codage) qui sait ce qu\u2019elle doit construire et comment le faire.<\/p>\n

Le designer technique<\/b><\/p>\n

Il n\u2019existe pas de d\u00e9finition pr\u00e9cise de ce r\u00f4le, mais cette personne est responsable de la cr\u00e9ation de certaines solutions. La fonction la plus importante du designer est certainement celle de savoir ce qu\u2019il ne faut PAS faire.<\/p>\n

L\u2019inventeur est charg\u00e9 de trouver des solutions originales pour r\u00e9soudre les probl\u00e8mes. Dans le cas de \u00a0\u00bb Six \u00ab\u00a0, les probl\u00e8mes \u00e9taient nombreux.<\/div>\n

L\u2019inventeur<\/b><\/p>\n

L\u2019inventeur est charg\u00e9 de trouver des solutions originales pour r\u00e9soudre les probl\u00e8mes. Dans le cas de \u00a0\u00bb Six \u00ab\u00a0, les probl\u00e8mes \u00e9taient nombreux. La solution devait fournir le plus haut niveau de protection possible mais utiliser le moins de ressources informatiques possibles.<\/p>\n

Le responsable de projet<\/b><\/p>\n

Le r\u00f4le du responsable de projet dans SCRUM ne signifie pas uniquement imposer des r\u00e8gles. Il contr\u00f4le les ressources et les dates limites mais il n\u2019est pas un r\u00e9el leader. Il n\u2019indique pas aux codeurs ce qu\u2019ils doivent faire mais il les encourage \u00e0 prendre le contr\u00f4le.<\/p>\n

\u00a0\u00bb L\u2019\u00e9quipe \u00e9tait petite, nous n\u2019avions m\u00eame pas de chef au d\u00e9part \u00a0\u00bb explique Doukhvalov. \u00a0\u00bb Le responsable planifiait, rapportait, mais les d\u00e9cisions \u00e9taient collectives. \u00a0\u00bb<\/p>\n

Le responsable marketing<\/b><\/p>\n

Le produit est cr\u00e9\u00e9 pour des clients et non pas pour l\u2019\u00e9quipe de d\u00e9veloppement elle-m\u00eame. Il est vital d\u2019avoir une bonne compr\u00e9hension des attentes des futurs utilisateurs et de comment ils l\u2019utiliseront. Alors que les principes op\u00e9rationnels sont d\u00e9finis par ceux qui comprennent la nature des fonctionnalit\u00e9s antivirus, des milliers de petites choses telles que la configuration, le syst\u00e8me de messagerie ou l\u2019interface utilisateur doivent prendre en consid\u00e9ration les n\u00e9cessit\u00e9s des utilisateurs.<\/p>\n

Le psychologue<\/b><\/p>\n

Travailler sous pression, manquer de sommeil, les conflits au sein du groupe, l\u2019instabilit\u00e9\u2026 Quelqu\u2019un doit s\u2019assurer que l\u2019environnement de la pi\u00e8ce est agr\u00e9able et productif. Ce r\u00f4le a \u00e9t\u00e9 attribu\u00e9 \u00e0 Eug\u00e8ne Kaspersky lui-m\u00eame, il a \u00e9galement fait office de parrain en fournissant les fonds et les ressources n\u00e9cessaires \u00e0 l\u2019\u00e9quipe et en prot\u00e9geant cette derni\u00e8re de l\u2019influence ext\u00e9rieure.<\/p>\n

Il existe un autre r\u00f4le fondamental aux projets SCRUM : celle du scribe<\/b> qui prend en note le processus. Mais cette position n\u2019a \u00e9t\u00e9 occup\u00e9e par personne et cela a cr\u00e9\u00e9 des probl\u00e8mes.<\/p>\n

\u00a0\u00bb Nous ne savons pas pourquoi nous avons fait ce choix ou pris cette d\u00e9cision il y a seulement six mois \u00a0\u00bb affirme Eug\u00e8ne Kaspersky.<\/p>\n

Dans cette approche, le nombre de r\u00f4les ne correspond pas n\u00e9cessairement au nombre de membres dans l\u2019\u00e9quipe. Le m\u00eame r\u00f4le peut \u00eatre distribu\u00e9 parmi plusieurs personnes, alors qu\u2019une m\u00eame personne peut occuper plusieurs r\u00f4les.<\/p>\n

le nombre de r\u00f4les ne correspond pas n\u00e9cessairement au nombre de membres dans l\u2019\u00e9quipe. Le m\u00eame r\u00f4le peut \u00eatre distribu\u00e9 parmi plusieurs personnes, alors qu\u2019une m\u00eame personne peut occuper plusieurs r\u00f4les.<\/div>\n

\u00a0\u00bb Bien que nous ayons choisi une organisation formelle, nous avons fonctionn\u00e9 comme une seule \u00e9quipe, les limites entre certains r\u00f4les \u00e9taient donc floues : en particulier quand nous \u00e9changions des id\u00e9es, tout le monde occupait diff\u00e9rents r\u00f4les \u00ab\u00a0, confesse Nikolay Grebennikov. \u00a0\u00bb Disons que si une personne \u00e9tait en train de coder, elle pouvait aussi partager ses id\u00e9es en mati\u00e8re de design, et son avis \u00e9tait pris en compte. J\u2019\u00e9tais le responsable de projet mais je participais \u00e9galement aux discussions \u2013 ces limites floues ont r\u00e9ellement contribu\u00e9 \u00e0 notre succ\u00e8s, car nous nous prenions en compte chaque \u00e9l\u00e9ment de notre projet. \u00a0\u00bb<\/p>\n

Selon De-Monderik, les codeurs \u00e9taient compl\u00e8tement interchangeables : \u00a0\u00bb Chaque membre de l\u2019\u00e9quipe \u00e9tait le meilleur dans son domaine, mais 50% de ses aptitudes d\u00e9bordaient sur celles de quelqu\u2019un d\u2019autre. Mike \u00e9tait capable de coder des pilotes si Sobko n\u2019\u00e9tait pas l\u00e0, les sp\u00e9cialistes en interface utilisateur pouvaient g\u00e9rer des t\u00e2ches relatives au moteur et vice-versa. Je pouvais m\u2019occuper du design \u00e0 la place de Max Yudanov et Kolya Grebennikov pouvait \u00e9galement s\u2019en charger.<\/p>\n

Il est crucial de comprendre que chaque r\u00f4le m\u00e8ne vers une \u00e9tape sp\u00e9cifique du projet d\u2019ex\u00e9cution. Pendant la phase de d\u00e9marrage, l\u2019architecte est la figure centrale. Le cr\u00e9ateur entre en action au milieu du processus de d\u00e9veloppement quand les fonctionnalit\u00e9s sont cr\u00e9\u00e9es et d\u00e9velopp\u00e9es. Et pendant la derni\u00e8re \u00e9tape, la figure centrale est le responsable de projet car le projet dispose d\u00e9sormais de nombreuses ressources qui requi\u00e8rent une gestion stricte afin que l\u2019\u00e9quipe soit capable de respecter la date limite.<\/p>\n

A la poursuite d\u2019un id\u00e9al <\/b><\/p>\n

\u00c9tant donn\u00e9 l\u2019approche \u00ab\u00a0SCRUM \u00a0\u00bb et l\u2019ambition du projet, \u00a0\u00bb Six \u00a0\u00bb ne disposait pas d\u2019une liste d\u2019exigences statique. Selon les exigences de base, le produit devait disposer des capacit\u00e9s suivantes :<\/p>\n