L'affirmation de Werber sur la nature générale du système
- L'expert a exprimé son avis selon lequel il s'agissait d'un système construit sans aucune norme et avec un très faible niveau de professionnalisme, et que ses développeurs n'avaient pas agi de manière professionnelle sur les questions fondamentales essentielles au développement fiable et réussi d'un logiciel (paragraphes 12.2 et 12.1 de l'avis). Concernant diverses fonctions, l'expert a également fait référence au fait qu'elles étaient développées de faible qualité (articles 2.5, 7.3, 10.10-10.5). Cependant, l'expert a précisé en réponse aux questions de clarification qu'il n'avait pas examiné tous les éléments du système, mais s'était plutôt concentré sur les revendications soulevées dans le tableau soumis par les parties, et que d'autres éléments avaient été examinés concernant la nature du système tel que détaillé dans l'avis (p. 5 en réponse aux questions de clarification).
- Cela incluait l'expert soulignant que le système avait été construit sans versionnement de code (une fonction similaire à « suivre les modifications » dans un document), ce qui est essentiel pour permettre la récupération en cas de dysfonctionnement, qui a effectué le changement et pourquoi ; comme aide au développement futur (article 12.4). Il a été noté que c'est aujourd'hui la norme pour tout développement professionnel. L'expert a également souligné que le système a été développé sans gestion de version de développement permettant de surveiller l'ensemble du système et de décrire les modifications de la version, ce qui est essentiel pour partager entre les développeurs, administrateurs et parties intéressées les modifications apportées au système et leur date (section 12.5).
Je note qu'il n'y a aucune raison de préférer les explications de Shmulik selon lesquelles cela n'était pas requis plutôt que l'avis d'expert au nom de la cour. Le témoignage de Shmulik est le seul témoignage d'un plaideur, et il n'y a aucune justification à sa préférence sur l'avis d'expert, qui a laissé une impression très professionnelle (p. 180 de la transcription aux pages 4-5 ; p. 238 de la transcription aux paragraphes 1-6). En fait, la conclusion probable des preuves est que Shmulik a travaillé avec la gestion des versions (GIT) à un moment donné, contrairement à son témoignage, mais a tenté de le dissimuler. Lors du contre-interrogatoire, Shmulik a d'abord témoigné qu'il ne travaillait pas avec la gestion des versions, et lorsqu'il a demandé à se référer à la correspondance datée du 30 mai 2018 dans laquelle il écrit qu'il définit GIT pour le programmeur (P/3, p. 13, message de 15:37), il a répondu que « ce n'est pas nécessaire » et qu'il ne s'en souvient pas, « mais il se peut qu'il n'ait pas été utilisé car nous ne l'avons pas défini, il n'était pas nécessaire au final » (p. 180, s. 8, 15-16). Cette réponse ne satisfait pas plusieurs raisons. Premièrement, aucune explication n'a été donnée quant aux raisons pour lesquelles Shmulik a utilisé la définition de Git selon la correspondance et pourquoi, bien qu'il ait utilisé cette définition, elle n'a pas été utilisée lors de son témoignage. Deuxièmement, c'est le seul témoignage d'un plaideur qui n'a pas laissé une impression positive sur son témoignage. Troisièmement, les prévenus se sont abstenus de convoquer le programmeur Michal, qui est un témoin clé, à témoigner. Quatrièmement, la conduite des défendeurs, qui avant la procédure avaient refusé aux demandeurs l'accès au système, et aussi, dans la procédure elle-même, ont tenté de les empêcher d'accéder au système dans le but de l'examiner, même si l'activité commerciale était négligeable à l'époque, comme le montre l'avis de l'expert (p. 24), soutient la conclusion de dissimulation (compte tenu de la faible qualité et des problèmes découlant de l'avis de l'expert).
- L'expert estimait également qu'il y avait de la confusion et de l'instabilité dans le système car dans « l'environnement produit » du logiciel (celui qui a réellement été utilisé), des essais et erreurs étaient réalisés, aucun vestige d'expériences n'était nettoyé et les données expérimentales étaient mélangées avec des données réelles. L'expert a expliqué qu'en cas de développement approprié, les essais et erreurs sont réalisés dans un environnement de développement séparé, seuls le code final et les données réelles étant transférés dans « l'environnement produit » afin que cet environnement soit fiable et exempt de problèmes. L'expert a également expliqué que même s'il existait un environnement de développement (preuve de son existence mais supprimée par une société de stockage), cela ne change pas sa conclusion car un travail a été effectué dans l'environnement produit alors qu'il aurait dû être effectué dans un environnement de développement (article 12.6 conjointement avec la p. 21 pour répondre aux questions de clarification).
- L'expert a également souligné que le système avait été construit sans tests automatisés, qui sont une norme professionnelle acceptée pour les systèmes à logique complexe, afin de garantir que le noyau du système fonctionne comme requis (Section 12.7). L'expert au nom des défendeurs a témoigné que les tests automatisés dans l'environnement WordPress ne sont pas courants (p. 69 de la transcription aux paragraphes 20-29), mais l'avis de l'expert du tribunal devrait être préféré. L'expert de la cour a laissé une impression très sérieuse et professionnelle, comme indiqué, et en tant qu'expert au nom de la cour, il faut accorder un poids considérable à son opinion. D'un autre côté, l'expert des défendeurs a justifié son opinion concernant la qualité du système sur des fondements solides, pour le moins, comme l'a expliqué l'expert du tribunal. Ainsi, par exemple, l'expert au nom des défendeurs peut apprendre la complexité et la qualité du système à partir de la portée des lignes de code écrites, où la majeure partie du code provient de plugins génériques développés par des tiers. Il a également invoqué la satisfaction des utilisateurs comme preuve de qualité, mais il s'est avéré que la satisfaction alléguée reposait sur des données sélectives et une fausse représentation de celles-ci, alors qu'en réalité l'activité dans le système était marginale après un an (pp. 24-25 de l'avis d'expert ; p. 20 en réponse aux questions de clarification ; p. 72 de la transcription aux paras. 10-12). Cela risque de nuire au poids du témoignage et à l'avis d'expert en faveur des défendeurs.
- L'expert a également expliqué qu'il est courant de s'appuyer sur un système open source incluant des composants gratuits, lorsque le composant prêt à l'emploi correspond parfaitement aux besoins ou lorsque les développeurs savent comment ajuster le composant de manière professionnelle. L'expert note que les principaux éléments ne répondaient pas exactement aux besoins et que l'ajustement n'a pas été effectué par un professionnel, et a noté à titre d'exemple le problème mentionné précédemment qu'il a identifié, qui permet de regarder les parcours gratuitement.
- L'expert estimait également que le système n'était pas maintenu par des professionnels. L'expert a expliqué que dans un système open source, les pirates ont intérêt à détecter des faiblesses de sécurité et, pour protéger le système contre cela, il est nécessaire d'effectuer une maintenance supplémentaire des plugins prêts à l'emploi installés et d'acheter un code de licence afin de recevoir des corrections de bugs et des mises à jour de sécurité des développeurs des plugins. L'expert a cependant constaté que les composants clés fonctionnent sans licence permettant de recevoir des mises à jour de la part de ces développeurs, et que la solution pour recevoir les mises à jour via un logiciel appelé nobuna.com pose des difficultés car il s'agit d'une solution indirecte tierce (et non directement du fabricant officiel du plugin) et met donc le site en danger (p. 23 de l'avis, pp. 8-9 et 22 en réponse aux questions de clarification).
- Dans la conclusion de l'avis, l'expert exprime son avis selon lequel les caractéristiques existantes du système ne fonctionnent pas de manière fiable ; Le système a été construit de manière non professionnelle et de faible qualité (il existe des défauts et des faiblesses en matière de fiabilité, de confidentialité et de sécurité), et il a été conçu sans un processus de développement ordonné. Sa conclusion finale fut qu'il s'agissait « d'un système non standard avec une fonctionnalité altérée ».
- Je note que, pour répondre à la question du tribunal, si l'expert avait été invité à examiner le système et à organiser ce qui était requis, quelle aurait été la signification en termes de coûts et de ressources en temps, l'expert a répondu : « Je n'aurais pas pris le temps de régler le système existant. Il vaut mieux réécrire » et plus tard « C'est un désordre atomique » - non pas à cause de la difficulté de faire écrire le code par quelqu'un d'autre, mais « après avoir vérifié que j'avais vu les problèmes » (p. 90 de la transcription aux paras. 11-18), lorsqu'en réponse à la question de l'avocat des défendeurs, il a précisé que c'était « la considération économique du client quant cela vaut pour lui d'investir » dans les réparations et en tenant compte du coût de reconstruction du système, ce qui n'arrivera pas : de l'ordre de 50 000 à 100 000 ILS (où 100 000 ILS est le prix pour un travail excellent) (p. 90 de la transcription, pp. 73-74).
- Il convient de noter que les conclusions de l'expert concernant la faible qualité du développement du système sont étayées par la correspondance en temps réel d'Alexandra avec l'un des pigistes ayant travaillé sur le code, un programmeur indien (nommé Subash Poudel), dans lequel il écrit qu'il voit que le site a été construit sans prendre en compte la rapidité, la qualité du code et l'incompatibilité des plugins (Annexe 34 p. 485 pour les preuves de Werber) :
Je vois que le site a été construit sans tenir compte de la vitesse, de la qualité du code et de l'incompatibilité entre plugins et thèmes.