L’un des moments essentiels qui a permis à Kaspersky Lab d’acquérir une renommée internationale dans le secteur de la sécurité fut la sortie du produit révolutionnaire Kaspersky Anti-Virus 6.0. Officiellement lancé en 2006, le produit fut un véritable succès sur le marché international des antivirus, et a permis d’établir Kaspersky comme un leader en matière de technologies pour les années à venir. Dire que le produit est la meilleure solution au monde ne serait pas très modeste, mais c’est ce que de nombreux magazines et entités indépendantes ont déclaré.

La route vers le succès n’a pas été de tout repos – et peut-être qu’un jour un scénariste d’Hollywood reprendra cette histoire, mais en attendant, nous essaierons de partager notre succès avec vous en vous montrant des photos, des notes et des souvenirs provenant de l’équipe de développeurs originale. Nous espérons que cette histoire servira d’exemple aux jeunes développeurs qui créent de nos jours de nouvelles applications et services – s’ils souhaitent devenir les meilleurs, comme les créateurs de « Six ».

Une célèbre photo faite le jour du lancement de la version  » Six « 

Problèmes en 2003

Le succès de  » Six  » trouve son origine dans la catastrophe que fut la version précédente. Cette cinquième version n’a d’ailleurs jamais vu le jour.

Pour comprendre l’essence de la catastrophe, nous devons retourner en 2002 : Windows XP venait alors à peine de sortir, les CPU étaient enfin capables d’atteindre une fréquence d’horloge de 1GHz et la très jeune industrie antivirus devait encore découvrir toute une variété de menaces. Toutes les sociétés antivirus ont alors étendu les capacités de leurs produits : à l’époque, une solution compétitive devait inclure un pare-feu, une surveillance constante des fichiers systèmes et des douzaines d’autres fonctionnalités.

Après avoir construit un puissant moteur d’analyse dans les années 1990, l’équipe de développement de Kaspersky Lab a admis qu’ajouter toute une série de fonctionnalités à la solution la rendrait extrêmement lente – même le V4.0 de l’époque était déjà condamné par les utilisateurs (il y avait à l’époque toutes sortes d’allégations affirmant que le produit de Kaspersky était lent). C’est la raison pour laquelle le processus de développement du nouveau V5.0 a été approché avec beaucoup de précautions, en considérant seulement les éléments essentiels : un nouveau responsable des technologies a été désigné, une nouvelle structure de développement a été employée et une nouvelle architecture antivirus a été choisie.

La société a utilisé toutes ses ressources pour supporter le projet. Malgré cela, rien ne garantissait que dans un an, toutes ces nouvelles règles de développement permettraient de créer un produit compétitif. Le système créé qui reprenait les applications client-serveur de niveau professionnel (une architecture choisie par le responsable des technologies) n’était pas capable de répondre aux exigences des produits antivirus sur le marché. Il était lent et lourd et le nombre de bugs ne cessait de s’accroitre alors que l’équipe testait le produit.

 » J’ai commencé à demander aux gens, aux vétérans de la société, ce qu’ils pensaient. Ils ont dit que tout se jouait dans l’architecture. C’était comme un château de cartes : en fixant un côté, vous détruisez tout le château  » a admis Eugène Kaspersky. Il ne servait donc à rien de continuer avec le projet tel qu’il était. Il devait être complètement démoli et reconstruit à partir de zéro.

Nous pouvons le faire !

L’équipe de développement de Kaspersky Lab s’est divisée en deux groupes : l’un éprouvait des difficultés à réparer le produit à cause de sa mauvaise architecture, et l’autre se chargeait de sortir le V4.0 dans un nouveau produit.

Au même moment, un groupe de quatre a décidé de créer un tout nouveau produit qui ne respectait pas seulement les exigences du marché mais qui résisterait également aux exigences futures. L’objectif, qui avait été fixé par l’équipe de développement  » Six « , était simple à expliquer mais difficile à atteindre. La nouvelle version devait empêcher tous les virus et les menaces de s’infiltrer dans le système, elle devait être rapide, agile et transparente, et… elle devait être attrayante.

 » Nous voulions juste créer le meilleur produit de tous les temps « , se souvient l’équipe de développeurs  » Six « . Une très petite équipe confrontée à une tâche monumentale : c’est comme cela que les 200 autres employés la considéraient. La petite équipe avait néanmoins de bonnes raisons d’être optimiste : les fondateurs de la société, Eugène Kaspersky et Alexey De-Monderik, cherchaient à l’époque de nouvelles alternatives d’architecture – et ils allaient bientôt découvrir qu’une alternative existait et celle-ci a été inventée par l’équipe de Kaspersky Lab elle-même.

De l’aide en provenance de Prague

Il est important de mentionner que deux noyaux antivirus (aussi appelés  » moteurs « ) fonctionnaient déjà dans un paquet inclus dans V4.0. La vérification des fichiers était réalisée par l’ancien mais encore très capable (et massivement supporté par des entreprises internationales telles que G-Data et F-Secure) moteur V3.0 développé en 1996. La nouvelle tâche de réaliser la filtration du trafic Internet était gérée par le puissant nouveau mécanisme qui avait été conçu lors d’une session de brainstorming à Prague en 1998.

Le moteur a fini par être surnommé  » Prague « , bien qu’il ait été développé à Moscou par Andrey Doukhvalov qui n’était pas présent lors de la session de brainstorming dans la capitale tchèque. Les idées clés trouvent néanmoins leurs origines à Prague et Andrey a rejoint l’entreprise pour compléter ces idées et faire que Prague voit le jour.

Prague était censé devenir un noyau antivirus mais les objectifs prévus pour ce dernier étaient tellement ambitieux que la flexibilité et l’ingéniosité du nouveau moteur furent suffisantes pour faire fonctionner les systèmes les plus complexes. La question de savoir s’il était possible de créer la totalité du produit à partir de Prague inquiétait Eugène Kaspersky alors qu’il parlait avec les développeurs. Il se souvient :

 » Une fois, j’ai demandé à Victor Matyushenko comment Prague s’en sortait à l’intérieur du produit, et il m’a répondu qu’il était  » solide comme un roc ! « . Ce fut le point décisif. J’ai ensuite formulé ma question. Je suis rentré dans la pièce où Graf (De-Monderik) et Petrovich (Doukhanalov) travaillaient et je leur ai posé la question suivante :  » Pourquoi ne basons-nous pas entièrement le produit sur Prague ? « . Graf a répondu quelque chose comme  » impossible, Prague n’est pas fait pour ça « , mais Petrovich a hésité. Le matin suivant, il est arrivé à notre bureau avec un petit tas de feuilles et il m’a dit :  » Tu sais, j’ai codé certains cas d’utilisation sur Prague.  » Graf l’a regardé et a dit :  » nous devons avoir une discussion « . Ensuite, après en avoir parlé, ils sont revenus me voir et m’ont confirmé que cela valait la peine d’essayer.  »

L’essai a commencé avec une équipe très restreinte qui a écrit les premières lignes de code qui deviendraient plus tard la version  » Six « .

 » Nous avons commencé à chercher des personnes créatives qui pourraient contribuer et nous avons réuni une équipe importante « , se souvient De-Monderik.  » Prenez, par exemple, Pavel Mezhuev, c’était un codeur novice mais il était brillant. Il y avait également Mike Pavlyuschik avec qui nous travaillions depuis longtemps. Il était capable de trouver des idées et des concepts originaux. Pour moi, il s’agissait de l’un des créateurs les plus talentueux et les plus appliqués de l’industrie.  »

Après deux mois de débats et de codage expérimental, nous avons décidé d’en faire une solution commerciale. Tout ce dont nous avions besoin était d’un responsable de projet.

 » Vous vous souvenez de Nikolay Grebennikov du bureau d’à côté ? Il lit beaucoup, il est jeune et il est nouveau dans l’entreprise. Prenons-le !  » s’est exclamé Andrey Doukhvalov en se souvenant d’une conversation qu’il avait eu avec De-Monderik. Andrey Sobko, un ingénieur en logiciels rejoindra le groupe plus tard.

Qu’est-ce que  » Prague  » ?

Cette section est certainement plus intéressante pour les ingénieurs en logiciel. Le reste de nos lecteurs peut tout à fait la passer.

Même au début des années 90, alors que l’industrie antivirus venait à peine de voir le jour, il existait des virus qui n’étaient pas détectables à partir de leur signature. Par exemple, un virus polymorphe, qui chiffre son code différemment pour chaque infection n’est pas détectable à partir de sa signature. Alors que les logiciels deviennent plus complexes dans un monde où la pénétration Internet a atteint des sommets et où les créateurs de malwares ne cherchent plus seulement à se divertir mais offrent leurs services au marché, les malwares sont eux aussi devenus de plus en plus sophistiqués et de plus en plus malveillants. Même avec un moteur comprenant d’autres fonctionnalités que l’algorithme de détection des signatures, comme c’était le cas chez Kaspersky Lab, les développeurs étaient obligés de mettre à jour l’antivirus sans cesse et non pas uniquement ses bases de données dans le cas où un malware utiliserait de nouveaux principes. Cela ralentissait de manière significative le temps de réaction aux nouveaux virus, et le succès de Kaspersky Lab alors qu’ils ont trouvé l’antidote au célèbre virus Tchernobyl (CIH) a prouvé que réduire le temps de réaction en valait vraiment la peine.

À la suite de cela, en 1998, Eugène Kaspersky a suggéré à ses collègues qu’il était temps de partir pour travailler sur un nouveau moteur antivirus. Mais où allaient-ils aller ?

 » La compagnie n’avait pas beaucoup d’argent  » a expliqué Eugène Kaspersky,  » et nous devions trouver l’endroit le moins cher près de Moscou pour quitter la ville et s’éloigner du bruit et de l’agitation. L’endroit devait être complètement déconnecté. Il n’y avait pas de Wi-Fi à l’époque. L’endroit le moins cher s’est avéré être la capitale européenne, Prague.  »

En réfléchissant à la nouvelle version du moteur antivirus, l’équipe de Kaspersky Lab est arrivée à la conclusion qu’une approche centrée complètement sur les objets était la meilleure solution pour le moteur : en d’autres termes, chaque fichier ou objet analysé devraient être disséqué suivant sa structure et les objets à l’intérieur devraient être détectés, analysés et vérifiés. La gestion des objets devrait aussi être exécutée en temps réel.

Tous les environnements d’objets existants ont été débattus et rejetés car ils n’étaient pas flexibles, qu’ils occupaient trop de mémoire ou qu’ils étaient trop lents. Une idée a émergé au cours de la discussion : pour développer notre propre environnement, qui intégrerait des capacités de gestion de la mémoire et d’autres services, nous aurions besoin de donner à l’antivirus l’habilité de disséquer et d’analyser un potentiel code de malware de manière rapide et efficace.

Cette idée fut créée à Prague par De-Monderik et Andrey Krykov et fut supportée par les premières lignes de code fournies par Doukhvalov et Kryukov.

Ensuite et pendant plus d’un an, Doukhnalov continua d’élaborer Prague – c’était après tout la raison pour laquelle Kaspersky Lab l’avait embauché. Grâce à son expertise d’architecte, Dukvalov a permis à Prague d’être flexible, adaptable et facile à mettre en place au sein du produit sans rencontrer de limites architecturales. L’objectif final était de construire une solution multiplateforme.

Il fut difficile de supprimer les bugs de hiérarchie des objets mais un système d’échange de messages entre les objets et une interface de programmation minimaliste ont fait de Prague une architecture intégrée facile à utiliser.

 » Nous avions prévu une approche par composant « , note fièrement Doukhvalov.  » Cela signifie que des composants pourraient être ajoutés à un programme existant. Le système était très ouvert, avec la possibilité d’ajouter des éléments et de changer certains comportements.  »

Une architecture basée sur les composants, compacte et qui n’utilise pas beaucoup de ressources était, d’un commun accord, la base pour introduire une toute nouvelle série de technologies à KAV 6.0. Elles furent mises en place facilement. De plus, quand Prague a été utilisé comme base pour le produit, et non plus uniquement comme un moteur antivirus, Pavel Mezuev, a largement contribué à cette architecture :

 » Nous avons mis en place une solution architecturale supplémentaire en déployant un modèle séparant la logique opérationnelle et l’interface. De plus, Doukhnalov et Mezhuev ont créé un gestionnaire des tâches capable de contrôler n’importe quel processus au sein du produit, et le processus de réciprocité fut très simple « , déclare Nikolay Grebennikov, le responsable de projet de KAV 6.0.

Le principe de  » Six « 

Étant donné que la période d’essai et l’étape initiale de développement ont toutes deux été réalisées par un petit groupe, il est devenu clair que les énormes approches de gestion du projet ne fonctionneraient pas pour l’équipe. Par conséquent, une approche similaire à SCRUM a été mise en place : les développeurs seraient assis dans un open space, afin de pouvoir constamment interagir – bien qu’ils avaient déjà traité tous les aspects du processus de développement. Voici la façon dont l’équipe de développement  » Six  » a travaillé :

SCRUM

SCRUM est une approche de gestion de projet pour un environnement de développement logiciel flexible. Elle est basée sur le principe que le client (l’utilisateur) ne connaît pas exactement ce dont il a besoin et que les nécessités du projet peuvent changer au cours du processus. Cela signifie que le processus de développement est caractérisé par la présence de plusieurs cycles : construire – appliquer – analyser des résultats – mise à jour de la version.

Mais la distribution des rôles de SCRUM a été revue de manière considérable. Kaspersky Lab a défini six roles :

L’architecte

Il s’agit d’une personne (activement impliquée dans le processus de codage) qui sait ce qu’elle doit construire et comment le faire.

Le designer technique

Il n’existe pas de définition précise de ce rôle, mais cette personne est responsable de la création de certaines solutions. La fonction la plus importante du designer est certainement celle de savoir ce qu’il ne faut PAS faire.

L’inventeur

L’inventeur est chargé de trouver des solutions originales pour résoudre les problèmes. Dans le cas de  » Six « , les problèmes étaient nombreux. La solution devait fournir le plus haut niveau de protection possible mais utiliser le moins de ressources informatiques possibles.

Le responsable de projet

Le rôle du responsable de projet dans SCRUM ne signifie pas uniquement imposer des règles. Il contrôle les ressources et les dates limites mais il n’est pas un réel leader. Il n’indique pas aux codeurs ce qu’ils doivent faire mais il les encourage à prendre le contrôle.

 » L’équipe était petite, nous n’avions même pas de chef au départ  » explique Doukhvalov.  » Le responsable planifiait, rapportait, mais les décisions étaient collectives.  »

Le responsable marketing

Le produit est créé pour des clients et non pas pour l’équipe de développement elle-même. Il est vital d’avoir une bonne compréhension des attentes des futurs utilisateurs et de comment ils l’utiliseront. Alors que les principes opérationnels sont définis par ceux qui comprennent la nature des fonctionnalités antivirus, des milliers de petites choses telles que la configuration, le système de messagerie ou l’interface utilisateur doivent prendre en considération les nécessités des utilisateurs.

Le psychologue

Travailler sous pression, manquer de sommeil, les conflits au sein du groupe, l’instabilité… Quelqu’un doit s’assurer que l’environnement de la pièce est agréable et productif. Ce rôle a été attribué à Eugène Kaspersky lui-même, il a également fait office de parrain en fournissant les fonds et les ressources nécessaires à l’équipe et en protégeant cette dernière de l’influence extérieure.

Il existe un autre rôle fondamental aux projets SCRUM : celle du scribe qui prend en note le processus. Mais cette position n’a été occupée par personne et cela a créé des problèmes.

 » Nous ne savons pas pourquoi nous avons fait ce choix ou pris cette décision il y a seulement six mois  » affirme Eugène Kaspersky.

Dans cette approche, le nombre de rôles ne correspond pas nécessairement au nombre de membres dans l’équipe. Le même rôle peut être distribué parmi plusieurs personnes, alors qu’une même personne peut occuper plusieurs rôles.

 » Bien que nous ayons choisi une organisation formelle, nous avons fonctionné comme une seule équipe, les limites entre certains rôles étaient donc floues : en particulier quand nous échangions des idées, tout le monde occupait différents rôles « , confesse Nikolay Grebennikov.  » Disons que si une personne était en train de coder, elle pouvait aussi partager ses idées en matière de design, et son avis était pris en compte. J’étais le responsable de projet mais je participais également aux discussions – ces limites floues ont réellement contribué à notre succès, car nous nous prenions en compte chaque élément de notre projet.  »

Selon De-Monderik, les codeurs étaient complètement interchangeables :  » Chaque membre de l’équipe était le meilleur dans son domaine, mais 50% de ses aptitudes débordaient sur celles de quelqu’un d’autre. Mike était capable de coder des pilotes si Sobko n’était pas là, les spécialistes en interface utilisateur pouvaient gérer des tâches relatives au moteur et vice-versa. Je pouvais m’occuper du design à la place de Max Yudanov et Kolya Grebennikov pouvait également s’en charger.

Il est crucial de comprendre que chaque rôle mène vers une étape spécifique du projet d’exécution. Pendant la phase de démarrage, l’architecte est la figure centrale. Le créateur entre en action au milieu du processus de développement quand les fonctionnalités sont créées et développées. Et pendant la dernière étape, la figure centrale est le responsable de projet car le projet dispose désormais de nombreuses ressources qui requièrent une gestion stricte afin que l’équipe soit capable de respecter la date limite.

A la poursuite d’un idéal

Étant donné l’approche « SCRUM  » et l’ambition du projet,  » Six  » ne disposait pas d’une liste d’exigences statique. Selon les exigences de base, le produit devait disposer des capacités suivantes :

• Un support complet contre les menaces de sécurité
• Une utilisations des ressources du PC optimisée
• Une infrastructure basée sur les composants pour une meilleure adaptation
• Une adaptation facile des composants aux différentes plateformes

À partir de ces méta-exigences, les nécessités techniques correspondantes du produit ont été modifiées. Par conséquent, la date de sortie était sans cesse repoussée mais l’équipe a pu développer une solution révolutionnaire en avance de quelques années sur les exigences du marché et supérieure à la version précédente en matière de vitesse.  »

À la suite du lancement de Kaspersky Anti-Virus 6.0, Maxim Yudanov le responsable du design de l’interface utilisateur a déclaré :  » L’une des différences clés de ce projet est l’absence d’une liste d’exigences  » gravée dans la pierre « . Nous avons créé des prototypes, parlé du produit, mis à jour la liste des exigences techniques et des fonctionnalités, pris en note les points principaux sur des Post-it et les avons collés sur nos écrans, nous avons oublié des choses, nous nous en sommes souvenus, avons tout recommencé, avons demandé l’aide du public (je veux dire de la communauté de test de la version Beta). Je suis certain que le produit final n’aurait pas été comme il l’est maintenant si nous avions travaillé à partir d’une liste d’exigences traditionnelle. Si ça avait été le cas, nous aurions fini par créer un produit comme nous l’avions imaginé au départ. Je suis certain que dans ce cas, le produit aurait été bien plus mauvais que celui que nous avons obtenu.  »

Programmation extrême

Aujourd’hui cette approche n’a rien de nouveau. Mais il y a 10 ans, cette méthode appliquée à des projets à si grande échelle était révolutionnaire et non conventionnelle. La différence majeure entre la soi-disant  » programmation extrême  » (cette expression était alors très largement utilisée, désormais les méthodes similaires sont regroupées sous l’expression  » développement de logiciel agile « ) et l’approche de codage bureaucratique CMM (qui a presque complètement disparu) repose sur l’absence d’une liste d’exigences traditionnelle comme base du projet pour les années à venir. Le CMM est peut-être l’approche à suivre pour les projets de développement externalisés mais pour les projets commerciaux, il est inutile.

Nikolay Grebennikov, qui est désormais le directeur technique de Kaspersky Lab, est d’accord avec ce principe :  » Si nous avions commencé par trouver une série de fonctionnalités figée sans possibles modifications ultérieures, nous n’aurions pas eu l’opportunité de comprendre ce dont les utilisateurs avaient besoin et nous n’aurions pas pu obtenir un tel support de leur part. La première version du produit n’était pas vraiment utilisable et présentait de nombreux problèmes. Nous avons passé beaucoup de temps à les régler – cinq trimestres ont passé entre la sortie Alpha et la sortie technique. Dans le monde d’aujourd’hui, c’est un luxe dont on ne dispose plus, mais à l’époque, ce fut une expérience très utile.  »

L’agenda de développement (en russe)

Eugène Kaspersky est plutôt clair sur le sujet :  » Quand vous développez des innovations, soyez près à ne jamais respecter les dates limites.  »

La vie au travail

Les membres clés de l’équipe de développement de KAV 6.0 se souviennent de cette époque de leur vie avec nostalgie. Avec le manque de sommeil, le manque de temps passé avec leur famille, le manque de week-ends libres, ils subissaient un stress émotionnel important et ils ont été récompensés par les progrès et la qualité de leur travail.

L’un des emails écrits par Nikolay Brebennikov, alors que le projet était en cours de développement, nous fournit un aperçu de cette époque plutôt poétique :

 » À un moment donné, ce n’était plus qu’un simple projet. C’était comme s’engager dans un jeu immense et vous y plonger et le vivre du début à la fin. En route pour le travail, dans le métro, vous pensez aux victoires et aux défaites de la partie précédente, vous commencez ensuite à travailler, et vous pensez à comment jouer pour pouvoir accéder au niveau suivant. Quand vous avez couché vos enfants, vous vivez de nouveau à l’intérieur du jeu où vous étiez capable de toutes les choses imaginables et où tout était possible.  »

 » C’était en fait le meilleur moment de ma vie  » se souvient Eugène Kaspersky.  » Les yeux pleins d’enthousiasme, les Post-it, les membres de l’équipe privés de sommeil. C’était un bouillon d’idées et d’actions.  »

Quand l’équipe s’est agrandie, le noyau du groupe de développement a transmis cet esprit aux nouveaux venus. De-Monderik s’en souvient :

 » Avec tous les membres de l’équipe travaillant ensemble, nous devions compter sur l’habilité du  » groupe noyau  » pour briller d’enthousiasme. Il y avait le  » groupe noyaux « , ils avaient cette idée générale, ils avaient un défi : créer le meilleur produit de tous les temps. C’était leur objectif clé : Kolya (Grebennikov), Pavel Mezhuev, Doukhvalov, moi-même, Mike Pavlyuschik… nous avons pu transmettre notre enthousiasme aux autres membres de l’équipe. Tout le monde travaille dur et vous êtes dans la même pièce, vous voyez vraiment comment cela se passe et vous essayez de vous engager aussi sans le savoir.  »

Même le responsable de projet était plutôt informel et cela a porté ses fruits.

 » Si je me souviens bien, au début, nous avions des réunions sur l’état du projet « , déclare De-Monderik.  » Le matin, quand le groupe se réunissait dans la pièce, Kolya avait l’habitude de donner une sorte de speech récapitulatif : nous disposons de telles ressources, nous réaliserons telles et telles tâches aujourd’hui – il était super doué pour ça. Nous avions un énorme tableau blanc où nous écrivions et dessinions nos idées. Comme nous n’étions pas une énorme équipe, c’était suffisant.  »

Grebennikov reconnaît que ce qui a vraiment fait la différence dans ce projet c’est que la réunion sur l’état du projet comme méthode formelle d’organisation du projet n’était pas le plus important. L’équipe ne devrait être rassemblée que si cela apporte de réels bénéfices au projet.

Élargir l’étendue

Alors que le projet a évolué avec le temps, de septembre 2003 à mars 2006, l’équipe s’est agrandi et le jour de la sortie du produit, le groupe comprenait presque 30 personnes. Avec plus d’exigences et la transition vers l’étape « Alpha », l’équipe a ensuite accueilli un nouveau designer, Maxim Yudanov, ainsi que de nouveaux ingénieurs en logiciels : Pavel Nechayev, Denis Gushin, Eugène Roschin et Andrey Gerasimov. Ils ont apporté toute une série de fonctionnalités innovantes telles qu’une interface utilisateur basée sur un thème unique et un pare-feu intégré. Le groupe a également accueilli des spécialistes en installation et des contrôleurs de tests Beta. Néanmoins, l’une des étapes les plus importantes qui a permis de modifier et de redéfinir KAV 6.0 fut une nouvelle approche inventée par l’équipe « Six » : un test Beta se basant sur un forum.

Forum

Tous les participants ont admis collectivement que c’est grâce au forum de testeurs que Kaspersky Anti-Virus 6.0 a été si bien conçu et testé. Le test Beta ouvert à tous (ce qui est devenu une pratique courante à Kaspersky Lab) fut à l’époque une réelle innovation et également un risque : la concurrence aurait pu en profiter pour découvrir les fonctionnalités du produit avant sa sortie.

« Nous avons pris les choses très sérieusement car un test Beta expose les codes Beta aux pirates et à la concurrence » explique Grebennikov. « Les gens avaient une opinion bien définie sur le sujet. Les opposants ont eu leur mot à dire et leurs arguments principaux sont listés ci-dessous. Néanmoins, les partisans ont également apporté de solides éléments justifiant leur position. Nos ressources étaient limitées, avec seulement deux testeurs disponibles alors que le reste des testeurs s’occupaient des essais de la version V5.0. Notre produit a été créé à partir de rien, et nous avions besoin d’un groupe énorme pour réaliser les tests. Nous avons employé, pour la première fois, l’approche de la mise à jour régulière, premièrement de manière hebdomadaire puis ensuite quotidiennement. Tester ces outils sur le forum nous a permis de fournir la qualité de test la plus avancée sans avoir à impliquer des ressources internes conséquentes. »

Tous les développeurs étaient activement engagés dans les discussions du forum avec les testeurs.

« Pendant le test du forum, le groupe de testeurs comprenait plusieurs milliers d’utilisateurs, avec plus de 500 personnes actives » ajoute Nikolay Grebennikov. Chaque soir, Nikolay avait l’habitude de passer des heures sur le forum, s’endormant même parfois devant son ordinateur. Ils avaient envie de découvrir une nouvelle fonction et avaient l’habitude de l’utiliser tous les soirs, ce qui n’engageait absolument aucun coût pour l’entreprise.

Les résidants du forum fournissaient aussi bien des informations sur les bugs que des suggestions sur comment améliorer le problème. Une grande partie de ce retour collectif a été pris en compte, et a contribué à la qualité de KAV 6.0. En outre, les suggestions n’étaient pas collectées uniquement en ligne. Eugène Kaspersky se souvient que les développeurs se rendaient régulièrement aux étages des autres bureaux, incluant tout le monde, des responsables des ventes au personnel du support technique, dans la version de test Beta. À partir du retour du personnel, le produit a connu quelques améliorations : par exemple, à partir des suggestions de l’équipe de support technique, changer de langue vers l’anglais a été rendu possible en un simple clic.

Néanmoins, les améliorations apportées grâce aux discussions du forum ont eu un prix – elles ont sans cesse repoussé la sortie du produit.

« À partir du feedback des utilisateurs du forum, nous avons reçu une énorme liste de suggestions mais à un moment, j’ai réalisé que nous ne pouvions pas ajouter plus d’éléments, même si la proposition était intéressante. Nous devions respecter un planning stricte pour la sortie prévue au cours du deuxième trimestre de 2006. Nous avons terminé juste à temps : à 18h30, le 31 mars » se souvient Nikolay Grebennikov.

Sortie

Succès

L’élément essentiel est que, notre équipe étendue (bien que toujours relativement concise) a développé un produit doté d’un programme d’installation compact, d’une interface utilisateur simple basées sur des couches interchangeables, un impact sur les performances de l’ordinateur relativement moindre, et encore plus important, un produit rempli de fonctionnalités puissantes et innovantes telles que des capacités de protection permettant de bloquer les applications suspectes selon leur comportement.

« À Symantec, ils ont halluciné quand les magazines américains ont commencé à nous donnés les meilleures notes. Nous avons reçu d’excellentes notes partout », affirme Eugène Kaspersky, très heureux.

Grâce au réseau de partenaires de la société en Europe, aux États-Unis et en Chine, le produit a été rapidement mis en vente et il a même fait partie des meilleurs ventes en ligne.

Le succès de « Six » est dû à une architecture choisie avec soin qui a permis de déployer facilement nos innovations technologiques et qui offrait de hautes performances ainsi qu’une approche de développement qui correspondait à 100% à l’enthousiasme de notre petite équipe. C’est là que réside le travail qui a permis de lancer Kaspersky Anti-Virus 6.0 sur le marché – pour mener à bien un projet, aussi bien l’architecture que les techniques de développement doivent être alignées avec l’équipe de développement et l’étendue du travail.

Six rôles et une machine à café

« Dans la stratégie SCRUM que nous avons utilisée à cette époque, j’ai observé une règle intéressante que je considère aussi dans d’autres sphères que celle du développement », affirme Eugène Kaspersky. « Si quelque chose entrave le processus de développement, ce problème doit être immédiatement éliminé et c’est tout. Peu importe ce que c’est. Cela signifie également, que si un développeur a besoin de quelque chose, il doit l’obtenir tout de suite. »

« Le premier jour du projet, j’ai demandé : « Qu’elle est votre exigence première ? », « Une machine à café », a répondu Petrovich. Le matin suivant, nous leur avons acheté une super cafetière. Et nous avons réussi ! »

Le totem du projet, la toute première cafetière de Kaspersky Lab, elle ne fonctionne plus mais elle reste exposée dans le bureau d’Andrey Petrovich.