Commission, 5 mars 2008, n° M.4747

I. INTRODUCTION

1.   Le 29 août 2007, la Commission a reçu notification, conformément à l’article 4 et à la suite d’un  renvoi  en  application  de  l’article  4,  paragraphe  5,  du  règlement  (CE)  n° 139/2004 du Conseil (ci-après dénommé « le règlement sur les concentrations »), d’un projet de concentration par lequel l’entreprise International Business Machines Corporation (ci-après dénommée « IBM », États-Unis) acquiert au sens de l’article 3, paragraphe 1, point b), du règlement du Conseil, le contrôle de l’ensemble de  l’entreprise Telelogic AB (ci-après dénommée « Telelogic », Suède) au moyen d’une offre publique d’achat annoncée le 11 juin 2007.

2.   À l’issue d’un examen de la notification, la Commission a conclu, le 3 octobre 2007, que l’opération notifiée entrait dans le champ d’application du règlement sur les concentrations et qu’elle soulevait des doutes sérieux quant à sa compatibilité avec le marché commun et le fonctionnement de l’accord EEE. C’est la raison pour laquelle elle a engagé la procédure prévue à l’article 6, paragraphe 1, point c), du règlement sur les concentrations.

3.   Afin de procéder à un examen approfondi de l’opération notifiée, la Commission a envoyé à IBM, le 19 octobre 2007, une demande de renseignements conformément à l’article 11, paragraphe 3, du règlement sur les concentrations. Comme IBM n’a pas fourni les renseignements corrects et complets dans les délais fixés par la demande de renseignements, la Commission a adopté une décision le 15 octobre 2007 en application de l’article 11, paragraphe 3), du règlement sur les concentrations demandant les renseignements nécessaires pour l’évaluation de l’opération de concentration et suspendant les  délais  prévus  par  le  règlement  sur  les  concentrations  à  compter  du 5 novembre 2007. À la suite de la communication de la réponse d’IBM à la demande de renseignements de la Commission, les délais prévus par le règlement ont recommencé à courir le 3 décembre 2007.

4.   Le comité consultatif a examiné le projet de la présente décision le 20 février 2008.

II. LES PARTIES

5.   IBM (ci-après dénommée «la partie notifiante»), entreprise américaine, conçoit, produit et vend dans le monde entier une vaste gamme de produits, logiciels et services dans le domaine des technologies de l’information (ci-après dénommées «TI»). Dans le caédre de ses diverses activités logicielles, IBM conçoit et vend des outils de développement logiciel, c'est-à-dire des logiciels qui servent à la conception et à la mise en oeuvre d'applications logicielles.

6.   Telelogic est une entreprise suédoise qui conçoit et vend des outils de développemet logiciel4.

III. L’OPÉRATION

7.   Le 11 juin 2007, IBM a annoncé publiquemet son intention de faire une offre publique d’achat pour l’ensemble du capital-actions de Telelogic. L’offre ‘IBM est subordonnée, entre, à :  i) l’acquisition par  IBM d’au  moins  90 %  du  capital  émis  de  Telelogic, et

ii) l’approbation des autorités antitrust pertinentes. Par conséquent, après l’achèvement de l’opération de concentration proposée, IBM aura le contrôle exclusif de l'ensemble de Telelogic grâce à une participation d'au moins 90 %.

IV.  LA CONCENTRATION

8.   L’opération de concentration proposée comporte l’acquisition du contrôle exclusif de Telelogic par IBM. Elle constitue donc une concentration au sens de l’article 3, paragraphe 1, point b) du règlement sur les concentrations.

V. DIMENSION COMMUNAUTAIRE

9.   La concentration notifiée n’atteint pas les seuils de chiffre d’affaires fixés à l’article 1, paragraphes 2 et 3 du règlement sur les concentrations.

10.  Le 28 juin 2007, la Commission a reçu une demande de renvoi de la partie notifiante conformément à l’article 4, paragraphe 5, du règlement sur les concentrations, qui a été transmise à l’ensemble des États membres. Puisque la concentration notifiée est susceptible  d’être  examinée  en   vertu   du   droit   national   de   la   concurrence   de 10 États membres différents et puisqu’aucun d’entre eux n’a exprimé son désaccord sur la demande de renvoi de l’affaire à la Commission dans les délais définis à l’article 4, paragraphe 5, la concentration est réputée avoir une dimension communautaire.

VI.   MARCHÉS EN CAUSE

 VI.1.   Marchés de produits en cause

 VI.1.1.  Définition des marchés de produits

11.  La concentration proposée affecte l’industrie des outils de développement logiciel. Ce type d’outils sert à créer de nouvelles applications logicielles et à développer les applications existantes. Plus spécifiquement, ces outils ont pour but d’améliorer l’efficacité du processus de développement logiciel. Dans un document interne d’IBM, les outils de développement logiciel sont définis comme « une catégorie de logiciels qui aide les organisations à créer et gérer des ressources logicielles tout au long de leur

cycle de vie. Ces ressources se rapportent aux applications, aux services logiciels et aux logiciels embarqués dans des dispositifs ou des systèmes »*5.

12.  IBM et Telelogic offrent toutes deux des outils de développement logiciel. Dans la décision d’engager la procédure, il a été conclu préliminairement que la concentration proposée soulevait des doutes sérieux quant à sa compatibilité en ce qui concerne deux marchés de produits possibles : les outils de gestion des exigences et les outils de modélisation basés sur l’UML6.

13.  L’enquête approfondie menée par la Commission a largement confirmé que les outils de gestion des exigences et les outils de modélisation compatibles avec l’UML doivent être considérés comme des marchés de produits en cause; toutefois, elle a également  montré que pour un certain nombre de raisons, la définition des marchés de produits en cause doit être traitée avec beaucoup de prudence dans la présente affaire. Afin de mieux comprendre les raisons motivant cette prudence, une vue d’ensemble des principales caractéristiques du marché va d’abord être présentée.

VI.1.2. Caractéristiques d’ l’industrie des outils de développement logiciel

 VI.1.2.1. Le cycle de développement logiciel

14.  Le processus de développement logiciel peut être segmenté en cinq étapes principales. Différentes catégories d’outils aident les clients à chacune de ces étapes.

15.  La première étape correspond à l’analyse conceptuelle nécessaire pour déterminer les fonctionnalités qui doivent être fournies par une nouvelle application logicielle. Les outils d’analyse (souvent dénommés outils de « gestion des exigences ») facilitent ce processus en permettant le recueil, la structuration, le stockage, la gestion et le suivi ultérieur des exigences de l’utilisateur tout au long du processus de développement. Comme l’explique un cabinet d’analystes du secteur, Forrester: « L’objectif de la  gestion des exigences est de maximiser les chances qu’une application fonctionne  comme prévu et que l’entreprise bénéficie de la valeur prévue de cette application ». Forrester définit la gestion des exigences comme: « Le stockage des exigences, le suivi

des relations entre les exigences et le contrôle des changements apportés à une exigence individuelle et à des groupes d’exigences »7.

16.  Une fois que la la fonctionnalité requise de l’application logicielle a été déterminée, les détails sur l’architecture logicielle sont ensuite mis au point durant l’étape de modélisation (ou conception). Alors que durant l’étape d’analyse, la question à laquelle il faut répondre est: « Quelle fonction le logiciel devrait-il remplir? », durant l’étape de conception/modélisation, la question à laquelle il faut répondre est: « Comment le logiciel devrait-il remplir la fonction déterminée? ». Les outils de modélisation assistent les   clients   dans   diverses   tâches,   y   compris    la    création    de    modèles    visuels («diagrammes »), les définitions de données et les spécifications de programmation. Certains outils de modélisation peuvent utiliser ces modèles et ces informations associées pour générer automatiquement un code source de logiciel. Selon le niveau de détail présent dans les modèles, les résultats varient et peuvent aller de simples structures de code (qui doivent ensuite être remplies manuellement) à un code complet qui ne nécessite pas d’intervention humaine supplémentaire.

17.  Après avoir été conçu et modélisé, le logiciel d’application doit être mis en œuvre. L’étape de mise en œuvre (ou construction ou codage) se compose essentiellement de l’écriture du code de logiciel (programmation). Cette étape s’accomplit principalement à l’intérieur d’un outil d’environnement de développement intégré («IDE»: Integrated Development Environment), une application logicielle qui facilite l’écriture du code de logiciel. Tel que mentionné ci-dessus, certains outils de modélisation peuvent automatiquement générer l’ensemble ou une partie du code source. Dans leur forme la plus simple, les outils de construction fournissent des fonctionnalités d’édition et de compilation nécessaires pour convertir des langages de programmation de haut niveau, tels que C, C++, COBOL ou Java, en langage de niveau inférieur qui peut être facilement exécuté par la plateforme de déploiement visée.

18.  Une fois qu’il a été écrit, le logiciel d’application doit être testé pour identifier les erreurs («débogage») et pour s’assurer que le logiciel fonctionnera avec succès sur la plateforme de déploiement visée, telle que par exemple les systèmes d’exploitation  Windows, Linux ou UNIX. Des outils de test spécialisés offrent un moyen automatique d’effectuer ces tests, alors que certaines fonctionnalités de test basiques sont parfois fournies soit directement par les outils de modélisation soit à partir de l’environnement IDE.

19.  Finalement, durant et après le processus de développement logiciel, les développeurs doivent collaborer pour livrer et mettre à niveau l’application logicielle. Les équipes de développement logiciel peuvent aller de quelques personnes – pour des projets simples – à plusieurs centaines de personnes travaillant simultanément dans des lieux différents pour les projets les plus sophistiqués. La collaboration entre les développeurs de  logiciels se déroule généralement sur un réseau qui relie tous les collaborateurs et qui implique des ordinateurs serveurs spécialisés, par exemple pour garder la trace du code de logiciel produit ou pour s’assurer que les différentes parties d’une application en cours de développement restent synchronisées. Les outils de gestion d’équipe, souvent dénommés outils de «gestion de la configuration (& du changement) du logiciel» («SCCM» ou «SCM» : Software (Change &) Configuration Management), permettent à des parties de l’application logicielle d’être stockées et extraites tout en fournissant également des fonctions de notification relatives au contrôle et au changement de version.

VI.1.2.2. Logiciels d’application des TI et logiciels de systèmes

20.  Le processus de développement logiciel décrit ci-dessus est pertinent pour le développement de deux types de logiciels principaux: les logiciels d’application des TI et les logiciels de systèmes. Les logiciels d’application des TI sont des logiciels conçus pour fonctionner sur un système d’exploitation standard ou une plateforme standard et sont généralement installés sur un ordinateur universel (par ex., en ce qui concerne une entreprise, un serveur générique exécutant un système d’exploitation serveur de Linux ou Windows ou, en ce qui concerne les clients, des ordinateurs de bureau ou des ordinateurs portables standard). Ce type de logiciel est généralement destiné à l’interaction des utilisateurs finaux; il permet aux utilisateurs finaux d’accomplir des tâches spécifiques. Les logiciels d’application des TI incluent une large gamme de programmes qui, entre autres, comprennent: i) des logiciels de productivité personnelle (traitements de texte, tableurs, etc.), et ii) des logiciels d’entreprise (gestion de la masse salariale, gestion de la relation client, gestion de la chaîne logistique, etc.).

21.  Par contre, les logiciels de systèmes sont des logiciels qui gèrent et contrôlent les composants matériels de sorte que les logiciels d’application des TI puissent accéder à ce matériel pour accomplir une tâche. En tant que tels, les logiciels de systèmes sont étroitement liés aux composants matériels qui peuvent être destinés soit à un usage général (par ex., un PC ou serveur générique) soit à un usage non général (par ex., des systèmes de télécommunications, des systèmes dans le domaine de l’aérospatial ou de la défense, des systèmes d’instrumentation médicale). En général, les utilisateurs finaux n’ont pas de contact direct avec ce type de logiciel.

22.  Parmi les logiciels de systèmes, une sous-catégorie de logiciels embarqués peut être identifiée. Contrairement aux logiciels de systèmes généraux, les logiciels embarqués sont spécifiquement écrits pour des composants matériels spécialisés avec lesquels ils sont intégrés (embarqués). En tant que tels, ils font partie intégrante du système (ou sous-système) avec lequel ils sont fournis. Contrairement aux logiciels d’application des TI, le rôle principal des logiciels embarqués n’est pas de permettre aux utilisateurs  finaux d’accomplir une tâche, mais plutôt de gérer et contrôler l’interaction des composants matériels dans lesquels ils sont intégrés avec des facteurs externes (par ex., la lumière, la pression, la vitesse, etc.). On trouve généralement les logiciels embarqués dans les voitures, les téléphones mobiles, les appareils médicaux, etc.

23.  Les logiciels embarqués peuvent devenir très sophistiqués dans des systèmes complexes tels que des avions, des missiles et des satellites. Dans ces systèmes complexes, les logiciels embarqués doivent interagir avec de nombreux autres sous-systèmes. Certains logiciels embarqués doivent fonctionner avec des contraintes de temps strictes («en temps réel»). Dans ces cas-là, les logiciels embarqués fonctionnent généralement sur des systèmes d’exploitation spécifiques, nommés systèmes d’exploitation en temps réel («RTOS »: Real-Time Operating System)8, par opposition aux systèmes d’exploitation standard que l’on trouve dans les ordinateurs universels, tels que les serveurs Windows. Certains logiciels embarqués accomplissent également des missions cruciales de sécurité. Dans ces cas-là, les outils de développement logiciel utilisés pour développer ces logiciels sont homologués par des autorités de sécurité, comme par exemple l’Autorité fédérale américaine de l’aviation ou l’Agence européenne de la sécurité aérienne.

VI.1.2.3. Fournisseurs d’outils de développement logiciel

24.  Les fournisseurs d’outils de développement logiciel sont extrêmement divers et incluent tous les types de sociétés, depuis les petites sociétés non cotées qui ne vendent qu’un à deux outils jusqu’aux très grandes sociétés informatiques qui possèdent un important portefeuille de logiciels, comprenant une offre d'outils de développement logiciel plus  ou moins étendue (par ex., ibm, Hewlett Packard («HP»), Oracle et Microsoft). La division des outils de développement logiciel d’IBM se nomme IBM Rational depuis

l’acquisition de Rational en 20039. Le produit de gestion des exigences d’IBM est Requisite Pro et ses principales familles de produits de modélisation sont Rational Software Architect («RSA»: Rational Software Architect)10 et Rational Rose. La famille de produits Rational Rose inclut Rational Rose Enterprise, Rational Rose XDE, Rational Modeler et Rose Technical Developer. Ces produits sont des logiciels hérités, c’est-à- dire qu’ils ne sont pas constamment mis à jour et activement vendus par IBM à de nouveaux clients. Par conséquent, la plus grande partie des revenus d’IBM sur ces produits provient de la maintenance et du support11.

25.  Entre ces deux extrémités, les autres fournisseurs (y compris Telelogic) sont des sociétés de taille moyenne possédant quelques outils de développement logiciel dans leur portefeuille de produits. Les principaux produits de Telelogic sont: Doors, Focal Point, Rhapsody, TAU, Synergy, Statemate, SDL Suite et System Architect, qui représentent ensemble presque la totalité du chiffre d’affaires de Telelogic, soit 175,87 millions EUR en 2006. Le principal produit de gestion des exigences de Telelogic est DOORS et ses principaux outils de modélisation sont Rhapsody, TAU, Statemate et SDL Suite, les deux derniers produits étant des produits hérités12. Telelogic a acquis Rhapsody grâce à l’acquisition d’I-logix en 2006.

26.  Les fournisseurs vendent leurs outils soit directement par l’intermédiaire de leur propre force de vente, soit indirectement par l’intermédiaire d’intégrateurs de systèmes. Les fournisseurs, y compris IBM et Telelogic, organisent généralement leurs forces de vente dans différentes régions géographiques du monde, en affectant des forces de vente spécialisées dans ces régions. Dans ces régions, certaines de ces forces de vente peuvent également se spécialiser afin de s’occuper de grands clients, de secteurs industriels ou de groupes  de  produits  spécifiques.  Par  exemple,  IBM  a  un  […]*  dans  sa division «Amériques» et un […]* dans sa division Europe du Sud-ouest, Moyen-Orient et Afrique. De manière similaire, Telelogic a des directeurs des ventes spécialisés pour […]* respectivement dans sa division Europe, Moyen-Orient et Afrique et un directeur des ventes spécialisé pour […]* dans sa division Asie Pacifique13.

27.  Les intégrateurs de systèmes sont des fournisseurs de services indépendants qui sont spécialisés dans la construction de systèmes informatiques complets au nom de clients tiers, en rassemblant des composants de différents fournisseurs de matériel et de logiciels14.

VI.1.2.4. Clients d’outils de développement logiciel

28.  Selon l’objectif pour lequel ils utilisent les outils de développement logiciel, les clients peuvent être répartis en trois catégories principales.

29.  Les clients acquérant des outils de développement logiciel pour créer ou mettre à jour  des applications logicielles adaptées à leurs besoins spécifiques constituent la première catégorie de clients. Les applications logicielles développées par ces clients ne sont pas destinées à la commercialisation. Ces clients utilisent les outils de développement logiciel pour développer des applications logicielles des TI ou des logiciels de systèmes/embarqués. Dans le premier cas, les clients sont généralement actifs dans les secteurs des technologies de l’information, de l’administration publique et des services (par ex., la distribution/le commerce de détail, les transports, la banque/la finance/les assurances, etc.), alors que dans le second cas, ils sont généralement actifs dans les secteurs industriels et techniques (par ex., l’aérospatiale/la défense, l’automobile, l’énergie, les télécommunications, les instruments médicaux, l’électronique, etc.).

30.  Au niveau opérationnel, cela se traduit par différents profils d’utilisateurs: les logiciels d’application des TI sont développés par des développeurs de logiciels en collaboration avec des analystes en informatique/en informatique de gestion et des spécialistes en architecture logicielle, alors que les logiciels de systèmes sont développés par des analystes organiques en collaboration avec des analystes fonctionnels et des ingénieurs systèmes15.

31.  Dans ce contexte, il est utile de mentionner que les clients industriels/techniques utilisent souvent des outils de gestion des exigences et des outils de modélisation dans le cadre  du développement de systèmes techniques (y compris leurs composants matériels et logiciels), et pas spécifiquement le développement logiciel. En effet, la conception et le développement de systèmes techniques, notamment des systèmes importants et complexes, implique de passer par les mêmes étapes d’analyse et de modélisation que lors du développement logiciel.

32.  Comme l’explique la partie notifiante: «Alors que la majeure partie de l’industrie des logiciels utilise la modélisation comme un moyen permettant aux  équipes  de comprendre et de communiquer ce que le logiciel accomplit et de quelle manière son architecture est réalisée, les ingénieurs qui désirent valider leurs modèles de systèmes

complexes utilisent également souvent des modèles exécutables pour décrire le comportement réel (c’est-à-dire la logique) des logiciels»16.

33.  De manière similaire, en ce qui concerne les outils de gestion des exigences, IBM explique: «DOORS est un outil de pointe ‘centré sur les bases de données’ qui est conçu pour des projets complexes comportant des processus élaborés hautement structurés qui impliquent un grand nombre d’exigences ainsi qu’un processus dynamique pour l’analyse des exigences. DOORS est généralement utilisé par les ingénieurs systèmes (par ex. pour le développement d’un système aérospatial). Inversement, Requisite Pro

est un outil léger ‘centré sur les documents’ et les TI généralement utilisé par les analystes en informatique de gestion»17.

34.  Les clients qui acquièrent les outils de développement logiciel pour leurs propres besoins internes le font soit directement, éventuellement avec l’aide de consultants externes, soit indirectement, par l’intermédiaire d’intégrateurs de systèmes.

35.  Les fournisseurs de logiciels indépendants («ISV»: Independent software vendors) constituent la seconde catégorie de clients des outils de développement logiciel. Les ISV sont des sociétés spécialisées dans le développement et la commercialisation de  logiciels. Généralement, les ISV développent et vendent des applications logicielles des TI.

36.  La dernière catégorie de clients est composée des intégrateurs de systèmes qui acquièrent des outils de développement logiciel au nom de leurs clients, ainsi que d’autres composants logiciels et matériels.

VI.1.2.5. Structure de fixation des prix

37.  Le coût d’acquisition d’un outil de développement logiciel pour le client inclut les composantes suivantes: le coût de la licence; les coûts de maintenance et de support et les coûts de mise en œuvre (c’est-à-dire le coût d’installation, de configuration, d’intégration et de personnalisation de l’application). Alors que les coûts de licence et de maintenance/support correspondent aux revenus dévolus au fournisseur de logiciels, les coûts d’installation et de mise en œuvre ne génèrent pas nécessairement de revenus pour le fournisseur de logiciels; cela dépend de la personne ou l’entreprise qui effectue le travail.

38.  Les fournisseurs de logiciels utilisent différents modèles de concession de licence. Une première distinction essentielle peut être établie entre les licences perpétuelles et les licences basées sur une durée. Une licence perpétuelle est un achat unique suivi de paiements annuels pour la maintenance, alors que la licence basée sur une durée est un logiciel avec un droit d’utilisation pour une période de temps spécifique18. Au-delà de cette distinction générale, les modèles de concession de licence sont généralement basés sur le nombre d’utilisateurs nommés ou simultanés («postes») et la situation géographique de ces utilisateurs.

39.  En ce qui concerne les parties, IBM offre aux clients le choix entre deux modèles de licences perpétuelles: i) une licence d’«utilisateur autorisé», qui permet l’utilisation de la licence par un seul utilisateur et ii) une «licence flottante», qui permet l’utilisation de la même licence par plusieurs membres d’une équipe indépendamment de leur situation géographique, à condition que le nombre total d’utilisateurs simultanés ne dépasse pas le nombre de licences flottantes achetées19.

40.  Les modèles de licences de logiciels de Telelogic offrent aux clients le choix entre les licences perpétuelles ou les licences basées sur une durée avec trois options  principales:

i)  une licence « à nœud verrouillé », qui permet l’utilisation du logiciel par un utilisateur non spécifique sur une machine identifiée; ii) une licence « par utilisateur », qui permet l’utilisation du logiciel par un utilisateur spécifique sur n’importe quelle machine reliée par réseau au serveur de licence et iii) diverses licences « flottantes », qui permettent l’utilisation de la licence par l’ensemble des utilisateurs dans diverses configurations géographiques («site unique », « plusieurs sites », « continental » et « mondial ») à condition que le nombre d’utilisateurs simultanés ne dépasse pas le nombre de licences flottantes achetées20.

41.  La maintenance englobe généralement les mises à niveau des versions, la livraison automatique de correctifs et différents niveaux de support. La maintenance est généralement facturée séparément des droits de licence. Par exemple, la structure des frais de maintenance de Telelogic correspond à un pourcentage du prix catalogue ([…] du prix catalogue selon le niveau de support)21. Toutefois, les droits de licence d’IBM incluent une année de maintenance et de support standard pour un coût qui correspond à […]* des droits de licence notionnels sans le support22.

42.  En outre, il existe également des modèles d’abonnement dans le cadre desquels les  clients acquièrent le droit d’utiliser les produits logiciels et de bénéficier de la maintenance et du support pendant une période de temps limitée. Pour ce modèle, la valeur des droits de licence ne peut pas être déterminée indépendamment de la maintenance et du support23.

43.  Finalement, les fournisseurs accordent généralement […]* ou des remises aux clients. Les niveaux de remise peuvent être élevés dans l’industrie des outils de développement logiciel24. Par exemple, les règles de Telelogic […]* permettent des remises qui peuvent aller jusqu’à […]* de remise sur le prix catalogue pour les droits de licence et au delà de […]* sur les frais de maintenance généralement facturés25. Des remises peuvent être accordées soit dans le cadre d’un accord global soit sur la base d’un contrat.

44.  L’enquête approfondie a indiqué que le coût, y compris les coûts de licence, de maintenance, de support et de déploiement, est l’un des critères de choix les plus importants pour les clients qui développent des applications logicielles des TI. Par contre, le coût est un critère beaucoup moins décisif pour les sociétés actives dans les secteurs industriels/techniques qui mettent davantage l’accent sur les critères techniques liés aux caractéristiques du produit (par ex., la fonctionnalité du produit, sa conformité aux normes, son extensibilité, sa fiabilité/maturité et l’intégration avec d’autres outils, etc.), à son support après-vente et, dans certains cas, aux références du fournisseur, à sa réputation et à l’importance qu’il attache à l’outil26. Les documents confidentiels internes soumis par plusieurs grands clients industriels ont révélé que le critère lié au coût représentait 30 % ou moins dans leur processus de sélection des outils, par rapport  à 60 % ou plus pour les critères liés aux aspects techniques. […]* «le prix a tendance   à

être une considération plus importante pour le développement d’applications des TI que pour le développement de systèmes»27.

VI.1.2.6. Processus d’acquisition

45.  Les clients acquièrent des outils de développement logiciel dans trois cas principaux :

i)  pour de nouveaux projets ; ii) suite à une initiative de standardisation et iii) pour des projets existants.

46.  La pluart des clients acquièrent des outils sur la base d’un projet, ce qui signifie que les outils sélectionnés ne serviront que pour un projet spécifique. Dans ces cas-là, la sélection des outils est souvent effectuée à un niveau inférieur au sein de l’organisation, c’est-à-dire par le service ou l’équipe responsable du projet.

47.  Certains clients - principalement les grandes organisations généralement actives dans les secteurs techniques/industriels - ont standardisé leur acquisition d’outils de développement logiciel. L’objectif de ces efforts de standardisation est de rationaliser  les décisions d’achat de la société afin de maximiser les remises accordées par les fournisseurs et de faciliter la coopération entre les différentes unités commerciales ou divisions dans l’ensemble de la société. Les sociétés qui ont standardisé leur politique d’acquisition ont généralement d’abord effectué un processus d’évaluation approfondie des divers outils disponibles sur le marché par rapport à des critères techniques reflétant leurs besoins au niveau de la société. Le résultat de ce processus d’évaluation est l’établissement d’une liste d’outils « recommandés » ou « préférés » (habituellement un pour chaque catégorie de produits) qui peuvent être facilement acquis par les unités opérationnelles ou les équipes de projets, même si dans certains cas elles peuvent également se procurer d’autres outils. Cette standardisation est commune aux clients qui ont besoin d’outils de développement logiciel pour développer des logiciels de systèmes/embarqués complexes (par ex., des clients actifs dans l’industrie aérospatiale  & l’industrie de la défense).

48.  Finalement, les clients acquièrent également des outils de développement logiciel pour leurs projets existants soit quand leurs licences basées sur une durée expirent (renouvellement) ou quand de nouveaux membres de l’équipe doivent être ajoutés pour des raisons de mise à niveau ou d’extension (ajouts). Dans ces cas-là, le client acquiert généralement des licences (supplémentaires) des outils déjà utilisés pour le projet existant et n’envisage pas d’autres outils. Par conséquent, il n’y a aucune concurrence dans le cadre de l’acquisition d’outils de développement logiciel pour des projets existants.

49.  Quand un client a un nouveau projet ou quand il a décidé de procéder à une standardisation du processus d’acquisition, il doit d’abord établir ses besoins internes. Ce processus peut être long et complexe dans le cas de grandes organisations ayant plusieurs unités commerciales ou filiales actives dans diverses industries. Par conséquent, il doit s’informer sur les produits qui pourraient éventuellement répondre à ses besoins. Généralement, le client doit d’abord établir une longue liste de produits (habituellement de 5 à 20 produits) sur la base des informations rendues publiquement disponibles par les fournisseurs, sans évaluation/test préalable du client. Les produits sont ensuite sélectionnés suite à une première évaluation interne de base par les clients. Les sélections incluent généralement de 2 à 5 produits différents. Seuls les produits sélectionnés sont ensuite entièrement évalués et testés (présentation détaillée par les fournisseurs, tests, démonstrations, etc.). Ce processus de sélection est essentiellement axé sur l’évaluation des caractéristiques des produits. C’est un processus  d’apprentissage pour le client, qui est nécessaire en raison de l’hétérogénéité des nombreux produits disponibles.

VI.1.2.7. Produits individuels et suites

50.  Différents outils peuvent aider les clients à chaque étape du processus de développement logiciel  décrit  ci-dessus.  Les  «produits  individuels»  (également  nommés «meilleursproduits») fourissent une foctionnalité individuelle et aident donc les clients à une étape spécifique du processus de développement logiciel. Les produits individuels sont des produits autonomes qui sont vendus indépendamment comme des soloutions distinctes. IDC, un cabinet d’analyses du secteur, définit les produits individuels de la manière suivante : «Un produit individuel est un logiciel destiné à une seule fonction ou à un

ensemble très limité de fonctions qui est vendu séparément, par opposition à une suite»28.

51.  Par contre, certains outils, souvent nommés «suites», peuvent aider les clients à plusieurs étapes du processus de développement. Les suites apparaissent comme des offres groupées de plusieurs outils logiciels ayant des fonctionnalités différentes et complémentaires dans le processus de développement logiciel. IDC définit les suites de la manière suivante : «Une suite est une combinaison de produits, de modules et de services logiciels pour fournir un ensemble plus complet de fonctionnalités logicielles et pour éliminer l’activité redondante. Souvent, la combinaison est accomplie du point   de

vue de l’informatique intégrée, mais tout aussi souvent, la combinaison est purement théorique du point de vue du marketing»29.

52.  IDC explique également que «Il est courant dans l’industrie des logiciels que les nouvelles technologies apparaissent d’abord sur le marché sous la forme de produits uniques autonomes. Avec le temps, ces produits finissent souvent par devenir des fonctions/caractéristiques de produits plus généraux ou de suites de produits»30.

VI.1.2.8. Interopérabilité des outils de développement logiciel

53.  Il n’existe pas d’outil unique qui fournisse l’ensemble des différentes fonctionnalités requises à chaque étape du processus de développement logiciel mentionné ci-dessus. Etant donné qu’une partie importante des clients a tendance à avoir une politique de

«choix des combinaisons», c’est-à-dire la combinaison de plusieurs produits individuels, l’interopérabilité entre les outils de développement logiciel des différents fournisseurs est une question essentielle dans l’industrie et une question à laquelle les clients accordent une attention particulière. Par conséquent, les fournisseurs de logiciels sont incités à s’assurer que la gamme la plus large possible de logiciels peut être utilisée en combinaison avec leurs propres logiciels, ce qui permet de créer […]* un    «écosystème

de partenaires commerciaux» […]*31, qui les rendent attrayants pour les clients.

54.  L’interopérabilité entre les produits logiciels des différents fournisseurs est accomplie soit grâce à l’utilisation de formats de fichiers communs (qui permettent à l’application d’un fournisseur de lire et comprendre ce que l’application d’un autre fournisseur a écrit) soit par l’intermédiaire d’interfaces de programmation d’applications («API»: Application Programming Interfaces) qui offrent la possibilité d’accéder aux données d’une application et de les extraire d’une manière structurée selon les objectifs de l’utilisateur. Par exemple, un outil de gestion des exigences peut fournir un API qui permette à d’autres applications d’ordonner à l’outil de gestion des exigences de sélectionner  un  certain  nombre  d’exigences  selon  une  condition  spécifiée  et ensuite d’exporter toutes les informations associées à ces exigences dans un format standard spécifique. Cet API permet à une autre application de s’intégrer de manière continue à l’outil de gestion des exigences parce qu’aucune intervention humaine n’est nécessaire pour faire travailler les deux outils ensemble, et ils fonctionnent comme si leur interopérabilité avait été prévue à l’origine.

55.  Afin de faciliter l’interopérabilité, les fournisseurs peuvent donc soit donner un accès direct aux informations d’interopérabilité du logiciel exclusif soit favoriser le développement de normes communes. Par exemple, Eclipse32, créé par IBM en 2001, est une plateforme qui fournit une technologie facilitant le développement d’outils de développement logiciel qui interopèrent les uns avec les autres. Le Groupe de gestion  des objets (Object Management Group)33, créé par onze fournisseurs de logiciels, y compris IBM, qui est responsable de la définition et de la maintenance du langage de modélisation unifié («UML») est un autre exemple de l’effort de normalisation des fournisseurs.

VI.1.2.9. Logiciels commerciaux et logiciels libres

56.  Une autre caractéristique de l’industrie des outils de développement logiciel (et de l’industrie des logiciels dans son ensemble) est l’émergence et le développement rapide de logiciels dits «libres». Les logiciels libres sont des logiciels avec un code source disponible sous licence qui permet aux développeurs d’utiliser, de changer et d’améliorer les logiciels et de les redistribuer sous une forme changée ou non changée34. Cette accessibilité entraîne la création de communautés de développeurs qui collaborent pour développer des outils logiciels.

57.  Les logiciels libres sont généralement offerts gratuitement, mais de nombreuses sociétés offrent des services de support commercial pour certains produits libres35. Toutefois, comme cela est indiqué dans la décision d’engager la procédure, les outils de développement  de  logiciels  libres  ne  sont  pas  encore  perçus  par  les  grands clients

industriels comme une alternative crédible aux outils logiciels commerciaux parce qu’ils n’offrent pas de garanties suffisantes en termes de stabilité, de maintenance et d’amélioration. En effet, ces produits gratuits ne sont généralement pas pris en charge par les fournisseurs commerciaux mais par une communauté de développeurs privés36.

58.  Les avantages et inconvénients des logiciels libres sont résumés de la manière suivante dans […]*37:

Tableau 1: Les avantages et inconvénients principaux des logiciels libres sont généralement homogènes dans l’ensemble des types de logiciels.

 VI.1.3. Marchés en cause pour l’évaluation de la présente concentration

59.  Dans une décision précédente, la Commission a laissé ouverte la question de savoir s’il existe un marché global pour les outils de développement logiciel ou si des marchés de produits distincts dans le domaine des outils de développement logiciel doivent être définis38.

60.  Dans la décision d’engager la procédure, il a été conclu préliminairement que les marchés de produits en cause sur lesquels la concentration proposée pourrait avoir un impact concurrentiel significatif sont les suivants :

·  le marché concernant les outils de modélisation sur l’UML, correspondant à la catégorie Conception & analyse orientées objet («OOA&D») de Gartner, que ce marché soit subdivisé ou non en outils pour les applications des TI et en outils pour les logiciels de systèmes;

· le marché concernant les outils de gestion des exigences, correspondant à la catégorie Gestion des exigences de Gartner, que ce marché soit subdivisé ou non en outils pour les applications des TI et en outils pour les logiciels de systèmes.

61.  Gartner est un cabinet d’analystes du secteur qui fournit des données de marché, des recherches et des analyses sur le secteur des technologies de l’information, y compris le domaine des outils de développement logiciel. En particulier, Gartner produit des segments de marché sur la base desquels il établit la taille des marchés et les parts de marché des fournisseurs. Dans des décisions précédentes, la Commission s’est appuyée sur la segmentation de Gartner afin de définir les marchés de produits en cause dans le secteur des TI39. Dans la décision d’engager la procédure, il a été conclu préliminairement que la segmentation des outils de développement logiciel de Gartner constituait un cadre approprié pour l’analyse de l’impact concurrentiel de la concentration proposée40.

62.  La partie notifiante soutient que la catégorie OOA&D et la catégorie de gestion des exigences de Gartner ne constituent pas des marchés de produits en cause parce qu’elles ne prennent pas suffisamment en compte i) les produits libres et ii) la fonctionnalité de modélisation et de gestion des exigences intégrée dans les suites. En outre, en ce qui concerne la modélisation, la catégorie OOA&D de Gartner ne prendrait pas suffisamment en compte les outils de modélisation qui ne sont pas conformes à l’UML. Finalement, IBM estime qu’aucun marché de produits distinct ne devrait être défini sur la base des types de logiciels développés (logiciels d’application des TI ou logiciels de systèmes) ou par les marchés verticaux de l’industrie.

63.  Chacune de ces questions est traitée en détail ci-dessous.

VI.1.3.1. Produits libres

64.  En règle générale, les produits libres gagnent en popularité dans l’industrie des logiciels en général, ainsi que dans certains domaines de l’industrie des outils de développement logiciel. Toutefois, l’enquête approfondie a indiqué que, en ce qui concerne les outils de modélisation et de gestion des exigences, les clients considèrent que les produits libres constituent des alternatives crédibles aux logiciels commerciaux principalement pour les petits projets de développement logiciel, mais pas pour les projets importants et complexes41. Les principales raisons avancées par les clients pour ne pas utiliser les outils libres pour les grands projets sont: i) le manque de maintenance et de support,   ii)

les fonctionnalités insuffisantes, iii) le manque de maturité, (iv) les craintes concernant  la durabilité des outils, (v) l’absence d’interfaces/d’interopérabilité avec d’autres outils et (vi) l’absence de politique ou de stratégie au sein de la société en ce qui concerne l’utilisation des logiciels libres.

65.  En ce qui concerne l’évolution de la politique des clients vis-à-vis des outils libres, l’enquête approfondie a révélé que certains clients pourraient augmenter l’utilisation de ces outils au cours des deux à trois prochaines années, principalement pour de petits projets pour lesquels l’utilisation des logiciels commerciaux n’est pas toujours rentable. Toutefois, la majorité des clients n’ont pas l’intention de changer significativement leur politique vis-à-vis des outils libres parce qu’ils considèrent que le problème des limites actuelles d’utilisation de ces outils, notamment leurs fonctionnalités insuffisantes et leur manque de maintenance et de support, ne pourrait pas être traité efficacement dans ce laps de temps42. Comme l’explique un grand client dans le secteur de l’énergie: «Nous avons examiné les outils libres mais nous ne prévoyons pas de les utiliser car le manque de maintenance et de support limiterait notre capacité à les utiliser»43. La principale exception à cette caractéristique générale concerne les cas où de grands clients sophistiqués développent eux-mêmes des logiciels libres, comme le projet Topcased44 développé par Airbus et plusieurs autres sociétés et des universités, visant à créer un nouvel outil de modélisation libre.

66.  L’enquête approfondie a également révélé que les fournisseurs d’outils commerciaux considèrent généralement que leurs logiciels commerciaux ne sont guère en concurrence avec les produits de modélisation et de gestion des exigences libres en ce qui concerne les grands projets45. Comme le fait observer un fournisseur d’outils de modélisation:

«Artisan n’est pas en concurrence avec les outils libres sur nos marchés car ces outils libres ont rarement accès aux grands modèles/grandes équipes et ont donc peu de connaissances sur ces modèles/équipes»46.

67.  Le résultat de l’enquête approfondie concorde avec un récent […]*[…]*47 qui présente les «facteurs déterminants» et les «freins» à l’adoption des logiciels libres:

"Facteurs déterminants

·   Coût initial bas

·   Modularité indépendance et flexibilité

·   Une communauté de logiciels libres pour faciliter l’innovation

·   Une multitude de développeurs qui ont appris à programmer les logiciels libres dans les universités

·   Innovation; pas besoin de repartir à zéro si cela correspond à l’application

Freins

·   Qualité (installation et configuration du pilote)

·   Manque de fiabilité et de support»

  68.  La partie notifiante ne conteste pas le fait que la pression concurrentielle exercée par les logiciels libres sur les outils de développement de logiciels exclusifs, quoique  croissante, est encore limitée en ce qui concerne les outils de gestion des exigences. En effet, […]* a expliqué que: «les solutions libres commencent de plus à plus à représenter une concurrence dans le segment inférieur du marché»48, ce qui peut laisser supposer que la concurrence entre les logiciels libres et les logiciels commerciaux dans le segment supérieur du marché est beaucoup plus limitée.

69.  Comme cela a été noté ci-dessus, l’enquête approfondie a clairement confirmé que les clients ne considèrent pas les logiciels libres comme une alternative crédible aux outils de gestion des exigences commerciaux. En fait, la plupart des clients ne savent pas  qu’il existe des logiciels libres avec une fonctionnalité de gestion des exigences et lorsqu’ils le savent, ils considèrent que leurs caractéristiques techniques ne répondent pas à leurs besoins.

70.  En ce qui concerne les outils de modélisation, […]* a déclaré que «bien que les outils libres n’aient pas encore une portée aussi importante que certains produits commerciaux, ils exercent quand même une pression concurrentielle très importante sur ces produits, notamment en Europe»49. […]* avance également que «Même si […]*

reconnaissent que le support commercial peut être limité actuellement, les données disponibles semblent indiquer que cela va changer à l’avenir. Par exemple, […]* et […]* disposent toutes deux d’un support commercial pour leurs outils de modélisation libres»50.

71.  Comme cela a été noté ci-dessus, l’enquête approfondie a révélé que l’une des principales raisons pour lesquelles les clients ne considèrent pas les logiciels libres comme une alternative crédible aux logiciels de modélisation commerciaux (du moins pour les projets complexes) est notamment le manque de maintenance et de support. […]*.

72.  Une autre raison qui, d’après les témoignages des clients, limite l’utilisation des outils de modélisation libres pour le développement de logiciels complexes est que les fonctionnalités de ces produits sont limitées et ne répondent donc pas à leurs besoins. Comme le fait remarquer Qinetiq, un client actif dans le secteur de la défense: «Les outils de modélisation libres sont appropriés pour de petits projets de recherche dynamiques mais pas pour le support aux projets en temps réel et pour le support aux grands projets impliquant plusieurs sites. Nous avons également besoin que le fournisseur offre un support pour nos outils standard et un calendrier de lancement clair des produits. Ces critères ne sont pas facilement disponibles pour  les  outils libres» 51.

73.  L’évaluation des outils de modélisation libres faite par les clients est partagée par les fournisseurs52. Comme l’explique un petit fournisseur: «Il y a eu récemment certaines initiatives en ce qui concerne l’UML libre, notamment de la part d’Airbus (TopCased)  et de CEA (Papyrus). Ces initiatives en sont encore à un stade précoce et sont tout à fait confidentielles  à  ce  stade.  Airbus  et  CEA  ne  sont  pas  des  fournisseurs  d’outils de modélisation, l’impact sur le marché jusqu’à présent est donc négligeable. D’autres initiatives incluent Star UML, Gentleware et de nombreuses autres sociétés, mais nous considérons qu’à ce jour, aucune d’entre elles n’est apparue comme une alternative crédible»53.

74.  Fait intéressant, un fournisseur de support commercial pour les outils de modélisation libres a expliqué que: «Les projets de logiciels libres développant un outil complet (et non une infrastructure pour construire des outils) que nous suivons actuellement sont:

ArgoUML, basé sur UML 1.3, en grande partie compatible avec UML 1.3, et Papyrus, basé sur UML 2, en grande partie compatible avec UML 2.0. Aucun n’est disponible dans le commerce ou n’est vendu par un fournisseur. Ils peuvent être utilisés pour apprendre l’UML et dans le cadre de projets d’étudiants. Ils ne concurrencent pas réellement les outils professionnels, cependant»54.

75.  Finalement, il faut noter que selon Gartner: «Les outils de modélisation de système libres basés sur les spécifications du Langage de modélisation unifié sont encore trop peu évolués pour les environnements hétérogènes ou répartis, mais devraient être intéressants pour les petites équipes centralisées»55.

76.  Dans l’ensemble, il semblerait que les outils de modélisation et de gestion des exigences libres et commerciaux soient actuellement en concurrence directe uniquement en ce qui concerne le segment inférieur du marché, c’est-à-dire pour les petits projets de développement logiciel. Bien que l’on ne puisse pas exclure que la concurrence va augmenter dans un avenir proche en ce qui concerne le segment moyen du marché, c’est-à-dire pour les projets de développement logiciel plus complexes, il est très peu probable que les outils commerciaux subissent une pression concurrentielle réelle de la part des produits libres dans les deux à trois années à venir en ce qui concerne le  segment supérieur du marché, c’est-à-dire pour les projets de développement logiciel complexes.

VI.1.3.2. Produits individuels et suites

77.  Dans l’industrie des outils de développement logiciel, comme dans de nombreux autres domaines relatifs aux logiciels, les fournisseurs ajoutent de plus en plus de fonctionnalités à leurs produits individuels et les vendent comme des suites intégrées.

78.  En particulier, de plus en plus d’outils fournissent des caractéristiques de modélisation et de génération de codes intégrées de sorte que le code source de l’application logicielle est automatiquement généré à partir des modèles. Comme l’indique Forrester: «Avec de meilleurs langages, de meilleurs cadres d’applications, de meilleures classes d’objet, de meilleurs DSL56 et de meilleurs modèles textuels et visuels, il devient de plus en plus difficile de dire où un outil de modélisation de logiciel finit et où des langages de programmation commencent»57. Microsoft Visual Studio58, Oracle JDeveloper, Sun Netbeans, IBM RSA, Telelogic Rhapsody, Computer Associates AllFusion, entre autres, sont des exemples d’outils fournissant des caractéristiques de modélisation plus ou moins complètes accompagnées d’une fonctionnalité de génération de codes59.

79.  De manière similaire, la fonctionnalité de gestion des exigences est de plus en plus incluse dans les logiciels offrant des fonctionnalités de test, ainsi que des fonctionnalités de gestion de configuration et de modification, tels que HP QualityCenter, MKS Integrity, Rally Software Development, Kovair Global Lifecycle. Ces produits sont souvent nommés outils de gestion du cycle de vie des applications («ALM»: Application Lifecycle Management) car ils ont pour objectif de fournir une solution de bout en bout pour gérer le cycle de vie des applications logicielles60.

80.  En outre, de plus en plus d’outils de gestion du cycle de vie des produits («PLM» : Product Lifecycle Management), tels que notamment Siemens UGS TeamCenter, Oracle Agile Product Data Management et Dassault MatrixOne, incluent également des capacités de gestion des exigences. Les outils de PLM aident à gérer les descriptions et les propriétés d’un produit à travers son développement et sa durée de vie utile, essentiellement du point de vue commercial/technique61. Pour cette raison, les outils PLM avec des caractéristiques de gestion des exigences intégrées font concurrence principalement aux outils individuels traditionnels de gestion des exigences dans le segment des logiciels de systèmes/embarqués (voir ci-dessous).

81.  Suite à l’évolution décrite ci-dessus, les clients des outils de développement logiciel ont de plus en plus le choix entre des produits individuels et des suites. En règle générale, les suites constituent des produits de substitution imparfaits ou approximatifs des produits individuels car ils n’offrent pas le même niveau de fonctionnalité que les produits individuels. Généralement, les suites constituent des solutions attrayantes principalement pour les clients qui étudient des solutions minimisant les problèmes d’interopérabilité qui peuvent résulter de la combinaison d’outils provenant de fournisseurs différents ou pour ceux qui cherchent à réduire les coûts d’acquisition des outils de développement logiciel. Par contre, les grands clients, qui ont tendance à avoir une politique de «choix des combinaisons», sélectionnent généralement les produits individuels qui répondent le mieux aux besoins à chaque étape individuelle du processus

de développement logiciel et les combinent ensuite soit par leurs propres moyens internes soit avec l’aide d’intégrateurs de systèmes ou de consultants62.

82.  Tel qu’indiqué dans la décision d’engager la procédure63, la capacité de modélisation des IDE est généralement perçue par les clients comme faible par rapport à celle  des produits individuels de modélisation64. Toutefois, l’enquête approfondie a révélé que certains outils, notamment ceux des parties (Telelogic Rhapsody et IBM RSA) ainsi que par exemple Mathworks Matlab/Simulink, Borland Together, Kennedy Carter iUML et Artisan Studio, quoique pas nécessairement classés comme des IDE, sont considérés par les clients comme des logiciels de développement reposant sur des modèles avec de fortes capacités de modélisation et de génération de codes65. Ce point a également été confirmé par les fournisseurs66, et par les documents internes de Telelogic, lorsque l’on compare en détail les capacités respectives de modélisation et de génération de codes de Rhapsody et RSA67.

83.  En ce qui concerne la gestion des exigences, l’enquête approfondie a indiqué  que certains outils ALM et PLM, y compris Siemens UGS TeamCenter et HP QualityCenter, sont considérés par les clients comme des alternatives crédibles aux produits individuels traditionnels de gestion des exigences, notamment pour le développement de logiciels de systèmes et le développement de systèmes68. Cette constatation a été confirmée par les fournisseurs69.

84.  En outre, les documents de […]* indiquent qu’elle considère certains outils ALM et  PLM (MKS Integrity70, HP QualityCenter71 et Siemens UGS TeamCenter72) comme des concurrents directs de son […]* produit individuel de gestion des exigences ([…]*). Les documents […]* indiquent également que les produits PLM concurrencent de plus en plus les produits individuels traditionnels de gestion des exigences dans le domaine des systèmes.  Par  exemple,  il  est  indiqué  dans  un  document  interne  d’IBM  que    «La

convergence de plusieurs marchés entraîne l’apparition de nouveaux terrains de jeux verticaux. Les PLM et les logiciels convergent dans le segment industriel. SAP/ Dassault/Oracle sont plus que jamais au centre des préoccupations»73.

85.  Forrester résume la convergence entre les produits individuels traditionnels de gestion des exigences et les outils ALM de la manière suivante : «Les capacités de gestion des exigences à l’intérieur des solutions ALM sont celles qui ont le plus de potentiel. Les outils de gestion des exigences ont tant de points communs avec d’autres outils de gestion du cycle de vie qu’il n’est pas logique d’en faire des offres indépendantes. Alors

que les fournisseurs améliorent les capacités de gestion des exigences dans leurs plateformes ALM, cette option se rapproche de plus en plus de l’idéal»74.

86.  En outre, l’enquête approfondie a révélé qu’une grande partie des clients a l’intention d’accroître leur utilisation des suites avec des fonctionnalités de modélisation et de gestion des exigences intégrées au cours des deux à trois prochaines années, y compris pour des projets importants et complexes. En effet, les clients ont indiqué qu’ils s’attendent à ce que ces deux fonctionnalités soient mieux intégrées dans les suites dans un avenir proche75. Comme l’a expliqué un client actif dans le secteur de l’aérospatial:

«Nous avons l’intention de nous orienter vers des suites pour le support aux projets en temps réel et pour le support aux grands projets impliquant plusieurs sites. Cela permettra de profiter du développement logiciel de bout en bout (c’est-à-dire à partir des exigences, grâce à la conception, la mise en œuvre, les tests, la gestion de la configuration  et  la  livraison  dans  la  même  suite  de  produits).  Les  suites      seront

probablement mieux intégrées dans 2/3 ans de sorte que les avantages de l’utilisation des suites augmenteront»76.

87.  Pour conclure, bien que la concurrence soit généralement plus intense entre les produits individuels et les suites (notamment en ce qui concerne les clients importants et sophistiqués), certaines suites constituent des alternatives crédibles aux produits individuels de modélisation et de gestion des exigences, principalement pour le développement de logiciels de systèmes et le développement de systèmes. On peut s’attendre à ce que la concurrence entre les produits individuels et les suites offrant des fonctionnalités de modélisation et de gestion des exigences augmente au cours des prochaines années.

VI.1.3.3. Outils de modélisation UML et non UML

88.  L’un des principaux problèmes examinés dans la décision d’entreprendre la procédure concernait la question de savoir si un marché de produits en cause distinct pour les produits de modélisation UML devrait être identifié. La conclusion préliminaire de la décision était que les outils de modélisation UML constituaient en effet un marché de produits séparé. Cette constatation préliminaire était fondée sur les réponses fournies par les clients et les fournisseurs aux demandes de renseignements envoyées durant l’enquête préliminaire77, qui corroboraient la définition de la catégorie OOA&D par Gartner78.

89.  UML peut être mieux dépeinte comme un langage de modélisation général, ouvert et standard. Il est officiellement défini par un organisme indépendant (le Groupe de gestion des objets). Depuis le lancement de sa première version en 1997, l’UML est de plus en plus largement accepté et est devenu selon Gartner la norme de facto pour la modélisation orientée objets. La modélisation orientée objets est un paradigme de modélisation qui permet la décomposition d’un problème principalement sous la forme d’un ensemble d’« objets » liés qui interagissent.

90.  En tant que langage général utilisant des concepts spécifiques, l’UML ne traite pas spécifiquement   de   problèmes   particuliers   qui   surviennent   dans   chaque industrie individuelle79. Pour cette raison, il souffre d’un désavantage visible par rapport aux langages de modélisation à domaine spécifique («DSML») ciblant des industries spécifiques80.

91.  En revanche, l’UML est utilisé par une plus grande communauté de développeurs et d’ingénieurs et est supporté par un plus grand nombre de fournisseurs que n’importe quel langage DSML. Il permet à des modèles développés avec un seul outil d’être importés dans l’outil d’un autre fournisseur81. Pour ces raisons, l’UML est particulièrement attrayant pour les clients qui désirent éviter d’être tributaires d’un fournisseur donné, ou d’un groupe limité de fournisseurs, ainsi que pour les grandes sociétés qui désirent faciliter la coopération entre leurs différentes unités commerciales et leurs différents départements.

92.  La partie notifiante soutient que «en termes de définition du marché, il n’existe pas de chaîne de substitution continue couvrant à la fois les outils de modélisation UML et les outils de modélisation non UML avec diverses fonctionnalités». En particulier, IBM explique que: «L’UML est un langage de modélisation général de très grande portée englobant l’analyse (Modélisation fonctionnelle), la conception (Modélisation architecturale) et la mise en œuvre (Modélisation comportementale). Alors que les autres langages de modélisation ont une portée similaire (par ex., SysML,    SDL, IDEF,

et AADL), la plupart des langages non UML se concentrent sur un aspect de la modélisation (fonctionnelle, architecturale ou comportementale). […]*82.

93.  L’enquête approfondie a révélé que les outils de modélisation UML ne sont pas perçus par une grande partie des clients industriels/techniques comme entièrement interchangeables avec les outils non UML (c’est-à-dire principalement les outils DSLM)83. La principale raison avancée par ces clients est que chaque type d’outil a ses propres  avantages  et  est  donc  utilisé  pour  des  projets  ou  besoins  différents.     Par

conséquent, la plupart des clients techniques/industriels ont indiqué qu’ils ne basculeraient pas vers des outils non UML dans le cas d’une augmentation de prix permanente de 10 % des outils UML84.

94.  Contrairement à ce qui précède, l’opinion des clients utilisant des outils de modélisation pour le développement de logiciels d’application des TI, principalement actifs dans le

95.  La grande majorité des fournisseurs d’outils de modélisation a également indiqué que les outils UML et les outils non UML ne sont pas entièrement interchangeables du point de vue du client, essentiellement parce qu’ils se concentrent sur différentes fonctions86. En particulier, une grande partie des fournisseurs d’outils non UML ont expliqué qu’ils ne considèrent pas que leurs produits soient en concurrence étroite avec les outils UML87.

96.  À cet égard, l’enquête approfondie a révélé que les outils de modélisation basés sur des langages mathématiques exclusifs, tels que Mathworks Simulink, Esterel Studio et dSpace TargetLink, n’offrent pas une alternative, mais complètent plutôt les  outils UML. Alors que ces derniers peuvent être dépeints comme des outils de modélisation généraux, les premiers sont mieux dépeints comme des outils de conception ou de simulation. Cette constatation concorde avec la position de Venture Development Corporation («VDC»), un cabinet d’analystes du secteur, qui distingue les outils de modélisation UML utilisés pour le développement de systèmes et de  logiciels  embarqués et les «outils de conception de systèmes dynamiques basés sur des langages exclusifs [qui] ont l’intention d’automatiser le processus de conception et de  simulation

des systèmes dynamiques qui impliquent des conceptions d’algorithmes complexes représentant le comportement de phénomènes physiques complexes»88.

97.  En outre, l’enquête approfondie a indiqué que les outils UML ne constituent pas une alternative aux outils non UML utilisés pour le développement de logiciels ou de systèmes conformes à des normes industrielles spécifiques89.

98.  Toutefois, il faut noter que la distinction entre les outils de modélisation UML et les outils de modélisation non UML apparaîtrait trop simpliste si elle ne reflétait le fait que certains outils, quoique n’étant pas des outils UML au sens strict, sont néanmoins compatibles avec l’UML. C’est surtout le cas pour les outils qui sont basés sur des profils  UML,  tels  que  SysML90,  Executable  UML91   et  UPDM92:  Business   Profile Modelling Notation En effet, UML 2.0 et les versions ultérieures offrent des  mécanismes de personnalisation, sur la base desquels des dérivés UML adaptés à certains domaines spécifiques (nommés « profils » ou « stéréotypes ») ont été développés93. La version UML actuelle est UML 2.1.1 (mise à jour d’août 2007)94.

99.  En outre, certains outils basés sur des DSML exclusifs sont néanmoins compatibles avec l’UML car ils utilisent des interfaces ouvertes qui les rendent interopérables avec l’UML (par ex. Esterel Studio).

100.  Par conséquent, bien que les outils UML et les outils non UML ne soient généralement pas perçus par les acteurs du marché comme des alternatives crédibles, certains outils non UML sont néanmoins compatibles avec l’UML. Ces outils peuvent donc être considérés comme des produits de substitution plus proches des outils UML que les outils non UML purs pour certaines applications finales ou pour certains groupes de clients. Comme indiqué ci-dessus, c’est surtout le cas pour les clients utilisant des outils de modélisation pour le développement de logiciels d’application des TI pour lesquels les outils basés sur BPMN constituent une alternative crédible aux outils UML. Comme le fait observer Gartner: «UML peut être utilisé pour la modélisation d’entreprise, mais la norme de Notation de modélisation des processus d’entreprise (BPMN) du Groupe de

gestion des objets (OMG) est plus appropriée pour l’analyse des processus d’entreprise»95.

101.  Toutefois, il est nécessaire dans le cadre de la présente affaire de conclure à l’existence d’un marché de produits distinct pour les outils de modélisation UML. Néanmoins, les éléments mentionnés ci-dessus concernant le degré de concurrence entre les outils UML et non UML sur le marché devraient être pris en compte pour l’évaluation de la présente concentration du point de vue de la concurrence.

VI.1.3.4. Clients de TI et clients de systèmes

102.  La partie notifiante ne considère pas qu’il existe des marchés distincts pour les outils utilisés par les développeurs de logiciels embarqués. IBM a expliqué dans la notification que: «Bien que certains fournisseurs commercialisent des outils spécifiques pour développer des logiciels embarqués, la grande majorité des développeurs de logiciels embarqués utilise en fait les mêmes outils que ceux utilisés pour le développement de logiciels d’application des TI ou de logiciels embarqués (comme le fait Microsoft, entre autres). Pour la plupart des produits, il y a peu de différences fonctionnelles entre les outils de TI génériques et les outils commercialisés pour les développeurs de logiciels

 103.  D’emblée, il mérite d’être souligné que la distinction entre le développement de logiciels d’application des TI et le développement de logiciels de systèmes/embarqués est largement reconnue par plusieurs analystes du secteur97, et par IBM elle-même. Quand on lui a demandé d’expliquer les raisons économiques de la concentration, IBM a expliqué dans la notification que «Le mariage de l’expertise complémentaire des parties dans les domaines du développement de logiciels de systèmes et du développement de logiciels d’applications des TI va permettre à IBM d’offrir une gamme complète d’outils de développement logiciel»98.

104.  Les différences entre le développement de logiciels d’application des TI et le développement de logiciels de systèmes/embarqués se traduisent par des besoins différents significatifs des clients en termes de fonctionnalités et de caractéristiques des outils de développement logiciel. Ce point a été reconnu par IBM en ce qui concerne à  la fois les outils de modélisation et de gestion des exigences. Dans un document soumis au cours de l’enquête approfondie, IBM a expliqué que seulement […]* des critères qu’IBM elle-même a identifiés comme pertinents pour comparer les outils de modélisation sont tout aussi importants pour le développement de logiciels d’application des TI et le développement des logiciels de systèmes, alors que cette proportion serait de […]* pour les outils de gestion des exigences99.

105.  En outre, il faut noter que, dans le même document, IBM a identifié […]*  caractéristiques du produit comme les «caractéristiques indispensables spécifiques aux logiciels d’application des TI» pour les outils de gestion des exigences […]* et […]* caractéristiques différentes du produit comme les «caractéristiques indispensables spécifiques aux logiciels de systèmes» […]*100.

106.  En ce qui concerne les outils de modélisation, IBM, dans le même document, a identifié les […]* caractéristiques suivantes du produit comme les «attributs les plus importants pour le développement de logiciels d’application des TI»: […]*.

107.  Par  contre,  IBM  a  identifié  les […]* caractéristiques suivantes  du produit  comme les

«attributs les plus importants pour le développement de logiciels de systèmes»: […]*101.

108.  Une comparaison de ces deux listes révèle que le développement de logiciels d’application des TI et le développement de logiciels de systèmes ne partagent que […]* des «attributs les plus importants» en ce qui concerne les outils de modélisation ([…]*).

109.  En reflétant ces différences entre les besoins des clients des logiciels d’applications des TI et les besoins des clients des logiciels de systèmes, il est clair que certains outils de modélisation et de gestion des exigences sont mieux adaptés au développement de logiciels d’application des TI ou au développement de logiciels de systèmes/embarqués. Comme cela est indiqué ci-dessus (voir le considérant 33), IBM a expliqué que l’outil de gestion des exigences de Telelogic, Doors, est «généralement utilisé par les ingénieurs systèmes», alors que son propre outil de gestion des exigences, RequisitePro, est un «outil axé sur les logiciels d’application des TI». En outre, Telelogic a récemment lancé un nouvel outil léger de gestion des exigences, Doors FastTrack, ciblant spécifiquement le segment des TI102. Inversement, IBM a lancé un sous-ensemble de ses nouveaux  outils de modélisation RSA (nommé RSD) ciblant le segment des logiciels de systèmes/embarqués103.

110.  Toutefois, il est nécessaire dans le cadre de la présente affaire de conclure à l’existence d’un marché de produits distinct pour les outils de développement logiciel utilisés pour le développement de logiciels d’application des TI et le développement des logiciels de systèmes. Néanmoins, les éléments mentionnés ci-dessus indiquent que cette distinction est un élément important à prendre en compte pour l’évaluation de la présente concentration du point de vue de la concurrence.

VI.1.3.5. Groupes de clients

111.  Au-delà de la distinction de haut niveau entre les logiciels d’application des TI et les logiciels techniques/de systèmes, la partie notifiante a également soutenu dans la notification qu’il n’est pas logique de distinguer les outils de développement logiciel en fonction des différents groupes de clients. IBM fournit l’explication suivante: «différents types de clients (fournisseurs indépendants de logiciels, intégrateurs de systèmes et développeurs en entreprise) utilisent les mêmes outils de développement logiciel. […]*. De même, les clients cherchent à maximiser la valeur de leur investissement dans les outils à travers l’ensemble de leurs projets de développement, qu’il s’agisse de grands projets ou de petits projets. Souvent le même outil peut être utilisé pour différents

projets même si la fonctionnalité complète de l’outil n’est pas utilisée»104.

112.  En dépit de la déclaration ci-dessus dans la notification, IBM, dans un document soumis au cours de l’enquête approfondie, n’a pas contesté le fait que différents marchés verticaux de l’industrie pouvaient être distingués sur la base de la spécificité de leurs besoins en relation avec les outils de modélisation et de gestion des exigences.

113.  Dans un document […]*, IBM a expliqué […]*: «Un ensemble de classement distinct a été développé pour mettre en évidence le poids relatif des critères pour les […]* principales  catégories  industrielles:  […]*.  À  titre  d’exemple  des  besoins divergents

entre les différents secteurs industriels, le support pour le langage de programmation ADA est souhaitable dans […]* mais pas pour les autres secteurs industriels»105.

114.  Dans ce même document, IBM a décrit en détail les différences entre les […]*  principaux groupes de clients pour les outils de modélisation et de gestion des exigences […]* en termes de poids relatif des caractéristiques des produits106.

115.  Toutefois, il est nécessaire dans le cadre de la présente affaire de conclure à l’existence de marchés de produits distincts pour les outils de développement logiciel selon les différents groupes de clients ou les différents marchés verticaux de l’industrie. Néanmoins, les éléments mentionnés ci-dessus indiquent que cette segmentation des groupes de clients est un élément important qui doit être pris en compte pour  l’évaluation de la présente concentration du point de vue de la concurrence.

VI.1.3.6. Diversité des produits et des besoins des clients

116.  Bien que la gestion des exigences et la modélisation puissent être clairement identifiées comme des étapes différentes tout au long du processus de développement logiciel et  que des fonctionnalités spécifiques soient fournies par des outils individuels durant ce processus, les frontières exactes des marchés de produits en cause pour ces deux catégories d’outils sont difficiles à déterminer pour quatre raisons principales.

117.  D’abord, les capacités de gestion des exigences ou de modélisation sont de plus en plus regroupées avec d’autres fonctionnalités fournies à l’intérieur de suites intégrées. Comme cela est indiqué ci-dessus, l’enquête approfondie a révélé que certains (mais pas l’ensemble) de ces suites constituent des alternatives crédibles aux produits individuels traditionnels de modélisation et de gestion des exigences, pour certaines catégories de clients. Deuxièmement, les outils de modélisation et de gestion des exigences libres offrent des alternatives aux logiciels commerciaux dans le segment inférieur du marché, mais pas dans le segment supérieur du marché. Troisièmement, en ce qui concerne les outils de modélisation, les outils UML concurrencent les outils non UML pour certaines applications finales et pour certains clients, mais pas pour l’ensemble d’entre eux. Quatrièmement, même dans des catégories de produits étroitement définies, une grande diversité d’outils existe, comme le montrent les différences de prix importantes entre les divers outils, allant de la quasi-gratuité pour un outil libre à plusieurs milliers d’euros pour la licence d’un outil perfectionné. Il y a également des différences de prix très importantes entre les outils commerciaux.

118.  Par exemple, en ce qui concerne les outils de modélisation, […]* a expliqué que «alors qu’une licence Rhapsody peut coûter jusqu’à […]*, un produit équivalent est disponible chez Artisan pour environ […]* et chez Borland pour environ […]*. […] NoMagic offre un produit concurrent pour environ […]*. Poseidon Community Edition de  Gentleware

est disponible pour un coût aussi modique que […]*. Sparx Systems[…]*, […] offre une gamme complète de fonctionnalités pour environ […]*»107.

119.  En ce qui concerne les outils de gestion des exigences, […]* a expliqué que: «MKS offre sa licence flottante Integrity pour environ […]* et la licence flottante d’IraQ coûte environ […]*. Par comparaison, une licence flottante DOORS coûte entre […]* et […]*. Le prix catalogue de VersionOne débute à […]* et serait fourni à 30 sociétés figurant au classement de Fortune 100. Collab.NET offre des produits sophistiqués à partir de […]*»108.

120.  En fait, la grande diversité des outils de modélisation et de gestion des exigences reflète l’hétérogénéité des besoins des groupes de clients en relation avec ces deux catégories d’outils. En effet, il y a peu de points communs entre les besoins d’une petite société développant une nouvelle application de TI et ceux d’une grande société aérospatiale développant des applications logicielles embarquées sophistiquées pour un nouvel avion militaire. Alors que la première a généralement besoin d’un outil «rapide à maîtriser et facile à utiliser», la seconde cherche un outil perfectionné fournissant des fonctionnalités approfondies associées à des services de maintenance et de support de haut niveau. Bien que les outils de modélisation et de gestion des exigences utilisés par ces deux types de sociétés aient un ensemble principal de caractéristiques communes et puissent donc être classés comme des outils de modélisation et de gestion des exigences, ils ne peuvent pas être considérés comme des produits de substitution proches.

121.  En outre, comme cela est expliqué ci-dessus, entre ces deux extrémités du spectre, les différents groupes de clients ont des besoins extrêmement divers en termes de caractéristiques des produits et ceux-ci dépendent essentiellement du secteur industriel dans lequel ils sont actifs.

VI.1.4.   Conclusion concernant la définition du marché du produit concerné

122.  Bien que l’identification des outils de modélisation et de gestion des exigences en tant que marchés distincts dans la décision d’instaurer des poursuites semble confirmée par l’enquête approfondie, les limites exactes des marchés concernés (c.-à-d. dont les produits sont considérés comme interchangeables par les consommateurs) sont difficiles à établir. La raison première en est la grande diversité d’outils de modélisation et de gestion des exigences disponible sur le marché, qui est l’une des conséquences de l’hétérogénéité des besoins des consommateurs en relation avec ces outils.

123.  Compte tenu de ce qui précède, la définition du marché de produits dans la présente affaire peut uniquement nous donner un cadre assez vague pour l’évaluation concurrentielle de l’opération proposée. En effet, différents produits logiciels entrant dans la même catégorie de produits, bien qu’ils fournissent la même fonctionnalité principale d’un point de vue abstrait, ne peuvent constituer de véritables substituts du point de vue d’un consommateur. De plus, différents éléments pouvant ne pas indiquer l’existence de marchés de produits distincts doivent être pris en compte dans le cadre de l’évaluation concurrentielle. Cet aspect concerne en particulier des éléments comme l’hétérogénéité des produits et les différences entre les divers besoins des clients.

VI.2. Marché géographique en cause

124.  La partie notifiante souligne que les marchés géographiques pertinents dans cette affaire sont mondiaux. Dans une décision antérieure relative aux outils de développement de logiciels, la Commission a établi que la portée géographique des marchés pertinents correspondait au minimum à l’EEE109.

125.  L’enquête approfondie a indiqué qu’à part la personnalisation de la langue, les fournisseurs proposent les mêmes outils de modélisation et de gestion des exigences  dans le monde entier110, et que les clients ont tendance à acheter les mêmes produits  pour leurs différentes divisions ou centres de profits, indépendamment de leur situation géographique111. Bien qu’il semble qu’il existe certaines différences de prix entre l’UE et les autres grandes régions du monde, ces différences reflètent principalement les différences d’appréciation des devises, ce qui explique notamment pourquoi les prix aux États-Unis sont quelque peu inférieurs à ceux de l’UE112.

126.  Néanmoins, la définition exacte des marchés géographiques pertinents peut être laissée ouverte pour le moment, étant donné que la conclusion d’une évaluation concurrentielle demeure inchangée, qu’il s’agisse d’une définition mondiale ou restreinte à l’UE.

VII. COMPATIBILITÉ AVEC LE MARCHÉ COMMUN ET L’ACCORD EEE

127.  La décision d’engager une procédure relevait les trois théories du préjudice suivantes :

A.  hausses unilatérales des prix,

B.  baisse des incitations à l’innovation,

C.  diminution de l’interopérabilité des outils logiciels.

VII.1. Hausses unilatérales des prix

 VII.1.1. Parts de marché

128.  Sur la foi de la segmentation du marché réalisée par Gartner, l’entité issue de la concentration disposera de parts conjointes importantes sur le marché de la modélisation et de la gestion des exigences.

VII.1.1.1.  Modélisation

129.  Dans la catégorie Analyse et conception orientée objet, la «part de marché» combinée des parties indiquée par Gartner113 s’élève à 68 % dans le monde (IBM: 48% et Telelogic: 20 %), et à 69 % en Europe (IBM: 45% et Telelogic: 25%). Les principaux concurrents examinés par Gartner sont Borland, Sybase et Computer Associates.

130.  IBM prétend que les parts de marché de Gartner ne reflètent pas précisément le pouvoir de marché de l’entité issue de la concentration sur le marché. Les parties ont donc recalculé leurs parts de marché ainsi que les parts de marché de leurs concurrents. D’après les données relatives aux parts de marché corrigées présentées par IBM, l’entité issue de la concentrationissue de la concentration atteindrait une part mondiale conjointe sur le marché de la modélisation de [30-40]* %114, exprimée en valeur et [10-20]* %115, exprimée en volume. Les parties estiment que les chiffres de Gartner présentent des lacunes importantes pour les raisons suivantes.

131.  Tout d’abord, en se concentrant sur les recettes générales (incluant les recettes issues de la maintenance et de l’assistance) au lieu des recettes provenant des licences, Gartner exagère la position concurrentielle des parties (étant donné le caractère patrimonial des produits Rational Rose d’IBM) et sous-estime la position concurrentielle de plusieurs fournisseurs importants.

132.  À cet égard, les chiffres fournis par les parties montrent que sur la part de 48 % attribuée par Gartner à IBM, environ [20-30]* %116 correspondent aux produits patrimoniaux d’IBM Le tableau 2117 présenté la […]* baisse des recettes de licence d’IBM provenant des produits patrimoniaux ces dernières années (voir en particulier […]*).

Tableau 2

 133.  De plus, comme le démontre le tableau 3, la plus grande partie du chiffre d’affaires réalisé avec IBM Rational Rose provient actuellement de la maintenance et des services des projets en cours.

Tableau 3

134.  Deuxièmement, IBM prétend qu’en se concentrant sur les parts de marché en termes de recettes au lieu des parts de marché en termes de volume (c.-à-d. le nombre de licences accordées qui représente l’utilisation réelle de l’outil), Gartner ne parvient pas à représenter l’importance des revendeurs à bas prix comme Sparx Systems.

135.  Bien que l’enquête approfondie ait confirmé que certains revendeurs à bas prix constituent une alternative crédible pour la modélisation et doivent donc être pris en compte dans le calcul des parts de marché118, les parts de marché en termes de valeur

136.  Troisièmement, IBM prétend que la catégorie Analyse et conception orientée objet de Gartner exclut plusieurs outils importants pour la modélisation de systèmes (comme Artisan Studio ou The Mathworks Simulink).

137.  Quatrièmement, IBM prétend également que les données de Gartner ne tiennent pas compte de l’effet croissant des outils « libres », comme […]*, basés sur Linux ou Eclipse.

138.  Cinquièmement, IBM indique que même les données corrigées des parts de marché présentées (part de marché mondiale combinée en matière  de  modélisation  de  [30-40]* %, exprimée en termes de valeur et de [10-20]* %, exprimée en termes de volume) exagèrent la puissance de l’entité issue de la concentration sur le marché, étant donné qu’elles ne tiennent pas compte de plusieurs produits concurrentiels importants (comme les produits Visio120 et Visual Studio de Microsoft).

139.  Bien qu’il semble évident que les parts de marché de Gartner exagèrent la puissance de l’entité issue de la concentration, les calculs de part de marché corrigés d’IBM ne semblent pas entièrement adaptés non plus. Les données des parties peuvent exagérer la part de recettes de leurs concurrents qui est réalisée grâce aux recettes des licences121. Deuxièmement, IBM a également intégré des revendeurs qui ne sont pas perçus comme des concurrents par les sociétés ayant répondu à l’enquête approfondie de la Commission122. Troisièmement, IBM paraît surestimer la part de marché de la  catégorie

« Autres revendeurs du secteur Modélisation de logiciels » ([10-20]* %) en considérant que l’intégralité de son chiffre d’affaires provient des recettes de licence. Pour finir, IBM peut avoir sous-estimé ses propres parts de marché123.

140.  Si les chiffres des parties sont corrigés en fonction des données fournies par les clients et les concurrents concernant leur propre chiffre d’affaires, ainsi qu’en fonction des résultats de l’enquête approfondie, la part de marché mondiale combinée estimée des parties s’élèverait à [30-40]* %, comme présenté dans le tableau 4124. Les principaux concurrents seraient The Mathworks, Borland et Mentor Graphics, avec des parts de marché respectives de [30-40]* %, [0-10]* % et [0-10]*%.

Tableau 4

 141.  Si tous les outils non compatibles UML devaient être exclus125, nous parviendrions à une part de marché combinée de [50-60]* %. Les principaux concurrents seraient The Mathworks, Borland et Mentor Graphics, avec des parts de marché respectives de [10- 20]* % et [0-10]*%..

VII.1.1.2.  Gestion des exigences

142.  En matière de gestion des exigences, la «part de marché» combinée des parties indiquée par Gartner représente 62 % dans le monde (25 % pour IBM et 37 % pour Telelogic) et 65 % en Europe (22 % pour IBM et 43 % pour Telelogic)126. Les concurrents sont notamment Borland et Serena Software.

143.  Comme pour la modélisation, IBM prétend que les données de Gartner présentent d’importantes lacunes et ne reflètent pas précisément la puissance de l’entité issue de la concentration sur le marché. Les parties ont donc recalculé leurs parts de marché ainsi que les parts de marché de leurs concurrents. D’après les données relatives aux parts de marché corrigées présentées par IBM, l’entité issue de la concentration atteindrait une part mondiale conjointe en matière de gestion des exigences de [20-30]* %127, exprimée en valeur et [10-20]* %128, exprimée en volume. IBM estime que les chiffres de Gartner présentent d’importantes lacunes pour les raisons suivantes.

144.  Tout d’abord, les parts de marché fondées sur les recettes de Gartner sous-estimeraient l’importance des fournisseurs dont le modèle d’entreprise implique la vente d’un grand nombre de licences à un faible prix unitaire, comme RallyDev ou VersionOne et ne tiendrait pas compte des outils de gestion des exigences à logiciels libres («open- source») (comme Use Case Maker, Xplanner, Open Source Requirements Management Tool, myRMS).

145.  Comme expliqué en relation avec la modélisation, les parts de marché en termes de valeur semblent toujours mieux refléter la puissance sur un marché que les parts en termes de volume dans le cas de produits différenciés.

146.  Deuxièmement, IBM prétend que les parts de marché de Gartner ne tiennent pas compte de plusieurs fournisseurs importants d’outils de gestion des exigences (comme Compuware).

147.  Troisièmement, Gartner exclut également les outils utilisés dans la « Gestion du cycle de vie du produit » comme Siemens UGS TeamCenter, qui constituerait un concurrent évident sur le marché des outils de gestion des exigences.

148.  Pour finir, IBM prétend que la part de marché réelle de l’entité issue de la concentration serait même inférieure à ses propres estimations (part de marché mondiale combinée de [20-30]* % en matière de gestion des exigences, exprimée en termes de valeur et de [10- 20]* %, exprimée en termes de volume), étant donné qu’elle ne tient pas compte des ventes d’outils de bureau universels (comme Microsoft Word, Excel ou PowerPoint),  qui sont utilisés par certains clients pour les tâches de gestion des exigences.

149.  De la même manière, comme expliqué en relation avec la modélisation, les parts de marché de Gartner semblent surestimer la puissance de l’entité issue de la concentration sur le marché, tandis que l’estimation plus faible d’IBM sous-estimerait la position de l’entité issue de la concentration sur le marché129.

150.  Si les chiffres des parties sont corrigés en fonction des données fournies par les clients et les concurrents concernant leur propre chiffre d’affaires, ainsi qu’en fonction des résultats de l’enquête approfondie, la part de marché mondiale combinée estimée des parties s’élèverait à [20-30]* %, comme présenté dans le tableau 5130. Les principaux concurrents sont Borland et UGS TeamCenter, avec des parts de marché respectives de [0-10]* % et de [0-10]* %.

Tableau 5

VII.1.1.3.  Conclusion

151.  L’enquête approfondie a démontré qu’indépendamment de l’exactitude de l’approche de Gartner envers la définition du marché, la prudence est de mise lors de l’utilisation des parts de marché comme représentant direct de la puissance sur le marché de la modélisation et de la gestion des exigences. Le niveau élevé d’hétérogénéité des  produits réduit la possibilité de substituer les outils de modélisation et de gestion des exigences individuels. L’enquête approfondie a également confirmé que les outils de modélisation ou de gestion des exigences qui sont standard dans le secteur à l’heure actuelle pouvaient devenir un produit patrimonial en moins de cinq ans. Les concurrents qui ne mettent pas régulièrement leurs produits à niveau, ou qui n’introduisent pas de nouveaux produits satisfaisant les besoins croissants des clients perdront rapidement pied. La baisse des ventes des outils de modélisation Rational Rose d’IBM en constitue un bon exemple.

VII.1.2.  Proximité der la substitution

152.  Puisque les parts de marché peuvent ne pas représenter un indicateur fiable de la puissance sur le marché dans le cas présent, les éventuels effets anticoncurrentiels de la concentration ont été principalement évalués sur la base d’une analyse de la proximité  de la substitution.

153.  La partie notifiante prétend que les outils de gestion des exigences et de modélisation d’IBM et de Telelogic sont loin de constituer des substituts proches, dans la mesure où ils sont très différenciés et largement différents en ce qui concerne les principales fonctionnalités, qui ciblent différents groupes de besoins des clients. L’accent est tout particulièrement mis sur la différence entre les besoins des clients qui utilisent les outils de modélisation et de gestion des exigences pour des applications informatiques et ceux qui les utilisent pour le développement de systèmes. Tandis que les outils d’IBM sont plus axés sur les applications informatiques, ceux de Telelogic sont plus orientés vers le développement de systèmes.

154.  La proximité de la substitution peut être évaluée en analysant et en tirant des conclusions de la sélection du groupe de produits qu’un client examine avant de prendre  une décision d’achat. Tous les produits que le client examine dans le cadre du processus d’achat constituent d’éventuels « substituts proches » du produit finalement sélectionné. Néanmoins, l’inclusion d’un outil de modélisation ou de gestion des exigences particulier dans une liste longue ou dans une liste réduite ne signifie pas nécessairement qu’il s’agit d’un substitut proche de tous les autres outils figurant dans la liste, ou de l’outil finalement sélectionné par le client. Etant donné la forte hétérogénéité de chaque outil et la connaissance limitée que peuvent avoir les clients des caractéristiques des outils et de leur fonctionnement dans la pratique, en particulier au début du processus d’évaluation, il faut obligatoirement être prudent avant de tirer des conclusions du simple fait qu’un outil particulier soit mentionné dans une liste longue ou même dans une liste réduite131. Comme nous l’avons établi dans le chapitre consacré au processus d’achat, le client saura souvent uniquement au terme du processus d’achat si les produits figurant dans sa liste longue et même dans sa liste réduite constituent des substituts réalistes à l’outil finalement sélectionné. L’enquête approfondie l’a clairement démontré132.

155.  Une analyse qualitative de la question de proximité de substitution a été effectuée dans le cadre de l’enquête approfondie. Cette analyse a été complétée par une analyse quantitative, dans la mesure où la qualité des données sous-jacentes le permettait. L’analyse qualitative a été basée sur les réponses des clients et des concurrents aux trois séries de demandes d’information détaillées transmises par la Commission. Plusieurs entretiens ont été réalisés avec un groupe sélectionné de clients et de concurrents importants, afin d’obtenir des éclaircissements supplémentaires133. L’analyse quantitative en découlant a été fondée sur une analyse des données gagnant / perdant.

156.  Un tiers (Microsoft) a présenté une autre analyse qualitative du marché. Cette analyse de marché conclut que l’opération entraverait de manière significative une concurrence effective dans le marché commun134. Il apparaît même que la méthode d’enquête sur laquelle est fondée cette analyse est sérieusement biaisée135. Ceci étant et en tenant

« La procédure d’évaluation de Lockheed Martin a été répartie en deux phases. Dans une première phase, Lockheed Martin a évalué une longue liste de dix-sept outils qui avaient été sélectionnés sur la base de leurs caractéristiques publiquement présentées par les fournisseurs. Sur la foi de cette première évaluation, quatre outils ont été évalués comme clairement supérieurs. Dans une seconde phase, une étude détaillée de ces produits a été réalisée, avec des démonstrations des fournisseurs. A la fin de cette procédure, X a été sélectionné comme le seul outil de modélisation recommandé par Lockheed Martin, étant donné qu’il se classait premier pour tous les types d’applications. Le produit Y n’a en lui-même pas satisfait toutes les exigences minimums de Lockheed Martin. Il a été néanmoins inclus dans la procédure d’évaluation (et ultérieurement sur la liste réduite) »  qui amoindrissent sérieusement sa pertinence. L’étude est basée sur un échantillon extrêmement réduit (seize entretiens au total), qui ne permet pas de dégager des conclusions significatives du point de vue statistique. L’étude elle-même reconnaît que « étant donné l’échelle réduite de l’étude, ces conclusions ne sont pas nécessairement représentatives du marché dans son ensemble, et la société ayant mené   cette étude n’a effectué aucune déclaration de ce type ». Ni l’identité de la société qui a procédé à l’étude, ni l’identité des sociétés y ayant répondu n’a été divulguée. La Commission n’est donc pas en mesure de vérifier les résultats de cette étude. De plus, le rapport ne divulgue pas l’intégralité des données brutes sur lesquelles est basée l’étude. Il ne fournit que certains devis communiqués par des sociétés ayant répondu de manière anonyme à l’étude. En outre, ses conclusions ne reflètent pas correctement les résultats de l’étude. Par exemple, les devis donnés semblent plutôt accentuer les différences entre l’outil de gestion des besoins DOORS de Telelogic et Requisite Pro d’IBM que leurs ressemblances. L’étude reste silencieuse au sujet des outils de modélisation d’IBM et de Telelogic. En compte du fait que l’enquête sur laquelle le rapport est fondé ne justifie pas pleinement ses conclusions, la Commission se fonde principalement sur les résultats de sa propre enquête approfondie.

VII.1.2.1. Outils de modélisation

157.  Comme nous l’avons expliqué dans le chapitre consacré aux revendeurs d’outils de développement de logiciels, IBM propose plusieurs outils de modélisation136. RSA est tout particulièrement destiné à répondre à tous les besoins de développement d’application informatique. RSM est spécialement ciblé sur les analystes informatiques et comprend le sous-ensemble de fonctionnalités de RSA pertinent à un niveau de prix inférieur. RSD offre des fonctions semblables à celles de RSA. Il est néanmoins bien adapté au développement d’applications informatiques générales, étant donné que la  plus grande partie de la programmation informatique est effectuée en utilisant J2EE, C# et VisualBasic.NET. Bien que tous les outils de modélisation non patrimoniaux d’IBM soient compatibles UML 2.0, ils ne sont pas adaptés pour SysML et ne génèrent pas de code C137. Outre ces outils de modélisation non patrimoniaux, IBM possède plusieurs outils de modélisation patrimoniaux, comme la gamme de produits Rational Rose. Etant donné leur ancienneté, ils ne sont pas compatibles avec les langages UML 2.0 ou SysML.

158.  Telelogic dispose essentiellement de deux outils de modélisation: Rhapsody et TAU138. Ces deux outils sont axés sur les systèmes complexes (intégrés). Ils servent à répartir l’analyse de gros systèmes en divers niveaux de sous-systèmes et à formaliser ou modéliser les interactions entre ces divers sous-systèmes. Rhapsody et TAU sont des produits compatibles UML. Rhapsody et TAU sont notamment compatibles avec les derniers modèles exécutables UML 2.1, qui proposent une ingénierie bidirectionnelle entre modèle et code généré139.

159.  Une analyse des fonctionnalités des outils de modélisation respectifs de Telelogic et d’IBM confirme qu’il existe des différences significatives entre les outils de modélisation de ces deux sociétés. Les différences les plus importantes entre les outils  de modélisation de Telelogic et ceux non patrimoniaux d’IBM se situent au niveau de la capacité des outils de Telelogic à utiliser le langage de modélisation SysML, leur entière compatibilité avec les exigences DoDAF/MoDAF140, leur capacité à vérifier et à valider le modèle, leur compatibilité avec les langages de programmation C et Ada, leur supériorité en termes de génération de code et leur compatibilité avec les applications intégrées (fonctionnant souvent sur RTOS)141. Ces fonctionnalités présentent un intérêt particulier pour les clients systèmes et l’absence de certaines d’entre elles fait que les outils de modélisation d’IBM sont largement moins adaptés pour les clients systèmes. Pour finir, une comparaison de prix montre que les prix des outils de modélisation de Telelogic sont largement supérieurs à ceux des outils de modélisation d’IBM142.

160.  D’autre part, une comparaison des fonctionnalités présentant un intérêt particulier pour les développeurs informatiques montre qu’en particulier, IBM RSA possède des fonctions plus développées que les outils de modélisation de Telelogic, par exemple […]*143.

161.  Les différences de fonctionnalités et d’orientation commerciale entre les outils de modélisation de Telelogic et d’IBM se reflètent dans le type de clients desservis par ces sociétés. Les clients Modélisation de Telelogic sont principalement actifs dans les secteurs qui utilisent des outils de modélisation pour le développement de systèmes complexes (en particulier intégrés), comme l’aérospatiale et la défense (45 % du chiffre d’affaires de Telelogic) et, dans une moindre mesure, les communications (11 %) et l’automobile (5 %)144. Parmi les principaux clients de Telelogic figurent Lockheed Martin, Ericsson, Thales, Nokia, Raytheon, Boeing, General Dynamics, Northrop Grumman, Siemens et EADS. Les clients d’IBM pour les outils de modélisations sont plus concentrés dans le secteur du développement informatique, le secteur financier et l’administration publique. -

162.  Une analyse des documents internes d’IBM montre que […]* reconnaissent l’adéquation limitée de leurs outils de modélisation pour le segment du développement de système, et en particulier le segment des systèmes complexes (en particulier intégrés), qui se trouvent principalement dans le secteur de l’aérospatiale et de la défense147.

163.  Une analyse des calendriers de lancement des produits d’IBM montre qu’une mise à niveau importante était prévue en relation avec l’outil […]*,[…]*148. Cette mise  à niveau était considérée comme nécessaire au maintien ou à l’accroissement de la présence d’IBM dans le segment système (financièrement important).

164.  Le calendrier de lancement indique néanmoins que l’outil mis à niveau d’IBM ne comprendrait toujours pas plusieurs fonctionnalités essentielles par comparaison avec  les versions actuelles des outils de modélisation de Telelogic ([…]*)149.

165.  De plus, une simple augmentation du nombre de fonctionnalités peut ne pas suffire à transformer les outils de modélisation d’IBM en un substitut proche des outils de modélisation de Telelogic. Les résultats de l’enquête approfondie ont confirmé que pour les clients, la qualité des fonctionnalités de modélisation disponibles est tout aussi importante que leur nombre. Les clients du segment système considèrent généralement que les outils de Telelogic sont supérieurs à ceux d’IBM à la fois en termes de quantité et de qualité ou profondeur150.

166.  De plus, l’enquête approfondie a confirmé que tous les fournisseurs d’outils de modélisation mettent constamment leurs outils à niveau. Ce processus est stimulé par l emploient souvent des critères pondérés, reflétant l’importance relative de chaque critère. Chaque outil de modélisation se voit attribuer une note par critère correspondant à ses performances. Voir par exemple la réponse d’Elbit du 2 novembre à la question 8 de la demande de renseignements de la Commission. Un autre exemple se trouve dans la réponse de Lockheed Martin du 8 novembre 2007 à la question 11 de la demande de renseignements de la Commission. Les listes de critères, tout particulièrement dans le cas des clients employant des systèmes complexes, peuvent être composées de cinq cents critères individuels, voire davantage. Ces outils d’évaluation indiquent, en particulier pour  les clients du segment système, que les outils de Telelogic obtiennent de bien meilleures notes que les outils d’IBM sur de nombreuses fonctionnalités qui sont importantes pour les clients systèmes. Voir également l’étude du Groupe Butler de juin 2007, Développement orienté par modèle, qui conclut   que

« Le Groupe Butler estime que l’offre de Telelogic est l’une des plus puissantes du marché et devrait être prise en compte par les développeurs qui souhaitent améliorer la qualité et réduire le délai de commercialisation de systèmes et d’applications logiciels complexes ou recouvrant  une  grande  échelle ».

167.  Néanmoins, même si l’écart entre les outils de modélisation de Telelogic et ceux d’IBM était trop étroit, la présence constante d’un écart, quelle que soit son importance, peut être suffisamment essentielle pour influer sur la décision d’achat des clients du segment système. L’enquête approfondie a démontré que les clients du secteur système et, en particulier, du segment aérospatiale et défense, considèrent généralement le meilleur outil de modélisation disponible, étant donné que leurs besoins en matière de quantité et de qualité de fonctionnalités dépassent couramment ce que propose toute offre de produit actuelle152.

168.  En fin de compte, les services marketing d’IBM reconnaissent que la mise à niveau de leurs outils de modélisation est peu susceptible de transformer leurs outils en substituts proches des outils de modélisation de Telelogic : «Il manque à […]* une solution complète attractive pour les clients de systèmes» et «Il ne suffira pas d’investir dans les ressources internes pour répondre à toutes les attentes de la clientèle»153.

Analyse par secteur d’industrie

 169.  L’enquête approfondie a confirmé que les clients des différents secteurs industriels avaient des besoins différents en matière de logiciels de modélisation. D’une manière générale, il est possible de différencier ceux qui utilisent des outils de modélisation pour les applications informatiques et ceux qui ont des besoins à la fois en matière de développement de système et d’informatique. Ce dernier groupe de clients a tendance à acheter des outils de modélisation différents afin de satisfaire des besoins différents.

170.  Bien que les clients du secteur systèmes aient en commun le fait d’avoir des besoins complexes154, des différences peuvent toujours se présenter entre les besoins de groupes de clients donnés du secteur système, qui les incitent à choisir un outil de modélisation particulier (par ex. : des systèmes réduits ou importants, continus ou réactifs, en temps réel, mettant l’accent sur la sécurité, dépendants du matériel, etc.).

171.  Les outils de modélisation peuvent servir à créer des spécifications de systèmes utilisées par des équipes (dépassant parfois les frontières de l’organisation) devant s’accorder sur un ensemble d’objectifs. Cette caractéristique oriente également les besoins du client en termes de fonctions ciblées vers la compatibilité avec les spécifications système (comme SysML, la modélisation fonctionnelle). De la même manière, les systèmes sont généralement conçus au moyen des langages de programmation C, C++ ou Ada qui fonctionnent sur des systèmes d’exploitation en temps réel. Par conséquent, pour les clients qui cherchent à utiliser leurs outils de modélisation dans le cadre de leur développement de code source, la compatibilité avec la génération de code et l’ingénierie inverse de ces langages de programmation est essentielle. Pour finir, les logiciels complexes comme ceux qui se trouvent dans les périphériques intégrés (par exemple dans les téléphones portables, les systèmes d’injection de carburant, les systèmes de freinage antiblocage, les systèmes d’atterrissage, etc.) exigent souvent une validation et des essais très poussés. Pour cette raison, la simulation de la modélisation, la résolution des problèmes et la validation formelle constituent généralement des critères essentiels pour ces projets de développement155.

Aérospatiale et défense

172.  La grande majorité des sociétés ayant répondu à l’enquête approfondie dans les secteurs de l’aérospatiale et de la défense emploient les outils de modélisation TAU ou Rhapsody de Telelogic basés sur UML156. Artisan157 est le seul outil de modélisation basé sur  UML qui est considéré comme un substitut proche des outils de modélisation de Telelogic. Néanmoins, dans la pratique, seul un groupe restreint de clients l’utilise réellement.

173.  Dans la mesure où les entreprises de ce secteur ayant répondu aux questions utilisent les outils de modélisation d’IBM, il s’agit des outils de modélisation patrimoniaux d’IBM, Rose. La vente de nouvelles licences pour ces outils connaît néanmoins une baisse  […]*. La raison pour laquelle plusieurs clients de ce secteur, ainsi que d’autres secteurs de systèmes, décrits ci-après, utilisent toujours des outils patrimoniaux est liée au fait que les clients ont tendance à conserver les outils de modélisation qu’ils ont sélectionné au début d’un projet. Changer d’outils de modélisation en cours de projet crée d’importants frais de substitution.

174.  L’enquête approfondie a confirmé que les frais de substitution ne constituent pas un frein pour les nouveaux projets. En particulier, les frais de substitution impliqués par le passage d’outils de modélisation patrimoniaux à des outils de modélisation non patrimoniaux d’IBM sont largement plus importants que dans le cas d’un passage aux outils de modélisation de Telelogic158. Les clients qui utilisent les outils de modélisation patrimoniaux d’IBM pour les projets en cours ont tendance à passer aux outils de modélisation de Telelogic pour les nouveaux projets159. Les sociétés ayant répondu à l’enquête approfondie ont indiqué que l’emploi des outils de modélisation d’IBM pour les nouveaux projets était rare et semblait recouvrir des besoins de modélisation différents de ceux gérés par les outils de Telelogic160.

175.  De temps en temps, les clients du secteur de l’aérospatiale et de la défense complètent les produits de modélisation de Telelogic par des produits non compatibles UML. Ces produits (comme ceux proposés par Mathworks ou Esterel) constituent des produits « de niche » spécialisés, qui se concentrent sur un domaine de modélisation particulier161 et n’ont pas la même application, c.-à-d. une application aussi vaste, que les outils de modélisation de Telelogic. L’emploi d’outils de modélisation libres est très rare dans ce secteur. L’enquête approfondie a montré que les questions de sécurité empêchent notamment les clients d’utiliser ces outils.

176.  La grande préférence des clients du secteur de l’aérospatiale et de la défense pour les outils de modélisation de Telelogic peut s’expliquer par le fait que ces outils servent mieux leurs besoins en modélisation de systèmes vastes et complexes. La compatibilité avec SysML et la modélisation fonctionnelle et structurelle constituent des critères essentiels, de même que la compatibilité MoDAF et DoDAF pour les systèmes de défense. De plus, les clients de ces secteurs comptent souvent sur des solutions de modélisation plus spécialisées pour développer le code source de logiciels. En fonction de la nature du système, ils mettent particulièrement l’accent sur la validation formelle du modèle (par exemple, pour les systèmes dans lesquels la sécurité est primordiale) ou ils peuvent rechercher des outils de modélisation qui supportent bien les langages de programmation cibles (dans la plupart des cas, des langages comme Ada, C et C++)162. Les outils de modélisation d’IBM ne proposent pas ces fonctionnalités ou obtiennent  une note largement inférieure en termes de qualité et de profondeur desdites fonctions.

177.  Étant donné que la plupart des besoins en modélisation de ce secteur concernent des systèmes complexes, la proportion de besoin de modélisation pour laquelle les autres outils de modélisation sont mieux placés (comme les projets informatiques ou les projets de développement de systèmes plus petits et moins complexes) est relativement réduite.

Industries automobile et des communications

178.  L’enquête approfondie a confirmé que dans les secteurs de l’automobile et des communications qui, avec le secteur de la défense et de l’aérospatiale, représentent environ 80 %163 des clients des outils de modélisation de développement de système (intégré), les clients expriment généralement une préférence similaire pour les outils de modélisation de Telelogic, tout comme dans le secteur de l’aérospatiale et de la défense.

179.  Les outils de modélisation pour le secteur des communications sont quelque peu semblables à ceux du développement de système, mais partagent également quelques caractéristiques avec le développement d’application informatique164. Par conséquent,  les caractéristiques comme la compatibilité avec J2EE ou .NET sont pertinentes. L’une des différences avec les autres secteurs industriels qui utilisent des logiciels de modélisation pour les applications système est l’emploi de SDL comme langage de modélisation, en parallèle avec UML. SDL est un langage de modélisation dont les caractéristiques ont été établies par l’ETSI165, qui a été conçu pour le secteur des télécommunications. Telelogic est le principal fournisseur d’outils compatibles avec les normes ETSI / ITU (c.-à-d. SDL Suite de Telelogic)166. L’une des autres différences majeures par rapport au développement de systèmes d’une façon plus générale est le niveau de profondeur de la modélisation réalisée. Tandis que certains éléments logiciels complexes peuvent être modélisés avec un grand niveau de détail (c.-à-d. avec une modélisation comportementale complète), la modélisation de systèmes plus étendus est généralement réalisée à un niveau (structurel) exclusivement élevé. C’est la raison pour laquelle, dans le secteur des communications, le besoin de compatibilité avec la modélisation comportementale, la simulation, les essais et la génération de code source intégrale est inférieur par rapport à d’autres industries manufacturières comme l’automobile.

180.  Les besoins en modélisation du secteur automobile représentent largement un sous- ensemble de développement de systèmes. L’industrie automobile se caractérise par des clients qui ont généralement des besoins moins complexes à l’égard du développement logiciel. Leurs systèmes ont tendance à ne pas être aussi importants que ceux des secteurs de l’aérospatiale et des télécommunications pour lesquels les logiciels sont étroitement associés au matériel167. Par conséquent, les spécifications de leurs  systèmes

ou leur modélisation structurelle sont moins complexes. À la place, les clients de l’industrie automobile mettent davantage l’accent sur la capacité à modéliser le matériel et les logiciels dans les moindres détails, et à utiliser des mécanismes de simulation pour vérifier la fonctionnalité, les performances et la sécurité du système avant la  disponibilité du matériel. Contrairement au développement de systèmes d’une manière plus générale, les clients de l’industrie automobile utilisent principalement le langage de programmation C (en raison des contraintes de performances), si bien que les autres langages de programmation sont donc moins pertinents. Cette caractéristique réduit largement  le  degré  d’utilisation  des  outils  de  modélisation  d’IBM  dans  le   secteur automobile étant donné qu’ils ne génèrent pas de code C168.

181.  Pour répondre à leurs différents besoins, les clients des secteurs des communications et de l’automobile utilisent des outils différents pour leurs tâches de modélisation169. Pour leurs besoins informatiques, ou leurs tâches de développement de système moins exigeantes, les clients ont tendance à choisir parmi un vaste groupe d’outils de modélisation de substitution, comprenant les outils de modélisation d’IBM et d’autres outils comme ceux de Borland, Sparx, Microsoft Visio, Artisan et Mentor Graphics. A l’occasion, ces clients font appel aux outils de modélisation de Telelogic pour ces  tâches. Cependant, étant donné qu’ils sont plus coûteux que les outils de modélisation moins avancés d’autres fournisseurs et plus complexes à utiliser, les clients de ces secteurs limitent généralement leur usage des outils de Telelogic à la modélisation de systèmes intégrés complexes de leur organisation. Pour ces applications, les outils d’IBM ne constituent pas un substitut proche de ceux de Telelogic.

Applications des TI

182.  À l’autre extrémité du spectre se trouvent les clients qui utilisent des outils de modélisation pour des applications de TI. Parmi ces clients, on compte non seulement les entreprises de TI, mais aussi les établissements financiers et les administrations publiques. Les besoins en modélisation pour le développement d’applications de TI sont provoqués par les plateformes d’exécution cibles et leurs langages de programmation correspondants. Spécifiquement, les applications de TI peuvent fonctionner sur des systèmes d’exploitation tels que Microsoft Windows ou Linux, mais les applications commerciales modernes sont souvent créées de manière à fonctionner sur des intergiciels, tels que J2EE ou des serveurs d’applications .NET (par exemple IBM Websphere, BEA Weblogic Microsoft IIS) ou des serveurs Web (par exemple Apache) ou des moteurs d’exécution de procédures d’entreprise. Par conséquent, le support pour les services Web de modélisation, les éléments spécifiques au domaine J2EE et la génération de cadres de code source, ou l’ingénierie inverse de code de programmation qui fonctionne sur un intergiciel tel que J2EE (écrit en langage Java) et .NET (par exemple écrit en C# ou VB.NET) sont des éléments essentiels pour les développeurs d’applications de TI170.

183.  Les besoins en modélisation des établissements financiers sont semblables à ceux du développement d’applications de TI. Dans la mesure où les applications destinées aux secteurs de la banque, de la finance et des assurances sont souvent orientées bases de données, les critères tels que la modélisation de données ou la génération de code DLL (« Langage de définition de données ») sont plus importants. De manière similaire, un certain nombre d’applications destinées aux secteurs de la banque, de la finance et des assurances sont encore basées sur des applications bureautiques écrites en langage Java ou à l’aide de technologies telles que Cobra (communication client/serveur). De ce fait, ces éléments sont classés légèrement plus haut pour ce segment de l’industrie.

184.  L’enquête approfondie a confirmé que les clients dans ces secteurs considèrent rarement les produits de modélisation de Telelogic comme des substituts proches des offres de produits d’IBM, dans la mesure où ils sont moins bien adaptés aux besoins en IT spécifiques de ces clients. À la différence de nombreux clients dans le segment des systèmes (et plus particulièrement dans le secteur de l’aérospatial et de la défense), les

clients de ces secteurs attachent plus d’importance au prix des outils171. Le prix élevé et la sophistication du Rhapsody de Telelogic, par exemple, constitueraient en soi un obstacle au développement de son utilisation dans ce secteur. De plus, la complexité des outils de Telelogic est généralement peu utilisée dans le secteur des TI. L’enquête approfondie a confirmé que, dans ce secteur, peu de clients prendraient en considération les outils de modélisation de Telelogic172. Au lieu de cela, les clients utilisent les outils d’IBM, ainsi qu’un grand nombre d’autres outils de modélisation (par exemple, Oracle JDeveloper et Computer Associates).

Analyse des gains/pertes

 185.  Afin de compléter les documents et points de vue fournis par les participants du marché, la Commission a demandé aux parties de lui fournir un ensemble complet de « données gains / pertes » relatives aux outils de gestion des exigences et de modélisation depuis le mois d’octobre 2005.

186.  Les données « gains/pertes » décrivent des instances dans lesquelles chaque partie a gagné un nouveau contrat (par exemple, un contrat avec une société qui n’était pas encore cliente, ou un nouveau projet avec un client existant), ainsi que des instances où chaque partie a perdu un contrat (par exemple un contrat existant, une prorogation de contrat existant, une opportunité d’affaire potentielle). L’objectif d’une telle analyse quantitative est de contribuer à l’évaluation de la proximité de la substitution entre les produits de chaque Partie, en mesurant par exemple les fréquences de « confrontation » des produits de chacune des Parties dans les processus d’achat des clients et en mesurant si la présence de l’offre de chacune des parties exerce une influence sur le résultat des processus d’achat.

187.  Dans le cas présent, les parties devaient fournir les détails173 sur, premièrement, l’identification du client : nom du client, nom du groupe auquel appartient le client (le cas échéant), le pays du client, le secteur d’activité du client, puis, en second lieu, sur l’identification du projet: année, zone géographique couverte, projet nouveau ou existant, principaux éléments du projet / des besoins du client, la valeur totale du projet, le nombre de licences du projet, et enfin, sur l’identification des fournisseurs réels ou assimilés impliqués: noms des anciens produits et de leurs fournisseurs (le cas échéant), les noms des produits concurrents réels ou assimilés et leurs fournisseurs qui ont été retenus par le client (le cas échéant), le nom du produit sélectionné pour le contrat (le  cas échéant).

188.  […]*. De ce fait, la Commission s’est principalement fondée sur l’analyse de la réponse de Telelogic. Telelogic tient à jour une base de données dans laquelle est enregistrée une «perspective de débouché» lorsque les chances de conclure une vente avec un client sont supérieures à […]* %174.

189.  La Commission a partiellement corrigé l’ensemble des données gains / pertes de Telelogic concernant les outils de modélisation en vérifiant avec quelques clients l’exactitude des informations fournies par Telelogic, notamment les informations relatives au nombre et à l’identité des produits concurrents auxquels Telelogic était confrontée175.

190.  Concernant les années 2006 et 2007, l’ensemble des données final contient les informations sur […]* cas de gains/pertes ([…]* marchés gagnés et […]* marchés perdus), ce qui représente une valeur (contrat conclu ou attendu) d’environ […]* millions USD ([…]* millions USD pour les marchés gagnés et […]* millions USD pour les marchés perdus)176.

191.  Un concurrent réel ou assimilé est mentionné dans […]* des perspectives de débouché enregistrées ([…]* gains et […]* pertes). En théorie, les perspectives de débouché pour lesquelles aucun concurrent réel ou assimilé n’est mentionné correspondent soit à des extensions ou des renouvellements, soit à de nouveaux projets. Dans le premier cas, le titulaire (Telelogic) n’est typiquement pas confronté à la concurrence, la seule incertitude résidant dans le fait de savoir si le client est disposé ou non à acquérir d’autres licences de produits Telelogic, ceci majoritairement indépendamment de l’offre des autres concurrents. Ces perspectives de débouché n’apportent aucun renseignement sur l’interaction entre les parties. Dans le second cas, le client consultera probablement plusieurs fournisseurs pour choisir un produit. Dans ce cas, l’échantillon sous-estimerait le nombre d’perspectives de débouché dans lesquelles Telelogic serait confrontée à des fournisseurs alternatifs et, de ce fait, la base de données gains/pertes ne refléterait pas totalement les interactions correctes entre les concurrents.

192.  Afin d’évaluer la représentativité de l’ensemble des données gains / pertes, la Commission  a  effectué  plusieurs  tests177.  En  dépit  du  nombre  d’imperfections,    la

193.  En outre, LECG178 a comparé la répartition des revenus par industrie des deux sources (cas tirés de la base de données gains / pertes d’une part, et les chiffres des recettes d’autre part) et les a jugées cohérentes. Cet élément accorde de la valeur à l’analyse des données gains/pertes.

194.  Comme le montre le tableau 6 ci-dessous, les perspectives de débouché dans lesquelles les produits non patrimoniaux d’IBM sont en concurrence avec les produits de Telelogic sont moindres entre […]* et […]* instances sur […]* dans lesquelles un concurrent a  été identifié (c’est-à-dire entre […]* et […]*). Le même rapport (à savoir entre […]* et […]*) s’applique également à la valeur cumulée des cas dans lesquels les produits non patrimoniaux d’IBM sont en concurrence avec les produits de Telelogic, ainsi qu’à la valeur cumulée des perspectives de débouché dans lesquelles un concurrent a été identifié.

Telelogic figurant dans la liste de la base de données des opportunités pour cette même période, à savoir Rhapsody, TAU et SDL, s’élèvent à […]* millions USD. Les revenus totaux correspondants de Telelogic (licences, maintenance et services) s’élèvent à […]* millions USD. Les revenus générés par les instances gagnées de la base de données gains / pertes s’élèvent à […]* millions USD, soit […]* des revenus de licences de Telelogic pour la période 2006-troisième trimestre 2007 et […]* des revenus totaux de Telelogic pour la période 2006-troisième trimestre 2007. La comparaison des ces résultats n’est pas aussi simple dès lors que la valeur escomptée rapportée dans les rapports gains/pertes peut être répartie sur plusieurs revenus annuels alors que les données relatives aux revenus intègrent les flux de revenus provenant de différents contrats, ainsi que d’éléments non couverts par les contrats initiaux (comme par exemple des services ou maintenances non programmés).

Tableau 6: Fréquence des interactions entre les outils de modélisation deTelelogic 

 Notes:      1) Les produits patrimoniaux d’IBM incluent les produits Rose, c’est-à-dire Rose Enterprise, Rose Modeler, Rose RT et Rose XDE

2)  Les produits non patrimoniaux d’IBM incluent les produits RSA, RSD et RSM

3)  Les produits IBM sans détails spécifiques peuvent être des produits patrimoniaux ou non patrimoniaux d’IBM

 195.  Le tableau 7 montre à quelle fréquence Telelogic est confronté à ses principaux concurrents. Sur les […]* instances dans lesquelles un concurrent a été identifié, les produits non patrimoniaux d’IBM et Telelogic se retrouvent […]* fois, alors que Telelogic et Artisan se retrouvent à […]* reprises, à […]* reprises avec Sparx et à […]* reprises avec Mathworks. De plus, la segmentation selon la taille du projet, l’industrie  ou la zone géographique du client ne semble pas montrer de niveaux d’interactions entre les parties supérieures à ceux de Telelogic avec ses principaux concurrents179.

Tableau 7: Fréquence des interactions entre Telelogic et certains de ses concurrents dans le domaine de la modélisation (nombre d’perspectives de débouché)

Source:   Enquête et analyse du marché de la Commission

 Notes: 1) Les produits patrimoniaux d’IBM incluent les produits Rose, c’est-à-dire Rose Enterprise, Rose Modeler, Rose RT et Rose XDE

2)  Les produits non patrimoniaux d’IBM incluent les produits RSA, RSD et RSM

3)  Les produits IBM sans détails spécifiques peuvent être des produits patrimoniaux ou non patrimoniaux d’IBM

4)  Il peut y avoir plus d’un concurrent pour une même opportunité; ainsi, en dépit de l’existence de 181 cas dans la base de données gains / pertes avec des concurrents identifiés, le nombre total d’interactions entre les paires de fournisseurs figurant sur la liste est ici de 187

 196.  En conclusion, malgré ses restrictions inévitables décrites ci-dessus, l’analyse gains/pertes tend à confirmer que les parties à l'opération ne sont pas strictement interchangeables sur le marché des outils de modélisation.

Conclusion sur le degré de substitution possible

197.  Il ressort de l’évaluation qualitative et quantitative effectuée plus haut que les outils de modélisation de Telelogic ne peuvent être considérés comme des produits de remplacement proches des outils de modélisation d’IBM. Pour le développement des systèmes ultrasophistiqués du secteur de l’avionique et de la défense, la seule vraie alternative aux outils de modélisation de Telelogic est l’outil UML Artisan Studio, bien que son utilisation soit limitée dans la pratique. Les autres clients pour le développement  de systèmes dans les secteurs de l’automobile et des télécommunications affichent eux aussi une préférence très nette pour les produits Telelogic dès lors qu’il s’agit de développement de systèmes complexes.

198.  Les clients de systèmes utilisent d’autres outils de modélisation (ex. Borland, Sparx et NoMagic) pour leurs autres tâches de modélisation (par exemple celles qui portent sur de petits projets de développement de systèmes moins complexes et sur des projets de développement de TI). Ces «autres» projets ont tendance à concerner davantage le secteur de l’automobile et des communications que l’avionique et la défense.

199.  Dans les TI, l’administration et le secteur financier, l’utilisation des outils de modélisation de Telelogic est très limitée tandis qu’IBM est plus présent. Ce constat est logique si l’on tient compte des différences de fonctionnalités décrites entre les outils de modélisation d’IBM et de Telelogic. Les usagers de ces secteurs disposent d’une longue liste d’outils de modélisation alternatifs aux outils de modélisation d’IBM.

200.  Même si certains clients considèrent les offres d'IBM et de Telelogic comme des  produits (relativement) proches pour certains usages, le nombre limité d'occasions dans lesquelles ce pourrait être le cas ne permettraient pas à l'entité issue de la concentration d'augmenter les prix après la concentration. Il existe un groupe de fournisseurs suffisamment nombreux d'outils de modélisation dont les fonctionnalités sont proches  de celles qui sont offertes par IBM pour rendre une telle hausse de prix non rentable. Le fait qu'une décision d'achat soit souvent prise (surtout pour les grosses commandes) sur la base d'une procédure type appel d'offres signifie que les parts de marché détenues par IBM et Telelogic jouent un rôle qui est moindre dans ce cas-là.

VII.1.2.2.                  Outils de gestion des exigences

201.  IBM possède un seul outil de gestion des exigences180. RequisitePro est principalement destiné aux analystes en informatique de gestion et aux utilisateurs professionnels qui créent des applications informatiques pour des procédures commerciales (ex. suivi des ventes, facturation).

202.  Les outils de de gestion des exigences de Telelogic sont essentiellement trois : DOORS, Focal Point et DOORS Fastrak. DOORS est conçu pour les ingénieurs systèmes qui gèrent les exigences de développement des systèmes. Focal Point se rapproche en fait davantage d’un outil de gestion de portefeuilles de produits181 que d’un outil de gestion des exigences. DOORS Fastrak est une version allégée et plus conviviale de Focal Point mise sur le marché en avril 2007182. Elle se veut une solution « clés en main »183 pour la gestion des exigences dans le cadre de projets rapides de développement logiciel184. DOORS Fastrack et Focal Point génèrent tous deux un chiffre d’affaires très modeste en comparaison avec DOORS qui est l’outil de gestion des exigences le plus vendu du marché.

203.  Une analyse des fonctionnalités des outils respectifs de Telelogic et d'IBM pour la  gestion des exigences confirme qu'il existe des différences importantes entre les outils proposés par les deux entreprises. L’outil RequisitePro d’IBM est un outil orienté TI, léger et centré sur le document, du type généralement utilisé par les analystes en informatique de gestion185. Dans un souci de simplicité d’utilisation, il a été conçu pour fonctionner avec Microsoft Word. Dans RequisitePro, la définition des exigences est simple: informations de base, priorité (élevée, moyenne, basse), coût (élevé, moyen, bas). Les utilisateurs de RequisitePro traitent en moyenne 500 à 1000 exigences tandis que l’outil peut en gérer un maximum de 50 000.

204.  La solution DOORS de Telelogic est un outil haut de gamme qui repose sur une base de données et s’adresse aux projets complexes, avec des procédures très structurées et éprouvées impliquant un grand nombre d’exigences et une approche rigoureuse de l’analyse des exigences186. Avec son interface utilisateur complexe, elle est destinée aux utilisateurs expérimentés. Elle permet d’effectuer des rapports et des analyses détaillés des exigences afin d’identifier les lacunes et de modifier l’impact et les méthodes de mesure. Les utilisateurs de DOORS traitent en moyenne au moins 100 000 exigences, le maximum théorique étant de 10 millions d’exigences.

205.  Si l’on compare les deux outils, DOORS apparaît comme le plus puissant et le plus élaboré des deux. C’est un avantage considérable dans le secteur du développement des systèmes. Contrairement à DOORS, RequisitePro ne dispose pas des attributs clés qui sont importants pour les clients de développement de systèmes: […]*187.

206.  Par contre, l’outil DOORS de Telelogic accuse quelques faiblesses sur un certain nombre d’attributs clés pour le développement des TI. Il lui manque […]*188. Telelogic a récemment mis sur le marché une version «allégée» de Focal Point, sous le nom de Telelogic DOORS Fastrak. Bien qu’étant moins coûteuse et plus simple d’utilisation que DOORS, elle manque toujours de […]*189. Focal Point de Telelogic n’est pas attractif pour les clients des TI. Il se positionne davantage comme un outil de gestion de portefeuilles de produits190 que comme un outil de gestion des exigences et présente des insuffisances en […]*.

207.  Les documents internes d’IBM confirment la supériorité de Telelogic DOORS sur le segment du développement des systèmes. La partie notifiante s’attend à ce que DOORS trouve sa place dans le portefeuille de produits d’IBM pour lui permettre d’entrer en contact avec des clients (par exemple dans l’industrie […]*) impossibles à atteindre de  la manière habituelle191.

208.  Les différences de fonctionnalités et d'objectif commercial entre les outils DOORS de Telelogic et RequisitePro d'IBM se reflètent aussi dans le type de clientèle que les deux entreprises approvisionnent. La clientèle de Requisite Pro d'IBM opère surtout dans les secteurs de l'administration publique ([…]*) et financière ([…]*) mais beaucoup moins dans les secteurs où les systèmes sont spécifiques comme l'avionique et la défense ([…]*), l'automobile ([…]*) et les communications ([…]*)192. La clientèle de Telelogic en gestion des exigences se trouve quant à elle davantage dans l’avionique et la défense ([…]*), l’automobile ([…]*) et les communications ([…]*).

209.  L’analyse de la feuille de route des produits d’IBM confirme que plusieurs des fonctionnalités de RequisitePro vont être améliorées (notamment […]*). Mais les améliorations programmées ne concernent pas les «attributs clés» qui permettraient de réunir ou de rapprocher les outils de gestion des exigences d’IBM et de Telelogic193. Comme on l’a expliqué concernant les outils de modélisation, IBM reconnaît elle-même qu’il est peu probable, même en améliorant ses outils (à la fois de modélisation et de gestion des exigences), que ceux-ci deviennent des produits proches des outils de modélisation de Telelogic: […]* et «Il ne suffira pas d’investir dans les ressources internes pour répondre à toutes les attentes de la clientèle»194.

Analyse par secteur d’industrie

 210.  À l’instar de la modélisation, l’enquête approfondie sur les outils de gestion des exigences a confirmé que les clients des différents secteurs de l’industrie ont des besoins en produits différents. Et la distinction entre clients de développement de systèmes et clients d’applications des TI s’applique aussi aux outils de gestion des exigences.

211.  Les besoins en gestion des exigences du secteur du développement des systèmes sont dictés par le fait que la tendance est à des projets à plus long cycle de vie, et à des équipes de plus en plus grandes et de plus en plus distribuées (au sein des organisations et entre les organisations). Pour ces raisons, plusieurs fonctionnalités liées à l’évolutivité des utilisateurs (ex. système de proposition de modification, support de workflow, historique des contrôles, contrôle d’accès/sécurité), ainsi qu’à l’évolutivité  des exigences (ex. analyse d’impact, analyse orpheline) sont plus appropriées que pour d’autres applications. De même, comme le développement des systèmes suit à la fois les exigences matérielles et logicielles, les intégrations avec des outils de gestion du cycle de vie des produits tels que la CAO (Conception Assistée par Ordinateur) ou l’EDA (conception électronique assistée par ordinateur) sont plus pertinentes.

212.  Au sein même du groupe des clients de systèmes on observe des différences de besoins. Celles-ci traduisent les spécificités du segment industriel et la préférence consécutive pour certains outils de gestion des exigences.

Aérospatiale et défense

213.  Les besoins du secteur de l’avionique et de la défense en gestion des exigences reflètent ceux du secteur du développement des systèmes en général. Ce secteur est caractérisé par des projets à long terme et des relations complexes entre prestataire principal et sous-traitants. Etant donné la taille des projets, les critères de planification et d’estimation ne sont généralement pas déterminants dans la mesure où il existe pour cela des outils spécialisés plus performants (ex. Primavera). Inversement, les critères relatifs aux utilisateurs et à l’évolutivité de leurs exigences sont davantage pris en compte (ex. support de workflow, système de proposition de modification, versionnage des exigences, analyse orpheline/exhaustive).

214.  Les résultats de l’enquête approfondie confirment que les outils de gestion des exigences d’IBM et de Telelogic ne sont pas en étroite concurrence. Les clients du secteur de l’avionique et de la défense, dont les besoins en outils de gestion des exigences concernent principalement les grands systèmes, affichent une nette préférence pour le système DOORS de Telelogic195. Il existe dans cette catégorie de nombreux clients qui jugent que DOORS n’a pas d’équivalent valable pour gérer les systèmes complexes196.

215.  Il faut cependant noter également que certains clients de cette catégorie utilisent à la fois DOORS de Telelogic et Requisite Pro d’IBM. Mais il semble toutefois que, dans ces cas-là, chacun de ces outils réponde à un usage différent. Autrement dit, DOORS est utilisé pour répondre aux besoins systèmes des sociétés, tandis que RequisitePro est préféré pour les projets très orientés développement logiciel197.

Industries automobile et des communications

216.  Les besoins du secteur automobile en gestion des exigences reflètent ceux du développement des systèmes en général. 

217.  L’enquête approfondie a fait apparaître que le secteur automobile considère généralement DOORS comme la norme pour la gestion des exigences198. Les clients qui choisissent DOORS le font soit parce qu’ils jugent que c’est l’outil qui possède les meilleures fonctionnalités, soit parce qu’il facilite les interactions avec les fournisseurs, les sous-traitants, etc199.. Il arrive aussi que les clients soient contractuellement tenus d’utiliser DOORS. Les professionnels interrogés lors de l’enquête approfondie citent des alternatives possibles à DOORS, et notamment MKS, Borland Caliber, IRQA, Polarion ALM, Reqtify et Siemens UGS TeamCenter200. Mais en règle générale la solution RequisitePro d’IBM n’est pas citée parmi les produits de remplacement potentiels201.

218.  Les besoins en gestion des exigences du secteur des communications sont généralement similaires à ceux du domaine du développement de systèmes, même s’ils partagent aussi certaines fonctionnalités avec le développement des applications de TI. Il est courant  que les systèmes de communication incluent ou se connectent à des applications des TI, c’est pourquoi on y trouve des fonctions telles que le story-boarding202. Comme pour les secteurs de l’automobile et des communications, le développement des systèmes obéit à des cycles de développement plus courts mais repose sur des équipes de développement plus grandes. C’est la raison pour laquelle les fonctionnalités de planification et d’estimation sont plus importantes, ainsi que les fonctions d’évolutivité des utilisateurs.

219.  L’enquête approfondie a confirmé que, dans le secteur des télécommunications, les clients ont généralement le choix entre un grand nombre de fournisseurs, parmi lesquels DOORS, Requisite Pro, Borland Caliber, Serena RTM, 3SL Cradle, Siemens UGS TeamCenter Systems Engineering, IRQA, Speedreq, Ontopia Force, Omninet Omni Tracker, Enovia Matrix One, ou qu’ils utilisent (selon la nature du projet en cours) des outils relativement simples à des fins de gestion des exigences, et notamment Microsoft Word et Excel203. L’enquête approfondie a toutefois confirmé que DOORS demeure l’outil privilégié pour de nombreux clients204.

Applications des TI

220.  Dans les applications des TI, les les besoins en gestion des exigences reflètent le besoin de capturer, de prioriser et de suivre des caractéristiques qui font partie des fonctionnalités de l’application du système de TI et de l’interface utilisateur205. Les principaux utilisateurs des outils de gestion des exigences pour le développement des applications des TI étant des utilisateurs professionnels, on trouve comme critères clés la simplicité d’utilisation, l’intégration avec les outils Microsoft Office et le prix. Parmi les autres critères importants, on peut citer le support pour le story-board visuel (qui permet de créer des maquettes d’écran pour afficher le contenu et le flux de l’interface utilisateur) et la simulation du story-board

221.  Les besoins du secteur financier en gestion des exigences sont relativement similaires à ceux du développement des TI. En comparaison avec le développement des TI pratiqué dans d’autres groupements verticaux d’industries, le secteur financier se caractérise par un grand nombre de petits projets à court terme. C’est la raison pour laquelle l’évolutivité, aussi bien dans le nombre d’utilisateurs que d’exigences, ou des fonctionnalités avancées telles que le versionnage des exigences ou l’analyse d’impact, revêtent une moindre importance. Inversement, les fonctions de story-boarding sont plus importantes car les clients chercheront le plus souvent à valider les nouvelles fonctionnalités proposées auprès des utilisateurs finals avant de commencer le développement.

222.  Parallèlement aux fonctionnalités spécifiques des segments de marché décrits ci-dessus, l’enquête approfondie a fait apparaître une préférence pour un produit différent de  celui associé au segment des systèmes. Les clients privilégient généralement Requisite Pro d’IBM, même s’il leur arrive souvent d’utiliser parallèlement d’autres solutions alternatives, solutions dont les outils de gestion des exigences de Telelogic ne font souvent pas partie206. L’enquête approfondie a confirmé que même l’utilisation d’outils relativement simples tels que Microsoft Excel et Word est commune à tous les clients207. En cas d’utilisation parallèle des outils de gestion des exigences d’IBM et de Telelogic,  il s’agit toutefois la plupart du temps d’un usage différencié208.

223.  Pour conclure, il ressort des paragraphes précédents que l’enquête approfondie a largement confirmé que les outils de gestion des exigences d’IBM et de Telelogic ne constituent pas des produits de remplacement proches. Quoi qu’il en soit, même dans les cas où certains clients ont cité les outils des deux fournisseurs, l’enquête approfondie a montré que le risque de hausse des prix du fait de l’entité issue de la concentration serait minime car il existe sur le marché suffisamment d’autres fournisseurs d’outils de gestion des exigences dont les fonctionnalités sont proches de celles qui sont offertes par Requisite Pro pour rendre une telle hausse de prix non rentable.

Analyse des gains/pertes pour les outils de gestion des exigences

 224.  Les parties ont également fourni des données sur les marchés gagnés/perdus concernant la fourniture d’outils de gestion des exigences. […]*. La Commission s’est donc fondée sur les informations relatives à Telelogic.

225.  Malheureusement, la base de données des possibilités concernant Telelogic pour les outils de gestion des exigences comporte un trop grand nombre de réserves pour rendre l’analyse instructive. Tout d’abord, sur les […]* possibilités, seules […]*, c’est-à-dire […]*, fournissent des informations sur les concurrents réels ou pressentis. De plus, LECG a comparé la répartition par secteur d’industrie des recettes correspondant aux marchés remportés par Telelogic dans la base de données des marchés gagnés/perdus, avec la répartition par secteur d’industrie des recettes globales de Telelogic en gestion des exigences. Il en résulte deux groupes de données radicalement différents.

226.  En conclusion, l’analyse de la base de données des marchés gagnés/perdus pour les outils de gestion des exigences ne suffit pas pour tirer des conclusions pertinentes sur la pression concurrentielle exercée par chaque partie sur l’autre.

Conclusion sur le degré de substitution possible

227.  Si l’on se base sur l’évaluation ci-dessus à dominante qualitative, il semble que les outils de gestion des exigences de Telelogic ne puissent être considérés comme des produits de remplacement proches de l’outil de gestion des exigences d’IBM, Requisite Pro. Nombreux sont les secteurs de l’industrie orientés développement des systèmes qui voient dans la solution DOORS de Telelogic quasiment un standard industriel (notamment l’avionique et la défense, et l’automobile) qui n’a pas de réel équivalent en termes de fonctionnalités et de performances globales. Quant aux autres outils de  gestion des exigences de Telelogic, soit ils ne sont pas un outil de gestion des exigences proprement dit (Focal Point), soit ils ne disposent pas de fonctionnalités suffisantes (DOORS Fastrak). Par conséquent, ils ne constituent pas non plus des produits de remplacement proches.

228.  Les clients de systèmes qui estiment qu’il existe des alternatives réalistes à Telelogic DOORS citent non seulement l’outil Requisite Pro d’IBM, mais aussi diverses autres solutions (par ex. Borland Together, Serena RTM, Siemens UGS TeamCenter), parmi lesquelles des outils de productivité généralistes tels que Microsoft Word et Excel, ainsi que des outils proposés par des concurrents plus modestes. L’utilisation des produits Microsoft et d’autres outils relativement simples se retrouve plus souvent chez les utilisateurs d’outils de gestion des exigences que chez les utilisateurs d’outils de modélisation209.

229.  Dans les secteurs des TI et financier, l’utilisation des outils de gestion des exigences de Telelogic est très limitée, notamment parce que la solution DOORS est jugée trop complexe et trop chère. Dans ces secteurs, le facteur prix occupe en effet une plus grande place que dans le secteur des systèmes. Les clients des secteurs des TI  et financier affichent une nette préférence pour Requisite Pro d’IBM et de nombreux autres fournisseurs d’outils de gestion des exigences.

230.  Même dans les cas où les clients jugent que les outils de gestion des exigences de Telelogic et d’IBM sont des produits de remplacement proches, cela ne pourrait pas permettre à l’entité issue de la concentration d’augmenter ses prix après la  concentration.

VII.2. Moins d’incitations à innover

231.  Il a été oté, dans la décision d'ouverture de la procédure, que certains clients craignaient, après la concentration proposée, une baisse de l'innovation résultant directement du manque de concurrence effective entre les différents outils de modélisation et de gestion des exigences. C'est la raison pour laquelle la Commission a examiné, au cours de son enquête approfondie, si l'entité issue de l'opération IBM/Telelogic rencontrerait ou pas moins d'incitations à innover qu’IBM et Telelogic séparément (c'est-à-dire en l'absence de l'opération notifiée).

232.  La partie notifiante avance l’argument selon lequel ce sont les besoins de la clientèle, et non la concurrence entre IBM et Telelogic, qui ont toujours été et continueront d’être les moteurs de l’innovation dans le domaine des outils de développement logiciel.

233.  À cet égard, la partie notifiante explique que l’évolution des outils d’IBM et de Telelogic ces dernières années a suivi des trajectoires différentes. Tandis qu’IBM concentrait ses investissements dans le développement d’outils de modélisation pour le développement logiciel des TI (par ex. […]*), Telelogic investissait dans le domaine de la modélisation, dans le développement d’outils pour le développement des logiciels de systèmes (par ex. […]*). IBM déclare aussi que les innovations majeures de Telelogic au cours des dernières années ont été consécutives à des consultations avec ses clients.

234.  La partie notifiante a donc expliqué qu’elle comptait intensifier ses projets innovants dans un avenir proche. IBM a ainsi précisé qu’elle «avait déjà prévu d’augmenter ses dépenses en R&D sur les produits Telelogic au lendemain de l’acquisition. En effet, le budget R&D 2006 de Telelogic se chiffrait à près de […]* millions USD, tandis que le

dossier commercial relatif à l’acquisition prévoit une hausse des dépenses de R&D jusqu’à […]* millions USD en 2008 et […]* millions USD à l’horizon 2012»210.

235.  En outre, IBM prétend que les outils libres, tels que CVS, Subversion, Bugzilla, JIRA ou Trac, sont de plus en plus utilisés par les équipes de développement des petites et moyennes entreprises, y compris par de petites équipes autonomes au sein de grandes entreprises.

236.  Enfin, IBM soutient qu’il est indispensable d’innover pour survivre dans un secteur à l’évolution aussi rapide que celui des logiciels, et que ça continuera d’être vrai après l’opération211. L’exemple des produits Rose d’IBM montre que le chiffre d’affaires d’un outil, même leader du marché, peut chuter […]* en relativement peu de temps si le produit n’est plus en phase avec les nouveaux besoins du marché.

237.  L’enquête approfondie a d’abord confirmé que la concurrence entre IBM et Telelogic n'a pas constitué, dans un passé récent, un élément essentiel les poussant à innover. Bien  que certains clients aient mentionné l’effet positif de la concurrence entre IBM et Telelogic sur l’innovation, les professionnels interrogés ont dans leur grande majorité expliqué que les innovations dans l’industrie du développement logiciel ont été réalisées sous l’impulsion de l’évolution des langages de modélisation (et notamment sous l’effet de la création du langage UML normalisé) et des besoins croissants de la clientèle212, en matière notamment de développement de logiciels de systèmes.

238.  Sur ce point, les clients spécialisés à la fois dans les logiciels de TI et les logiciels de systèmes ont confirmé que la concurrence reposait principalement sur les besoins des clients. Boeing, qui travaille sur le développement des logiciels de systèmes, déclare qu’elle «ne pense pas que la concurrence entre ces sociétés ait forcément encouragé l’innovation dans le domaine de la modélisation. Ce sont les besoins des clients qui ont intensifié la concurrence, ainsi que l’amélioration des normes de  l’UML»213. Concernant les outils de gestion des exigences, Boeing a également précisé que la concurrence entre les parties n’avait pas significativement encouragé l’innovation214.

239.  CSC, qui opère dans le développement des logiciels de TI, explique, concernant les  outils de modélisation que «ni IBM ni Telelogic n’a dominé le marché des outils de modélisation et que les deux entreprises ont dû innover face aux fournisseurs concurrents du marché. À la connaissance de CSC, qui se base sur les informations

actuelles, l’acquisition de Telelogic par IBM semble ne menacer en rien la poursuite de l’innovation sur le marché, en raison du nombre de fournisseurs»215. CSC a donné une réponse du même ordre concernant les outils de gestion des exigences. Et d’autres clients opérant dans les télécommunications216, l’électronique217, l’énergie218, la banque219 et le conseil en TI220 ont confirmé que la concurrence entre IBM et Telelogic n'a pas constitué, par le passé, un élément essentiel les poussant à innover.

240.  L’enquête approfondie a également révélé que, même si les produits d’exploitation libre ne semblent pas entrer en concurrence directe avec les outils de modélisation et de gestion des exigences d’IBM et de Telelogic, on s’attend dans un futur proche à voir se développer encore les offres d’exploitation libre dans ces deux catégories d’outils. Ceci devrait conduire à plus d’innovation dans les années à venir car les fournisseurs de logiciels commerciaux ressentiront le besoin d’enrichir leurs offres en nouvelles fonctionnalités afin de justifier l’écart de prix entre leurs produits et les produits libres.

241.  D’après une étude commandée par la Commission européenne221, les logiciels libres

«font potentiellement économiser à l’industrie plus de 36 % en R&D sur les logiciels, sommes qui peuvent soit venir s’ajouter aux bénéfices, soit être employées à meilleur escient pour de nouvelles innovations». L’étude met en lumière les relations évidentes entre le développement des logiciels libres, l’innovation et le secteur des nouvelles technologies de l’information, et conclut que les logiciels libres «permettent une diffusion de la technologie beaucoup plus étendue que les logiciels privés, notamment pour les futurs innovateurs potentiels qui n’ont pas à supporter les frais de recherche nécessaires pour localiser les sources d’innovations cachées dans les logiciels privés».

242.  Enfin, comme cela a été démontré ci-dessus en ce qui concerne les outils de modélisation et de gestion des exigences, les produits d'IBM et de Telelogic ne sont pas des produits de remplacement proches étant donné qu'ils proposent des fonctionnalités différentes, à des cibles de clients différentes. Ceci est notamment dû au fait qu’IBM travaille sur les applications des TI tandis que Telelogic s’adresse aux clients de développement des logiciels de systèmes. Par conséquent, les produits d’IBM et de Telelogic s'adressent généralement à des types de clientèles et de besoins différents.

243.  Compte tenu de ce qui précède, on en conclut donc que l'opération proposée n'est pas susceptible de freiner, dans un avenir proche, le rythme de l'innovation sur les marchés des outils de modélisation et de gestion des exigences.

VII.3. Baisse de l’interopérabilité des outils de logiciel

 VII.3.1. Effets non coordonnés non horizontaux : le verrouillage du marché par la baisse de l’interopérabilité des outils de logiciels

244.  La décision d’ouvrir une procédure a conclu dans un premier temps que l'opération proposée soulevait des doutes sérieux quant à sa compatibilité avec le marché commun , en raison du fait notamment que l'entité issue de la concentration serait moins encline à fournir des interfaces accessibles permettant l'intégration des outils de développement logiciel des tiers. IBM ressentirait moins le besoin d’enrichir ses propres outils de développement logiciel par des produits compatibles fournis par des tiers et aurait donc moins d’intérêts à permettre à des tiers fournisseurs d’accéder à ses interfaces logicielles.

245.  Un concurrent des parties (Microsoft), en particulier, a fait valoir que l'entité issue de la concentration aurait la capacité et des raisons d'évincer ses concurrents sur les marchés (ou segments de marché) des logiciels d'environnement de développement intégré (IDE: Integrated Development Environments), des outils de gestion de configuration et gestion des changements (SCCM: Software Change and Configuration Management), et de logiciels serveur d'application destinés à des plateformes (ASSP: application server software platforms)222.

246.  Plus précisément, Microsoft a fait valoir que l’entité issue de l'opération aurait la capacité, pour ses outils de modélisation et de gestion des exigences, de pratiquer la rétention d’informations essentielles à l’interopérabilité à l’encontre des fournisseurs concurrents des produits SCCM, IDE et ASSP. Ceci reviendrait à lier techniquement les ventes de produits SCCM, IDE et ASPP de l’entité issue de l'opération à ses outils de modélisation et de gestion des exigences. D’après Microsoft, l’entité issue de l'opération aurait des raisons de le faire aussi car cela lui permettrait de mettre à profit l’influence acquise sur les marchés des outils de modélisation et de gestion des exigences –  situation instaurée par la procédure de concentration – sur les marchés adjacents des produits SCCM, IDE et ASSP.

247.  Conformément aux lignes directrices sur l'appréciation des concentrations non horizontales223, la Commission s’est tout d’abord demandée224 si l’entité issue de la concentration aurait, après la concentration, la capacité d’empêcher l’accès aux outils des tiers en pratiquant, pour ses outils de modélisation et de gestion des exigences, la rétention d’informations essentielles à l’interopérabilité à l’encontre des fournisseurs concurrents des produits SCCM, IDE et ASSP. Deuxièmement, la Commission a examiné si les parties auraient intérêt à le faire et, troisièmement, si une stratégie de verrouillage du marché entraverait gravement le jeu de la concurrence.

VII.3.1.1. Capacité à verrouiller le marché

 Subordination technique

248.  Les IDE sont utilisés pour générer un code dans un langage de programmation qui peut ensuite être compilé en fonction de la plate-forme d’exécution souhaitée, autrement dit converti dans un format qui peut être exécuté sur le système informatique cible. Dans le contexte du cycle de vie du développement des logiciels, les IDE interviennent une fois que les exigences ont été déterminées et que le logiciel cible a été modélisé. On pourrait dire que la programmation ne fait qu’étoffer les modèles créés par les outils de modélisation.

249.  En règle générale, les ASSP permettent d’héberger des applications de prestation de services via les réseaux. Par exemple, les applications bancaires en ligne ou les applications de commerce électronique peuvent être hébergées sur des serveurs d’application spécialisés. Normalement, ce type de serveur interagit avec l’utilisateur en utilisant des éléments très similaires aux serveurs web. Ils utilisent la technologie de l’internet (et notamment l’Hypertext Transfer Protocol, HTTP) pour présenter une interface graphique de l’application à l’utilisateur et pour recevoir les données de l’utilisateur. Parmi les principaux exemples de plates-formes de serveurs d’application, on peut citer IBM WebSphere et Sun Java Enterprise Edition. Les ASSP sont importants vers la fin du cycle de vie du développement des logiciels. Une fois qu’un logiciel d’application destiné à être utilisé sur un réseau a été codé dans un IDE et a passé avec succès tous les tests de conformité à toutes les exigences applicables, il doit être mis en service, c’est-à-dire mis en production sur un ASSP. Il faut souligner que, sur  l’ensemble des logiciels élaborés, seuls quelques-uns auront besoin d’un ASSP pour être mis en service. Un grand nombre de logiciels sont prévus pour être exécutés directement sur l’ordinateur d’un utilisateur, autrement dit sans avoir à prévoir de liaison réseau  entre l’utilisateur et l’application. D’autres logiciels sont directement exécutés sur du matériel spécialisé et n’ont donc pas besoin d’être accessibles via des réseaux généralistes comme internet. C’est le cas par exemple des logiciels que l’on trouve dans les missiles, les satellites, les ordinateurs de bord des voitures, etc.

250.  Grâce aux serveurs SCCM, les équipes de développeurs peuvent collaborer simultanément à différentes phases du cycle de vie du développement des logiciels. Par exemple, le code de programmation produit dans un IDE est validé dans une base de données qui garde la trace des différentes versions et assure la transmission aux programmeurs qui veulent travailler sur une section spécifique du code la version la plus récente de la section en question. Le serveur garantit aussi que plusieurs personnes ne puissent pas valider des versions contradictoires de la même section du code logiciel.  Les serveurs SCCM peuvent aussi être utilisés pour stocker les modèles créés avec les outils de modélisation, ce qui permet aux différents membres de l’équipe de développement de collaborer sur les modèles sans risquer de créer des versions divergentes. De la même manière, les serveurs SCCM peuvent conférer des avantages conjoints aux autres outils utilisés dans le cycle de vie du développement des logiciels.

251.  Le développement logiciel est simplifié si les IDE sont dotés d’un accès direct aux modèles créés par les outils de modélisation et peuvent en extraire des informations. Les ASSP ne sont utiles que s’ils peuvent exécuter le code généré dans les IDE. Pour être utile, chaque serveur SCCM doit être en mesure de gérer les différents types d’informations en jeu et d’obtenir un certain degré de « connaissance » sur leur contenu. La gestion des exigences est nettement plus performante si une exigence peut être directement associée à une partie spécifique d’un modèle et à une section précise du  code logiciel, que si aucun lien technique permanent ne peut être établi entre les deux.

Tous ces exemples prouvent que l’existence d’un degré (variable) d’interopérabilité225 entre les divers outils susceptibles d’être utilisés au cours du cycle de vie du développement des logiciels offre de nombreux avantages pour les développeurs et est donc très recherché sur le marché de ces outils.

252.  L’entité issue de l'opération proposera ses produits dans l’ensemble des principaux segments de marché au service du cycle de vie du développement des logiciels. Microsoft prétend que l’entité issue de la concentration aurait la capacité d’évincer ses concurrents par le biais d’une subordination technique réalisée en pratiquant la rétention d’informations nécessaires à l’interopérabilité à l’encontre de la concurrence. Par exemple, l’entité issue de l'opération cacherait aux concurrents fournisseurs des produits SCCM, ASSP et IDE la manière dont leurs produits pourraient interagir avec l’offre d’outils de modélisation et de gestion des exigences de l’entité issue de la concentration.

253.  Il convient de noter pour commencer que le degré d’interopérabilité nécessaire pour les outils de modélisation et de gestion des exigences varie selon la nature de l’outil destiné à interopérer avec eux. À titre d’exemple, il ne faut quasiment aucune interopérabilité entre les outils de modélisation et de gestion des exigences et les ASSP. Au mieux, l’entité issue de l'opération pourrait donc n’avoir qu’un impact indirect sur ses concurrents fournisseurs d’ASSP, même si elle parvenait à entraver largement l’interopérabilité entre les outils de modélisation et de gestion des exigences et les SCCM et les IDE qui se trouvent normalement entre les deux en termes de circulation des informations.

254.  Selon la complexité des outils employés, l’interopérabilité nécessaire entre les IDE et les SCCM d’une part, et les outils de modélisation et de gestion des exigences d’autre part peut être relativement basique. Par exemple, il peut suffire que les serveurs SCCM se limitent à stocker, gérer et distribuer des fichiers contenant des informations sur les modèles, sans avoir besoin d’en connaître le contenu. On peut appliquer le même raisonnement aux IDE car chaque programmeur n’a besoin de connaître qu’une infime partie d’un modèle global et pourrait donc ne pas avoir à procéder à l’extraction automatique des informations des modèles – sa propre capacité d’inspecter visuellement un modèle peut être suffisante. Les outils de gestion des exigences sont typiquement fournis avec leurs propres serveur et base de données, si bien qu’ils n’ont pas besoin de serveurs SCCM pour permettre un travail en collaboration. Rien n’indique non plus que l’établissement d’un lien direct entre les exigences et les codes de logiciels ou les parties de modèle, au-delà d’un simple mappage des exigences avec le nom des procédures ou le nom des fichiers soit une pratique répandue dans l’industrie. Comme la technologie des bases de données sous-jacente est largement normalisée, la quantité d’informations essentielles à l’interopérabilité risquant d’être non divulguées est donc réduite.

255.  Ceci étant dit, on peut néanmoins conclure que l’entité issue de l'opération serait en mesure, concernant ses outils de modélisation et de gestion des exigences, de pratiquer  la rétention d’informations essentielles à l’interopérabilité à l’encontre de ses concurrents fournisseurs de produits SCCM, ASSP et IDE. C’est une observation purement technique car l’entité issue de la concentration pourrait par exemple choisir de présenter une solution de stockage de modèles dans des fichiers ou de stockage de données dans des bases de données qui serait privée, non normalisée et non divulguée. Tout fournisseur de logiciels dont les produits ont vocation à être utilisés d’une manière ou d’une autre par d’autres logiciels jouit en principe de ce droit.

256.  Certaines fonctionnalités des produits concernés ont toutefois un impact sur les retombées potentielles d’une telle rétention d’informations essentielles à l’interopérabilité. Comme indiqué plus haut, les outils de modélisation et de gestion des exigences sont très souvent employés à l’échelle d’un projet. Autrement dit, il est très rare de changer d’outil au milieu d’un projet. Bien entendu, tout changement portant sur les propriétés d’interopérabilité de ses outils de modélisation et de gestion des exigences ne peut s’appliquer qu’aux versions ultérieures du logiciel, et donc qu’aux nouveaux projets. Typiquement, l’interopérabilité est l’un des thèmes qui intéressent le plus les clients, précisément parce que le domaine du développement logiciel nécessite la coopération de plusieurs outils. Comme indiqué plus haut, la plupart des secteurs économiques ont le choix entre un grand nombre d’outils de modélisation et de gestion des exigences concurrents. Par conséquent, la capacité technique de rétention d’informations essentielles à l’interopérabilité se limiterait aux nouveaux projets.

VII.3.1.2. Intérêt à verrouiller le marché

 Marchés de produits liants

257.  La théorie de malveillance avancée par Microsoft ne pourrait être valable que dans le cas où l’entité issue de l'opération exercerait un certain pouvoir sur le marché du fait du processus technique des ventes liées de produits, en l’occurrence les outils de modélisation et de gestion des exigences. Comme indiqué dans les paragraphes précédents de cette décision, et compte tenu des caractéristiques concurrentielles des marchés concernés, la concentration ne saurait renforcer la dominance de la partie acquéreuse sur le marché. Ainsi, même si l’entité issue de la concentration bénéficiait d’une présence dominante sur le marché pour ces produits – ce qui n’est pas le cas –, cette règle s’appliquerait déjà à IBM seule. En conséquence, même si l’entité issue de l'opération était poussée à s’engager dans une stratégie de verrouillage du marché, cette incitation serait sans lien avec la concentration.

258.  Comme indiqué ci-dessus, dans de nombreux segments de marché, les parties comptent plusieurs concurrents sérieux. Dans d’autres segments de marché, les outils de Telelogic constituent à eux seuls une catégorie de produits, c’est-à-dire qu’ils ne sont pas en concurrence avec les produits d’IBM. On peut en conclure que la concentration n’offre pas une meilleure garantie de succès à la stratégie de verrouillage du marché redoutée par Microsoft en supprimant deux outils de modélisation (Rhapsody et TAU) et un outil de gestion des exigences (Doors) vers lesquels les clients auraient pu se tourner pour cause de manque d’interopérabilité.

259.  Telelogic est plutôt une petite entreprise mais elle occupe une part de marché significative sur les segments de marché des outils de modélisation et de gestion des exigences. On peut donc raisonnablement s’autoriser à penser que de grands groupes qui enregistrent des bénéfices substantiels, comme c’est le cas de Microsoft, seront en mesure de mettre sur le marché des produits de remplacement aux outils de l’entité issue de l'opération, si toutefois cette dernière tentait de contraindre ses clients à renoncer aux produits des fournisseurs concurrents sur les segments de marché concernés. Ceci modifierait profondément la structure de ces marchés. L’enquête approfondie n’a fait apparaître aucun obstacle technique particulier à l’entrée sur les marchés pour les  outils de modélisation et de gestion des exigences226. Ceci démontre que l’entité issue de l'opération s’exposerait à certains risques si elle décidait de s’engager dans la stratégie de verrouillage du marché décrite. En effet, elle pourrait inciter de nouveaux concurrents à pénétrer les marchés dans lesquels elle opère.

260.  Il existe quelques secteurs hyperspécialisés, principalement dans l’industrie automobile ainsi que dans l’avionique et la défense, dans lesquels les concurrents sérieux sont moins nombreux. Les projets lancés dans ces secteurs sont la plupart du temps de très gros projets dans lesquels le coût des logiciels ne revêt qu’une importance minime. Ces projets nécessitent aussi généralement d’étendre le support logiciel sur des décennies. Ainsi, les chefs de projets dans ces domaines choisissent avec soin les outils logiciels qu’ils veulent utiliser. Ce sont également les clients les plus exigeants et il est fréquent qu’ils demandent des logiciels conçus sur-mesure. Difficile d’imaginer dans ces circonstances comment l’entité issue de la concentration pourrait espérer vendre un outil de modélisation et de gestion des exigences non interopérable avec des outils qui sortent de l’offre de produits de l’entité issue de l'opération. Si les principales fonctionnalités de ces outils ont rencontré la satisfaction des utilisateurs, on pourrait considérer le manque (et peut-être le déni) d’interopérabilité délibéré et forcé comme l’absence d’une fonctionnalité critique.

Marchés de produits liés

261.  Il faut aussi garder à l’esprit que l’entité issue de l'opération aurait une part de marché inférieure à 30 % sur les marchés des produits IDE et ASSP. Il existe des concurrents de taille similaire sur les deux marchés. Concernant les produits SCCM, IBM occupe à elle seule une part de marché d’environ 45 %, que Telelogic ne contribuerait à augmenter que de 5 %. Deux autres concurrents ont des parts de marché dans la plage des 20 %.  Les clients de ces segments disposent donc d’un choix suffisant entre différents fournisseurs et rien n’indique qu’ils seraient prêts à changer de produits dans des catégories aussi stratégiques que les ASSP et à renoncer à leurs choix antérieurs dans le seul but de pouvoir utiliser un outil de modélisation ou un outil de gestion des exigences spécifique.

262.  Ce constat est étayé par un facteur supplémentaire: le fait qu’au moins les marchés des produits ASSP et IDE soient nettement plus vastes que les marchés de la modélisation et de la gestion des exigences227. Ainsi, il faudrait que les outils de modélisation et de gestion des exigences de l’entité issue de l'opération soient totalement indispensables et impossibles à remplacer, même à moyen terme, pour pousser les clients à opter pour des produits d’autres segments. Par exemple, la plupart des scénarios révèlent qu’il serait beaucoup moins onéreux de réécrire les interfaces existantes pour restaurer l’interopérabilité avec les produits de l’entité issue de l'opération (en supposant que ladite interopérabilité ait été préalablement refusée, selon la théorie de Microsoft) que de procéder à un changement d’offre très cher. Après tout, un tel changement, par exemple dans la catégorie des ASSP, est coûteux non seulement parce qu’il faut acheter de nouveaux logiciels, mais aussi en raison des coûts de formation, de l’interruption du service, de l’incompatibilité avec les logiciels d’application existants, etc. En revanche, l’adaptation des interfaces, si du moins elle est possible, nécessiterait au maximum de mettre quelques ingénieurs au travail et n’aurait aucun impact sur le travail des autres.

263.  Il faut également souligner que les produits ASSP et, dans une moindre mesure, les produits IDE, jouent un rôle beaucoup moins important sur le segment de marché du développement des systèmes (et notamment des systèmes embarqués) que dans le développement des applications des TI. Pour les produits ASSP, cela s’explique par le fait qu’un système embarqué est fourni avec sa propre plate-forme et ne nécessite pas de plate-forme généraliste du type IBM Websphere ou comme les plates-formes de Microsoft ou d’Oracle pour sa mise en service. S’agissant maintenant des IDE, la raison est que les systèmes embarqués n’ont généralement pas d’interface utilisateur et reposent sur du matériel informatique spécial qui permet à la modélisation des logiciels de progresser jusqu’à un niveau beaucoup plus précis. En conséquence de quoi un code généré automatiquement n’a pas à être traité de manière extensive, ce qui nécessite un recours bien moindre, voire aucun recours, aux IDE. Comme les produits de Telelogic ciblent très largement ce segment de marché pour le développement des systèmes, l’opération proposée ne transformera pas significativement la capacité actuelle d’IBM à tirer profit de la position qu’elle occupe sur les marchés de la modélisation et de la gestion des exigences pour s’imposer sur les marchés des produits ASSP et IDE.

Comportement antérieur

264.  Étant donné que l’IDE d’IBM, Eclipse, est un produit d’exploitation libre, il est difficile d’entrevoir la tactique qu’IBM pourrait mettre en œuvre pour faire appliquer strictement le principe d’une utilisation exclusive de ses propres outils de modélisation et de gestion des exigences avec Eclipse, et non avec Microsoft Visual Studio ou d’autres IDE. Il est contraire à l’idée même d’une plate-forme de développement d’exploitation libre, dont les tiers peuvent librement étendre les fonctionnalités à l’aide de modules externes, de pratiquer des méthodes de vente forcée en l’associant à des logiciels commerciaux privés. Eclipse, ainsi que le produit ASSP d’IBM, WebSphere, sont actuellement basés sur des standards libres, principalement Java, pour lesquels d’autres fournisseurs proposent une multitude d’outils à toutes les phases du cycle de vie du développement des logiciels. Face aux nouvelles contraintes ou restrictions de la part de l’entité issue de la concentration, ses clients actuels auraient donc la possibilité de se tourner vers d’autres fournisseurs. Tout espoir de réussite d’une stratégie de verrouillage du marché implique un net changement de cap par rapport au modèle commercial d’IBM concernant les outils dont il est question. Les documents internes des parties n’indiquent nulle part qu’une telle stratégie ait pu être rien qu’envisagée par IBM pour justifier l’acquisition de Telelogic.

265.  Microsoft fait également savoir qu’il a des projets pour réaliser l’interopérabilité entre le produit de gestion des exigences de Telelogic, Doors, et son propre produit SCCM, mais que Telelogic a mis fin aux pourparlers peu avant l’annonce par IBM de son offre de rachat. Microsoft voit dans cette démarche un premier signe qu’IBM amorce une stratégie de verrouillage du marché.

266.  Pourtant, l’offre SCCM de Microsoft représente une très faible part de marché dans le secteur des serveurs SCCM. Il apparaît donc clairement qu’il n’est pas dans les priorités de Telelogic, ni même dans celles de l’entité issue de l'opération, de s’assurer que Doors fonctionne aussi avec le produit SCCM de Microsoft. À cet égard, il est intéressant de noter que Microsoft ne déclare pas la non interopérabilité de Doors avec les plus grandes offres des tiers sur le marché des SCCM, par exemple les produits Computer Associates ou Serena.

VII.3.1.3. Coûts et bénéfices

267.  Pour s’engager dans une telle stratégie, les coûts supportés incluent a) le manque à gagner sur les ventes liées de produits lorsque les clients décident de ne pas se laisser enfermer dans le système; b) le manque à gagner sur les ventes liées de produits lorsque les concurrents décident de pénétrer les marchés pour satisfaire la demande d’outils haut de gamme interopérables; c) le manque à gagner sur les ventes liées de produits (IDE, ASSP, SCCM) lorsque les clients décident de se passer de l’un des produits de l’entité issue de l'opération par crainte de s’enfermer encore plus dans le système  ultérieurement; d) une perte générale de notoriété, particulièrement si l’on tient compte du comportement passé d’IBM sur les marchés concernés, plutôt favorable à l’interopérabilité et aux standards ouverts. Chacune de ces quatre catégories de coût est potentiellement substantielle et aucune d’elles ne peut être évitée dès le départ.

268.  Les bénéfices potentiels, d’autre part, proviennent de la hausse du chiffre d’affaires généré par les ventes liées de produits. Ces bénéfices seraient possibles si la stratégie de verrouillage du marché devenait effective et si des clients, qui auraient dans d’autres circonstances utilisé les produits IDE, ASSP et SCCM d’autres sociétés, choisissent les produits de l’entité issue de l'opération appartenant à ces catégories afin de pouvoir (continuer à) utiliser les outils de modélisation et de gestion des exigences de l’entité issue de la concentration. Comme indiqué plus haut, le groupe de clients le plus attaché  à continuer d’utiliser Doors ou Rhapsody (au lieu d’opter pour les outils de modélisation et de gestion des exigences des concurrents) est aussi celui qui regroupe les plus gros clients, avec des exigences spécialisées et des durées de service prolongées. Ils sont moins regardants quant au prix du logiciel qu’ils achètent mais sont plus exigeants en termes de fonctionnalités et de convivialité. Ces clients sont donc les mieux placés pour exercer un pouvoir d’achat compensateur sur l’entité issue de la concentration. Il se trouve que ces clients, parce qu’ils sont largement concentrés dans le domaine du développement des systèmes, sont aussi les moins enclins à utiliser des IDE généralistes (par exemple Eclipse) ou même à recourir à un produit ASSP. En conséquence, le bénéfice potentiel d’une stratégie de verrouillage du marché est relativement limité et il est impossible d’affirmer avec certitude qu’un quelconque bénéfice pourrait en résulter.

VII.3.1.4. Conclusion sur l’interopérabilité

269.  À la lumière des arguments énoncés ci-dessus, l’évaluation globale de l’impact potentiel, en termes de prix et de choix, d’une éventuelle stratégie de verrouillage du marché engagée par l’entité issue de l'opération, permet de tirer une conclusion claire. Une stratégie de verrouillage du marché ne peut réussir vu les caractéristiques des marchés des outils de modélisation et de gestion des exigences, surtout des outils haut de gamme. Même si techniquement il était possible de masquer les protocoles de communication et les formats de fichiers afin d'empêcher l'interopérabilité de ses outils avec les outils des tiers, l'entité issue de la concentration n'aurait aucun intérêt à s'engager dans une telle stratégie puisque les coûts en seraient largement excessifs par rapport aux bénéfices.

VII. CONCLUSION

Pour les raisons énoncées ci-dessus, il a été conclu que la concentration proposée ne soulèverait pas de problèmes de concurrence susceptibles d'entraver de manière significative une concurrence effective au sein du marché commun ou dans une  partie substantielle de celui-ci. En conséquence, la concentration est déclarée compatible avec le marché commun et l'accord EEE,

A ARRÊTÉ LA PRÉSENTE DÉCISION:

Article premier

 La concentration notifiée, par laquelle International Business Machines Corporation acquiert au sens de l'article 3, paragraphe 1, point b), du règlement (CE) N° 139/2004, le contrôle de l'ensemble de l'entreprise Telelogic AB, est déclarée compatible avec le marché commun et l'accord EEE.

159 Voir, par exemple, le procès-verbal de l’entretien avec Lockheed Martin réalisé le 30 novembre 2007.

160  Voir,  par  exemple,  la  réponse  de  Thales  du  8 novembre 2007  à  la  question 12  de  la demande de renseignements de la Commission : « Nous utilisons Rhapsody pour les systèmes en temps réel, et  RSA

pour les systèmes informatiques et qui ne sont pas en temps réel ».

161 Voir, par exemple, les réponses de Boeing du 7 novembre 2007 et de Safran du 31 octobre 2007 à la question 7 de la demande de renseignements de la Commission.

162 Voir la communication d’IBM du 20 novembre 2007.

163 Voir le Rapport sur le programme de renseignement logiciel du marché intégré de VDC, année 2006,

p. 33, présenté à la Commission par IBM le 11 septembre 2007.

164  Voir la communication d’IBM du 20 novembre 2007.

165   L’Institut européen des normes de télécommunications (ETSI) est une organisation de normalisation indépendante à but non lucratif de l’industrie des télécommunications (fabricants d’équipements et

opérateurs de réseaux) en Europe, avec une projection mondiale. L’ETSI a réussi à normaliser le système de téléphones portables GSM et le système radio mobile professionnel TETRA.

166  Voir   la   réponse   d’Alcatel/Lucent   du   7 novembre 2007   à   la   question 15   de   la   demande   de

renseignements de la Commission. « Les outils UML sont mieux adaptés à toutes les applications finales, à l’exception des protocoles pour lesquels SDL est plus adapté ».

167  Voir la communication d’IBM du 20 novembre 2007.

168  Voir, par exemple, les réponses de General Motors du 8 novembre 2007 à la question 12 de la demande de renseignements de la Commission. General Motors confirme que : « L’outil principalement utilisépar GM est Rhapsody. RoseRT est employé pour des projets avec d’autres équipementiers ».

169 Voir, par exemple, la réponse de Motorola du 8 novembre 2007 à la question 12 de la demande de renseignements de la Commission.

170 Voir la communication d’IBM du 20 novembre 2007.

171 Voir,  par  exemple,  la  réponse  d’UBS  du  1er   novembre  2007  à  la  question 8  de  la   demande  de renseignements de la Commission : « Notre principal critère est de savoir si les outils sont adaptés au besoin spécifique auquel nous tentons de répondre à un prix raisonnable ».

172 Voir par exemple les réponses d’UBS le 1er novembre 2007, de l’ ABNAMRO le 2 novembre 2007, de

Texas Instruments le 8 novembre 2007 et d’Unisys le 7 novembre 2007 à la question 7 de la demande de renseignements de la Commission. Toutes ces sociétés utilisent les outils de modélisation d’IBM seuls ou en parallèle avec d’autres outils de modélisation. Aucune de ces sociétés n’utilisent les outils  de modélisation de Telelogic.

173  La liste des éléments à fournir a été étendue au cours de la procédure. Les détails énumérés dans le texte correspondent à la liste finale.

174  “Cela  inclut  un  grand  nombre  de  situations  commerciales,  allant  des  « appels    d’offre »  formels (« RFP ») à des demandes de client ad hoc d’ « extension » de produits ou encore des situations dans lesquelles le client ne projette pas d’acquérir un outil de modélisation […] (ceci pourrait impliquer des sollicitations au hasard ou des tentatives d’incitation à la vente d’un […] outil où le client recherchait initialement des propositions d’outil différent) ’’. Voir le rapport de LECG intitulé “Telelogic’s  win/loss data (« Données gains / pertes de Telelogic : description et limites), daté du 27 novembre 2007, pages 2 et 3. Telelogic collecte également les memoranda « win flash ». Ces rapports sont souvent produits lorsque les vendeurs de Telelogic réalisent un bénéfice commercial significatif. Malheureusement, la plupart des “win flashes” datent de 2004 ([…]*) et seulement […]* par an sont disponibles pour les années suivantes. […]*. Par conséquent, les win flashes n’ont pas été pris en compte dans cette analyse.

175  Ces contrôles ont été effectués par le biais d’entretiens avec les clients. Etant donné la contrainte de temps,  la  liste  des  clients  a  été  limitée  aux  clients  où  Telelogic  a  identifié  en  tant  que produits

concurrents des produits patrimoniaux d’IBM lorsqu’identifiés ou de produits IBM lorsqu’identifiés sans détails.

176 En raison de la nature de la “base de données d’opportunités” de Telelogic, cet ensemble d’opportunités

risque de ne pas totalement représenter et décrire tous les processus d’achat auxquels Telelogic a pris part. En particulier, Telelogic explique que: "[…]*." Voir le rapport de LECG intitulé “Telelogic’s win/loss data: description and limitations" («Données gains/pertes de Telelogic: description  et limites»), daté du 27 novembre 2007.

177  Sur la base des données relatives aux revenus soumises par les parties, les revenus des licences de Telelogic pour la période 2006 - troisième trimestre 2007 relatives aux produits de modélisation de couverture de la base de données gains/pertes semble être suffisante pour permettre un certain degré d’analyse.

178 Cabinet de services d’experts employé par IBM.

179  Pour  certains  sous  segments,  par  exemple  une  industrie  spécifique  ou  une       zone  géographique spécifique, la base de données peut contenir très peu d’opportunités d’affaires dans lesquelles les parties fusionnant se retrouvent, par exemple, une seule. 

180 Voir la communication d’IBM du 21 novembre 2007 qui fournit un descriptif de son outil de gestion des exigences.

181 Voir la communication d’IBM du 21 novembre 2007.

182 La licence de DOORS Fastrak limite la fonctionnalité qui peut être utilisée dans Focal Point, voir la communication d’IBM du 12 décembre 2007.

183 Dans l’industrie des logiciels, un produit « clés en main » désigne normalement un logiciel facile à installer, qui ne nécessite aucune personnalisation et simple d’utilisation.

184  Voir la communication d’IBM du 12 décembre 2007.

185 Voir la communication d’IBM du 24 septembre 2007.

186 Voir la communication d’IBM du 24 septembre 2007.

187 Voir […]* dans la communication d’IBM du 21 novembre 2007.

188   Voir   par   ex.   SDL   (Langage   de   description   et   de   spécification)   utilisé   dans l’industrie  des télécommunications, UPDM utilisé dans l’industrie aérospatiale et l’industrie de la défense, AADL (Langage de conception, d’analyse et d’architecture) utilisé dans l’industrie automobile, BPMN (Notation de la modélisation des processus d’entreprise) et BRM (Gestion des règles d’entreprise) utilisés pour le développement de logiciels informatiques.

189 Voir […]* dans la communication d’IBM du 21 novembre 2007.

190  Voir […]* dans la communication d’IBM du 21 novembre 2007.

191  […]*.

192  Voir la communication d’IBM du 4 décembre 2007 contenant une étude de LECG sur la distribution des recettes des parties par secteur de l’industrie.

193  Voir la communication d’IBM du 23 août 2007 qui commente et analyse la feuille de route des produits de […]*.

194   "[…]*", 7 août 2006, p.12. Document joint en annexe 8 à la réponse d’IBM du 5 novembre 2007 à la demande de renseignements de la Commission.

195 Voir la réponse donnée par Safran le 31 octobre 2007 à la question 59 de la demande de renseignements de la Commission. Safran estime que « Doors est un outil  universel  dans  la  communauté  aérospatiale ». Voir aussi la réponse d’Elbit du 2 novembre 2007 à la question 59 de la demande de renseignements de la Commission : « Nous utilisons Requisite Pro pour certains de nos projets traditionnels. Nous avons jugé Requisite Pro inadapté pour les projets de grande envergure et à ce jour Doors est un standard en matière de gestion des exigences. Pour l’heure je ne vois aucune alternative valable à Doors ».

196 Voir par exemple la réponse de Thales du 8 novembre 2007 à la question 57 de la demande de

renseignements de la Commission. Thales répond, au sujet du système Telelogic Doors : « Il existe bien d’autres fournisseurs (IBM, Borland, Serena,…) mais leurs produits sont loin d’apporter le même niveau de fonctionnalités et de performances que Doors ».

197 Voir  par  exemple  la  réponse  de  Safran  du  31  octobre  2007  à  la  question  54  de  la demande  de renseignements de la Commission. Safran utilise Doors pour la gestion des exigences systèmes et

produits, mais utilise Requisite Pro pour la gestion des exigences logicielles. Voir aussi la réponse de Northrop Grumman du 15 janvier 2008 à la question 59 de la demande de renseignements de la Commission : « Le choix entre les deux produits de gestion des exigences dépend du type d’effort de développement entrepris. Dans le cadre d’une suite de programmes, et si le projet est largement orienté développement logiciel, la suite d’outils d’IBM Rational est souvent retenue à des fins d’intégration avec d’autres outils de gestion logicielle CASE (ingénierie logicielle assistée par ordinateur) dans la suite Rational […]. Si le projet associe développement de systèmes et développement de logiciels, ou s’il porte principalement sur le développement systèmes/composants, l’outil Telelogic DOORS est souvent choisi pour être intégré à la fois à Telelogic System Architect et à Telelogic TAU ».

198  Voir  par  exemple  la  réponse  d’Audi  du  8  novembre  2007  à  la  question  55  de  la    demande  de renseignements de la Commission, selon laquelle Doors est de facto l’outil standard de gestion des exigences pour l’industrie automobile. Voir aussi la réponse de Daimler du 8 novembre 2007 à la question 55 de la demande de renseignements de la Commission : « Telelogic Doors est la suite d’outils la plus importante en gestion des exigences. Doors étant utilisé dans un grand nombre de projets, la plupart des projets à venir vont suivre ce quasi-standard ».

199  Voir par exemple la réponse de Conti du 22 novembre 2007 à la question 59 de la demande de renseignements de la Commission. « Nous utilisons Doors parce que nos clients utilisent Doors et qu’à

l’heure actuelle les alternatives présentes sur le marché sont très insatisfaisantes. » Voir aussi la réponse de HD Leopold Kostal du 31 octobre 2007 à la question 59 de la demande de renseignements de la Commission : « Même si certains outils de gestion des exigences pourraient être une alternative à la solution Telelogic Doors, il ne faut pas oublier que c’est la solution qu’utilisent la plupart des constructeurs automobiles, et qu’adopter un système différent compliquerait l’échange de données ».

200   Voir par exemple la réponse de Conti du 22 novembre 2007 à la question 56 de la demande de renseignements de la Commission. Conti cite les outils de gestion des exigences de Borland Caliber et MKS RM (aucune mention des outils d’IBM).

201 Voir par exemple la réponse de Daimler du 8 novembre 2007 à la question 59 de la demande de

renseignements de la Commission sur la question du degré de substitution possible entre les outils de gestion des exigences d’IBM et de Telelogic. « Nous n’avons pas jusqu’à présent constaté de concurrence entre IBM et Telelogic. […] Les suites d’outils d’IBM ont d’autres finalités ». Voir aussi les réponses de Conti et d’Audi citées dans les trois notes de bas de page précédentes, ainsi que les réponses de Porsche (30 octobre 2007) et de HD Leopold Kostal (31 octobre 2007) à la question 54 de la demande de renseignements de la Commission.

202 Les story-boards sont des organiseurs graphiques qui prennent la forme d’une série d’illustrations ou d’images affichées en séquence dans le but de prévisualiser un graphique animé ou une séquence média

interactive, et basées sur l’interactivité des sites web.

203 Voir par exemple la réponse d’AT&T du 2 novembre à la question 60 de la demande de renseignements de la Commission : « La majorité de nos groupes de développement utilisent MS/Excel ou MS/Word pour documenter, suivre et gérer les exigences ».

204  Voir par exemple la réponse de Motorola du 8 novembre aux questions 59 et 62 de la demande de

renseignements de la Commission : « Telelogic Doors est notre outil de gestion des exigences préféré. Le produit Doors est largement utilisé chez Motorola. » Requisite Pro d’IBM est également utilisé dans une certaine mesure: « Requisite Pro a été choisi […] par des sociétés absorbées qui l’utilisent depuis longtemps et pour lesquelles le changement de produit aurait trop perturbé les activités. De manière générale, les utilisateurs qui choisissent Requisite Pro ne le font qu’en comparaison des fonctionnalités de la suite avec d’autres produits Rational. Pris seul, Doors est supérieur et c’est la solution de gestion des exigences que nous préconisons. »

205 Voir la communication d’IBM du 20 novembre 2007.

206  Voir par exemple la réponse de ABNAMRO du 2 novembre 2007 aux questions 54 et 59 de la demande de renseignements de la Commission et la réponse de l’administration fiscale néerlandaise du 1er novembre 2007 aux questions 17, 54 et 56 de la demande de renseignements de la Commission.

207  Voir la réponse de l’administration fiscale néerlandaise du 1er  novembre 2007 à la question 17 de la demande de renseignements de la Commission: « Il existe encore de nombreux projets qui capturent leurs exigences dans Word ou Excel.»

208  Voir la réponse d’Unisys du 7 novembre 2007 à la question 58 de la demande de renseignements de   la

Commission : « Rational Requisite Pro, qui fait partie de la suite Rational, est utilisé pour des projets qui reposent sur une équipe co-localisée chargée du développement des applications. […] La solution Doors de Telelogic est utilisée de la même manière que Requisite Pro sur les projets, mais elle repose sur de grandes équipes distribuées. Dans l’environnement du développement, l’utilisation de Telelogic Doors est exclusivement réservée à la gestion des exigences à travers un portefeuille de logiciels, de matériels et de produits systèmes développés par les équipes distribuées.

209  Cette tendance peut s’expliquer par le fait que, selon le niveau de traçabilité et de suivi des exigences souhaité par une société, l’activité elle-même est relativement simple et peut donc se passer d’outils complexes.

210 Voir la communication d’IBM du 24 septembre 2007 sur les préoccupations exprimées par les clients au cours du test de marché relatif à la gestion de Rational par IBM.

211  Par exemple, concernant la modélisation, IBM déclare que […]* a développé un meilleur support […]* que […]*; que […]* a fait un bien meilleur usage de la technologie de l’internet que […]*, et que TNI a

développé un produit de passerelle très réussi pour le transfert d’informations entre différents produits. Dans le domaine de la gestion des exigences, IBM a cité MKS et IRqA comme exemples de sociétés ayant réussi à accroître leur présence en développant des interfaces utilisateur à la pointe de la technologie.

212  Par  exemple  Siemens,  dans  sa  réponse  du  2  novembre  2007  à  la  question  82  de  la demande de renseignements de la Commission aux clients, a affirmé que « L’innovation devait davantage à la

demande du marché qu’à la concurrence entre IBM et Telelogic. Aucune des deux entreprises ne parvient actuellement à répondre à l’ensemble des demandes. IBM s’est davantage tournée vers le marché des applications web et Telelogic vers le marché du développement des systèmes. 

213  Voir par exemple la réponse de The Boeing Company du 7 novembre 2007 à la question 49 de la demande de renseignements de la Commission aux clients.

214  « Boeing n’a pas considéré cette concurrence comme un élément poussant à l’innovation dans les produits  de  gestion  des  exigences  de  ces  fournisseurs »  (réponse  de  The  Boeing  Company  du  7

novembre 2007 à la question 83 de la demande de renseignements de la Commission aux clients).

215 Voir par exemple la réponse de CSC Computer Sciences du 5 novembre 2007 à la question 49 de la demande de renseignements de la Commission aux clients.

216  Voir par exemple Siemens, Infineon (réponse du 2 novembre aux questions 49 et 83 de la   demande de renseignements de la Commission aux clients).

217 Par  exemple,  Texas  Instruments  a  signalé  « n’avoir  connaissance  d’aucun  cas  ou  exemple        de

concurrence entre IBM et Telelogic qui aurait été un facteur essentiel pour l’innovation dans le domaine des outils de gestion des exigences au cours des 3 dernières années.» (Réponse du 8 novembre to question 83 de la demande de renseignements de la Commission aux clients).

218  Par exemple, AREVA T&D Automation a répondu: « Je pense qu’IBM a perdu en compétitivité dans le

domaine des outils de modélisation et que Telelogic a été poussé par les autres fournisseurs à améliorer ses produits » (Réponse du 16 novembre à la question 49 de la demande de renseignements de la Commission aux clients).

219 Par exemple RBS a indiqué « Rien ne nous autorise à penser que la concurrence entre IBM et Telelogic ait été déterminante en termes d’innovation », que ce soit pour la modélisation ou pour la gestion des

exigences (réponse du 2 novembre aux questions 49 et 83 de la demande de renseignements de la Commission aux clients).

220  Par exemple, UNYSIS Corp. a répondu : « Nous refusons de croire que cette concurrence ait eu le

moindre effet déterminant sur l’innovation » (modélisation) et « Nous n’avons pas l’impression que cette concurrence ait été un déclencheur pour l’innovation » (gestion des exigences). Réponse du 7 novembre aux questions 49 et 83 de la demande de renseignements de la Commission aux clients.

221 «Study on the: Economic impact of open source software on innovation and the competitiveness  of the Information and Communication Technologies (ICT) sector in the EU (Final report)» (Étude sur les répercussions économiques des logiciels d'exploitation libre sur l'innovation et concurrence du secteur des technologies de l'information et des communications dans l’UE (Rapport final)). Préparé par Rishab Aiyer Ghosh (MERIT) le 20/11/2006. (http://ec.europa.eu/enterprise/ict/policy/ict/2006-11-20- lossimpact.pdf)

222  Communications de Microsoft du 26 octobre 2007, du 23 novembre 2007 et du 14 janvier 2008.

223  http://ec.europa.eu/comm/competition/mergers/legislation/nonhorizontalguidelines.pdf

224 Conformément aux lignes directrices sur l'appréciation des concentrations non horizontales.

225  Il  y  a  « interopérabilité »  en  présence  de spécifications  complètes  et  précises  sur  tous les moyens techniques utilisés pour échanger des informations entre différents produits logiciels et pour une utilisation réciproque des informations qui ont été échangées. Ce concept peut caractériser à la fois les protocoles de communication (réponse à la question « Comment les informations spécifiques sont-elles communiquées entre différents types de produits logiciels ? ») et les formats de fichiers (réponse à la question « Comment les informations spécifiques sont-elles enregistrées sur un fichier informatique ?).

226 A ce sujet, dans sa réponse du 21 novembre 2007 à la question 44 de la demande de  renseignements de la Commission aux concurrents, Artisan a répondu : « Il faut franchir de sérieux obstacles pour obtenir l’expertise nécessaire, mais le développement d’un nouvel outil de modélisation ne comporte aucun obstacle technique général ». Sybase, un autre concurrent, dans sa réponse du 28 novembre 2007 à la question 44 de la demande de renseignements de la Commission aux concurrents, a déclaré : « Sybase  ne voit pas d’autre obstacle précis à l’exception du coût des travaux de recherche et développement ». Kennedy Carter, s’il admet que: « Le développement d’un outil de modélisation graphique comporte quelques obstacles techniques », conclut en disant « On connaît néanmoins un certain nombre d’initiatives visant à réduire les obstacles globaux au développement de nouvelles solutions. Eclipse donne l’accès à un certain nombre d’outils qui pourraient être utilisés pour élaborer une solution complète autour d’un outil de modélisation. Par exemple, de nombreux projets d’exploitation libre basés sur Eclipse ont commencé à mettre des générateurs de codes à la disposition des outils de modélisation UML « standard ». Les fournisseurs d’outils intéressés par le développement d’outils de modélisation non-UML tireraient des bénéfices similaires de l’utilisation d’outils basés sur Eclipse. » (réponse du 2 novembre 2007 à la question 44 de la demande de renseignements de la Commission aux concurrents).

227 Gartner évalue le marché international de la modélisation à 245,7 milliards USD (Source : « Gartner Dataquest, Application Development and Project and Portfolio Management Software (logiciel de développement d’applications et de gestion de projets et de portefeuilles) », 2006) et le marché international de la gestion des exigences à 171,1 milliards USD (Source: «Gartner Dataquest, logiciels de développement d’application et de gestion de projets et de portefeuille» 2006, […]*) en 2006. En revanche, le marché des ASSP s’élève à 4524,1 milliards USD (annexe 1 à la communication de Microsoft du 23 novembre 2007).

1  JO L 24 du 29.1.2004, p. 1

2  JO C … du ...200. , p....

3  JO C … du ...200. , p....

4   Telelogic et IBM sont collectivement désignées comme «les parties».

5   […]*, mars 2007, page 3. Document soumisd en annexe 11 de la réponse d’IBM du 5 novembre 2007 à la demande de renseignements de la Commission du 19 octobre 2007.

6    Unified Modelling Language (ULM): langage de modélisation unifié: langage de modélisation général, ouvert et standard.

7  «Selecting The Right Requirements Management Tool – Or Maybe None Whatsoever», Forrester, 28 septembre 2007, page 2. Document soumis en annexe 15 de la réponse d’IBM du 5 novembre 2007 à la demande de renseignements de la Commission du 19 octobre 2007.

8 Par ex., VsWorkd, Windows CE ou des systèmes d’exploitation exclusifs internes.

9    See IBM's response of 5 November 2007 to question 23 of the Commission request for   information of 19 October 2007.

10  RSA  est  la  combinaison  des  sur-ensembles  de  Rational  Systems  Developer  («RSD»)  et  Rational Software Modeler («RSM»).

11    Voir la réponse d’IBM du 5 novembre 2007 à la question 23 de la demande de renseignements de la

Commission du 19 octobre 2007.

12  Voir […]*, page 3. Document soumis par IBM le 8 novembre 2007.

13  Voir […]*, document soumis par IBM le 19 octobre 2007 et […]*, document soumis par IBM le 18 octobre 2007.

14    Voir «Dataquest Guide: Software market Research Definitions», Gartner, 15 mars 2007, pages    56-57.

Document soumis par IBM le 26 octobre 2007

15  Voir […]*, pages 3-4. Document soumis par IBM le 20 novembre 2007.

16    Voir […]*, page 4. Document soumis par IBM le 25 septembre 2007.

17  Voir […]*, page 3. Document soumis par IBM le 24 septembre 2007.

18  Voir […]*. Document soumis en annexe 6 de la réponse d’IBM du 5 novembre 2007 à la demande de renseignements de la Commission du 19 octobre 2007.

19  Voir la réponse d’IBM du 5 novembre 2007 à la question 16 de la demande de renseignements de la Commission du 19 octobre 2007.

20    Voir […]*. Document soumis en annexe 6 de la réponse d’IBM du 5 novembre 2007 à la demande de renseignements  de  la  Commission  du  19  octobre  2007.  Voir  également  la  réponse  d’IBM  du 5

novembre 2007 à la question 6 de la demande de renseignements de la Commission du 19 octobre 200

21    Voir […]*. Document soumis en annexe 6 de la réponse d’IBM du 5 novembre 2007 à la demande de renseignements de la Commission du 19 octobre 2007. Voir également la réponse d’IBM du 5 novembre 2007 à la question 6 de la demande de renseignements de la Commission du 19 octobre 2007.

22   Voir la réponse d’IBM du 5 novembre 2007 à la question 16 de la demande de renseignements de la Commission du 19 octobre 2007.

23  Voir «IDC's Software Taxonomy, 2007», page 2. Document soumis par IBM le 19 septembre 2007.

24   Voir les réponses à la question 7 de la demande de renseignements de la Commission envoyée aux concurrents.

25  Voir […]*. Document soumis en annexe 7 de la réponse d’IBM du 5 novembre 2007 à la demande de renseignements de la Commission du 19 octobre 2007.

26   Voir les réponses aux questions 8 (Outils de modélisation) et 55 (Outils de gestion des exigences) de la demande de renseignements de la Commission envoyée aux clients.

27   […]*

28   "IDC's Software Taxonomy, 2007", page 96. Document submitted by IBM on 19 September 2007.

29     «IDC's Software Taxonomy, 2007», page 97. Document soumis par IBM le 19 septembre 2007.

30 «IDC's Software Taxonomy, 2007», page 104. Document soumis par IBM le 19 septembre 2007.

31   Voir par exemple […]*, 30 octobre 2007, page 40. Document soumis en annexe 10 de la réponse d’IBM du 5 novembre 2007 à la demande de renseignements de la Commission du 19 octobre 2007.

32  Voir http://www.eclipse.org/

33  Voir http://www.omg.org/

34   Voir Notification, page 37.

35  Voir Notification, page 37.

36  Considérant 41 de la décision de la Commission du 3 octobre 2007 d’engager la procédure.

37  […]*, 29 mars 2004, page 14. Document soumis en annexe 11 de la réponse d’IBM du 5 novembre 2007 à la demande de renseignements de la Commission du 19 octobre 2007.

38  Voir la décision de la Commission du 20 février 2003, Affaire COMP/M.3062 – IBM/Rational, para. 57.

39 Voir  les  décisions  de  la  Commission  du  22  décembre  2005  dans  l’affaire  COMP/M.3978  –

Oracle/Siebel et du 26 octobre 2004 dans l’affaire COMP/M.3216 – Oracle/Peoplesoft.

40  Voir le considérant 25 de la décision de la Commission du 3 octobre 2007 d’engager la procédure.

41  Voir les réponses aux questions 26 (Outils de modélisation) et 60 (Outils de gestion des exigences) de la demande de renseignements de la Commission envoyée aux clients.

42   Voir les réponses aux questions 27 (Outils de modélisation) et 61 (Outils de gestion des exigences) de la

demande de renseignements de la Commission envoyée aux clients.

43  Voir la réponse d’Areva du 16 novembre 2007 à la question 27 de la demande de renseignements  de la Commission envoyée aux clients.

44   http://www.topcased.org/

45  Voir les réponses à la question 29 (Outils de modélisation) et 61 (Outils de gestion des exigences) de la demande de renseignements de la Commission envoyée aux concurrents.

46  Voir la réponse d’Artisan du 2 novembre 2007 à la question 29 de la demande de renseignements  de la Commission envoyée aux concurrents.

47                    […]*

48                    […]*

49  Voir […]*, page 14. Document soumis par IBM le 25 septembre 2007.

50                    […]*

51  Voir la réponse de Qinetiq du 2 novembre 2007 à la question 26 de la demande de renseignements de la Commission envoyée aux concurrents.

52 Voir les réponses à la question 29 de la demande de renseignements de la Commission envoyée aux concurrents.

53     [Nom de la société : CONFIDENTIEL] réponse à la question 29 de la demande de renseignements de laCommission envoyée aux concurrents. .

54  [Nom de la société : CONFIDENTIEL] réponse à la question 29 de la demande de renseignements de la Commission envoyée aux concurrents. .

55  «Open-Source Modelling Tools Maturing, but Need Time to Reach Full Potential», 20 avril 2007. Disponible sur http://www.gartner.com/DisplayDocument?id=503940&ref=g_sitelink.

56 «DSL» signifie Langages à domaine spécifique (voir ci-dessous).

57   «Balancing The Costs and Benefits Of Software Modelling», 8 mars 2007, page 11.   Document soumis en  annexe  15  à  la  réponse  d’IBM  du  5  novembre  2007  à  la  demande  de  renseignements  de  la Commission du 19 octobre 2007.

58   Voir  «Microsoft  Sees  The  Future  of  Software  in  Modelling»,  InformationWeek,  30 octobre 2007. Document soumis par la partie notifiante le 30 octobre 2007.

59  Voir «Magic Quadrant for OOA&D Tools, 2h06 to 1H07», Gartner, 30 mai 2006, pages 6 et 11. Document soumis en annexe 3 du document d’IBM «Comments on feedback from the market test

relating to Object-Oriented analysis and design tools» du 25 septembre 2007.

60  Voir «Selecting The Right Requirements Management Tool – Or Maybe None   Whatsoever», Forrester, 28 septembre 2007, pages 5-8. Document soumis en annexe 15 de la réponse d’IBM du 5 novembre 2007 à la demande de renseignements de la Commission du 19 octobre 2007.

61 Voir  la  décision  de  la  Commission  du  27  avril  2007,  affaire  COMP/M.4608      –  Siemens/UGS, considérant 8.

62  Voir les réponses à la question 28 de la demande de renseignements de la Commission envoyée aux clients.  Voir  aussi  la  décision  de  la  Commission  dans  l’affaire  COMP/M.3062  –    IBM/Rational, considérant 76.

63  Décision de la Commission du 3 octobre 2007 d’engager la procédure, considérant 43.

64 Voir les réponses à la question 16 de la demande de renseignements de la Commission envoyée aux clients.

65 Voir les réponses aux questions 7, 11 et 28 de la demande de renseignements de la Commission envoyée aux clients.

66  Voir les réponses aux questions 16 et 30 de la demande de renseignements de la   Commission envoyée aux concurrents.

67 Voir […]*, 1er mai 2007, pas de pagination, diapositive 18 […]*. Document soumis en annexe 4 de  la réponse d’IBM du 5 novembre 2007 à la demande de renseignements de la Commission du 19 octobre 2007.

68  Voir les réponses aux questions 54, 58 et 62 de la demande de renseignements de la Commission envoyée aux clients.

69  Voir les réponses aux questions 60 et 62 de la demande de renseignements de la Commission   envoyée

aux concurrents.

70  Voir […]*.

71   Voir […]*.

72 Voir […]*.

73. […]*, 6 décembre 2005, page 10. Document soumis en annexe 10 de la réponse d’IBM du  5 novembre 2007 à la demande de renseignements de la Commission du 19 octobre 2007.

74 «Selecting The Right Requirements Management Tool – Or Maybe None Whatsoever», 28 septembre 2007, page 7. Document soumis en annexe 15 de la réponse d’IBM du 5 novembre 2007 à la   demande de renseignements de la Commission du 19 octobre 2007.

75  Voir les réponses aux questions 29 (Modélisation) et 63 (Gestion des exigences) de la demande de renseignements de la Commission envoyée aux clients.

76   Voir  la  réponse  de  Qinetiq  du  2  novembre  2007  aux  questions  28  et  29  de  la  demande  de renseignements de la Commission envoyée aux clients.

77  Voir les réponses à la question 10.b) de la demande de renseignements de la Commission   envoyée aux clients le 30 août 2007, et à la question 10.b) de la demande de renseignements de la Commission

envoyée aux concurrents le 30 août 2007.

78  La catégorie OOA&D de Gartner inclut presque uniquement les outils de modélisation qui sont basés sur l’UML ou conformes à l’UML. Voir «Dataquest Guide: Software Market Research Definitions»,

Gartner, 15 mars 2007, page 8. Document soumis par IBM le 26 octobre 2007.

79 Voir la réponse d’IBM du 5 novembre 2007 à la question 27 de la demande de renseignements de la Commission du 19 octobre 2007.

80 Voir   par   ex.   SDL   (Langage   de   description   et   de   spécification)   utilisé   dans l’industrie  des télécommunications, UPDM utilisé dans l’industrie aérospatiale et l’industrie de la défense, AADL

(Langage de conception, d’analyse et d’architecture) utilisé dans l’industrie automobile, BPMN (Notation de la modélisation des processus d’entreprise) et BRM (Gestion des règles d’entreprise) utilisés pour le développement de logiciels informatiques.

81  Voir la réponse d’IBM du 5 novembre 2007 à la question 33 de la demande de renseignements de la Commission du 19 octobre 2007.

82  Voir   par   ex.   SDL   (Langage   de   description   et   de   spécification)   utilisé   dans   l’industrie des

télécommunications, UPDM utilisé dans l’industrie aérospatiale et l’industrie de la défense, AADL (Langage de conception, d’analyse et d’architecture) utilisé dans l’industrie automobile, BPMN (Notation de la modélisation des processus d’entreprise) et BRM (Gestion des règles d’entreprise) utilisés pour le développement de logiciels informatiques.

83  Voir les réponses à la question 20 de la demande de renseignements de la Commission envoyée aux clients le 18 octobre 2007.

84  Voir les réponses à la question 22 de la demande de renseignements de la Commission envoyée aux clients.

85  Voir la réponse d’Unisys du 7 novembre 2007, la réponse d’Unicredito du 31 octobre 2007,  la réponse de Danske Bank du 2 novembre 2007 et la réponse de RBS du 2 novembre 2007 à la question 20 de la demande de renseignements de la Commission envoyée aux clients.

86 Voir les réponses à la question 24 de la demande de renseignements de la Commission envoyée aux concurrents.

87   Voir les réponses à la question 16 de la demande de renseignements de la Commission envoyée aux concurrents.

88  «The Embedded Software Market Intelligence Program – 2007 Service Year – Volume 5: Embedded

software and system Modelling tools», VDC, novembre 2007, page 6. Document soumis par IBM le 11 septembre 2007.

89 Par ex., le produit Etas' Ascet est homologué pour le développement de logiciels conformes à Autosar (Autosar est une infrastructure architecturale utilisée dans l’industrie automobile), Esterel's Scade est

homologué par des autorités de sécurité telles que EASA, FAA et TUV pour développer des logiciels embarqués cruciaux pour la sécurité.

90  SysML est développé au dessus d’UML 2.0 pour prendre en charge une approche de modélisation structurelle  qui  correspond  mieux  à  la  manière  dont  les  ingénieurs  de  systèmes  effectuent  la

modélisation. Il n’a été adopté en tant que norme qu’en juillet 2006. Voir la réponse d’IBM du 5 novembre 2007 à la question 28 de la demande de renseignements de la Commission du 19 octobre 2007.

91   Par ex. Kennedy Carter iUML.

92  UPDM est un profil UML pour les normes DoDAF/MoDAF. «DoDAF» désigne le   cadre architectural du Ministère de la défense américain. «MoDAF» désigne le cadre architectural du Ministère de la défense britannique. DoDAF et MoDAF sont des systèmes architecturaux utilisés par les Ministères de la défense américain et britannique respectivement pour leurs acquisitions.

93  Voir «View DSLs and UML as 'Fraternal Twins', Not Competitors», Gartner, 29 septembre 2006,  page

3. Document soumis par Microsoft le 12 novembre 2007.

94  Voir la réponse d’IBM du 5 novembre 2007 à la question 26 de la demande de renseignements de la Commission du 19 octobre 2007.

95 «Unified Modelling Language Is Still Going Strong», Gartner, 2 juin 2006, page 1. Document soumis

par Microsoft le 12 novembre 2007.

   96  Notification du 29 août 2007, page 34.

97 Par  exemple,  VDC  publie  un  rapport  portant  spécifiquement  sur  les  «Outils  de  modélisation des

systèmes et des logiciels embarqués». Gartner publie également des rapports sur les «Outils de développement des logiciels embarqués et les RTOS».

98  Notification, page 14.

99   «Functional Substitution Analysis - Methodology», pages 6 et 7. Document soumis par IBM le 20 novembre 2007. Dans ce document (page 6), IBM a expliqué en relation avec les outils de modélisation

que:

«•  Un  ensemble  principal  de  critères  est  tout  aussi  important  pour  le  développement       de  logiciels d’application des TI et le développement de logiciels de systèmes: ces critères représentent environ […]* du nombre total des critères.

• Un ensemble de critères s’applique uniquement au développement de logiciels d’application des TI: ces critères représentent environ […]* du nombre total des critères.

•    Un ensemble de critères s’applique uniquement au développement de logiciels de systèmes: ces critères représentent environ […]* du nombre total des critères.

•  Environ […]* des critères s’appliquent à la fois au développement de logiciels d’application des TI et  au développement de logiciels de systèmes, mais avec une importance variable. Le nombre des critères les plus courants pour le développement de logiciels de systèmes est légèrement supérieur au nombre de critères les plus courants pour le développement de logiciels d’application des TI.»

Dans le même document (page 7), IBM a expliqué en relation avec les outils de gestion des exigences que:

«•    Un  ensemble  principal  de  critères  est  tout  aussi  important  pour  le  développement       de  logiciels d’application des TI et le développement de logiciels de systèmes: ces critères représentent environ […]* du nombre total des critères.

•    Un ensemble de critères s’applique principalement au développement de logiciels d’application des TI : ces critères représentent environ […]* du nombre des critères.

•   Un ensemble de critères s’applique uniquement au développement de logiciels de systèmes: ces critères représentent environ […]* du nombre des critères.

•    Environ […]* des critères s’appliquent à la fois au développement de logiciels d’application des TI et  au développement de logiciels de systèmes, mais avec une importance variable. Le nombre des critères les plus courants pour le développement de logiciels de systèmes est légèrement supérieur au nombre de critères les plus courants pour le développement de logiciels d’application des TI.»

100 […]*, Annexe 2, pages 1 et 2. Document soumis par IBM le 20 novembre 2007.

101  […]*, Annexe 1, pages 2 et 4. Document soumis par IBM le 20 novembre 2007.

102  Doors FastTrack est présenté par Telelogic comme «la solution de gestion et de définition des exigences qui facilite un projet de développement logiciel».

Voir http://www.telelogic.com/Products/doors/doorsfastrak/index.cfm

103 RSD signifie Développeur de systèmes rationnels (Rational Systems Developer). Il est présenté par IBM comme un produit qui «simplifie la complexité de la livraison de systèmes».

Voir http://www.306.ibm.com/software/awdtools/developer/systemsdeveloper/index.html

104   Notification, pages 34-35.

105    Voir […]*, page 4. Document soumis par IBM le 20 novembre 2007.

106  […]*, Annexe 1, pages 8-12, et Annexe 2, pages 5-10. Document soumis par IBM le 20 novembre 2007.

107    […]*

108   […]*

109   Décision de la Commission du 20 février 2003, Affaire COMP/M.3062 –    IBM/Rational, considérants 17, 21, 24, et 27.

110 Voir les réponses aux questions 11 (outils de modélisation) et 56 (outils de gestion des besoins) de la demande de renseignements de la Commission transmise aux concurrents.

111  Voir les réponses aux questions 6 (outils de modélisation) et 53 (outils de modélisation) de  la demande de renseignements de la Commission transmise aux clients.

112  Voir la réponse aux questions 5 et 6 (outils de modélisation) et 51 et 52 (outils de gestion des   besoins) de la demande de renseignements de la Commission transmise aux clients, et les réponses 9 et 10 (outils de modélisation) et 54 et 55 (outils de gestion des besoins) de la demande de renseignements de la Commission transmise aux clients.

113  Voir  «Gartner  Dataquest,  logiciels  de  développement  d’application  et  de  gestion  de  projets et de portefeuille» (2006), comme indiqué par IBM dans la notification (pages 56 et 57).

114 Voir la communication d’IBM du 4 décembre 2007 ([…]*), corrigé et recalculé dans la communication d’IBM du 21 décembre 2007.

115  Voir la communication d’IBM du 4 décembre 2007 ([…]*), corrigé et recalculé dans la communication d’IBM du 21 décembre 2007.

116 Voir le tableau 2 du rapport LECG présenté par IBM le 21 novembre 2007, en réponse à la question 4 de la demande de renseignements de la Commission du 9 novembre 2007.

117  Chiffres extraits du tableau 2 du rapport LECG présenté par IBM le 21 novembre 2007

118 Certains  clients  (Infineon  par  exemple) utilisent  un  nouvel  outil  de modélisation développé par un nouvel entrant ou par un petit fournisseur. D’autres clients ont répondu qu’ils l’utiliseraient (The  Boeing Company, AT&T, CSC ou RBS par ex.). Voir les réponses d’Infineon, AT&T et RBS du   2 novembre 2007, la réponse de CSC du 5 novembre 2007 et la réponse de The Boeing Company du  7 novembre 2007. semblent toujours mieux refléter la puissance sur le marché que les parts de marché en termes de volume. En cas de produits différenciés, il est généralement accepté que les parts de marché en valeur reflètent mieux la position et la puissance relative de chaque concurrent119.

119 Voir la communication de la Commission sur la définition du marché en cause aux fins du droit communautaire de la concurrence, point 55 (Journal officiel C 372 du 9.12.1997, p. 0005 – 0013). Voir également la décision de la Commission du 21 juin 1994 dans l’affaire IV/M.430 - Procter & Gamble/VP Schickedanz (II), considérants 112 à 117 (Journal officiel L 354 du 31.12.1994, p. 0032 – 0065).

120  36 % des sociétés ayant répondu à une analyse de concurrence réalisée par VDC en 2005 concernant l’utilisation  des  outils  de  modélisation  de  logiciels  utilisaient  Visio  (Microsoft),  bien  que    VDC n’accorde à Visio que 2 % de parts du marché des outils de modélisation intégrés (« Le programme de renseignement   logiciel   du   marché   intégré »   –   Volume   IV,   2006,   présenté   par   IBM   le    11 septembre 2007).

121 IBM estime par exemple que les recettes provenant des licences représentent 100 % des recettes  totales

de cinq de ses concurrents (Omondo, Gentelware Poseidon, NoMagic MagicDraw, Visual Paradigm et Sparx Systems). Voir la communication d’IBM du 4 décembre 2007, corrigé et recalculé dans la communication d’IBM du 21 décembre 2007.

122  Computer  Associates,  Embarcadero  Technologies,  IAR  visualSTATE  et  Foresight,    par  exemple. Néanmoins, certains autres concurrents qui ont été mentionnés par les clients ayant répondu à l’enquête

approfondie de la Commission ne figurent pas dans les parts de marché recalculées d’IBM (Core (Vitech/Sodius), IDS Scheer (ARIS), Casewise Corporate Modeller ou Allfusion Data Modeller, entre autres).

123  Le calcul de part de marché de […]* tient uniquement compte des recettes issues de RSA et de RSD qu’IBM estime comme pouvant être correctement imputées aux fonctionnalités de modélisation   […]*.

124 Le tableau 4 est basé sur les données de vente fournies par IBM et corrigées en fonction des données de vente obtenues des concurrents dans le cadre de l’enquête approfondie. Tandis que les parties considéraient que toutes les ventes de […]*, ainsi que de […]* pouvaient être considérées comme des recettes de licences, dans ce tableau, on estime que 50 % des ventes totales représentent une approche plus réaliste. De plus, le tableau comprend toutes les recettes de licence d’IBM RSA et RSD […]*  (IBM elle-même n’intègre que 27 %). Ce tableau ne comprend pas les outils de Microsoft (en l’absence de chiffre d’affaires fiable) ni les outils dits libres.

125  Telelogic SDL Suite et Statemate, Mathworks Simulink, ETAS Ascet, dSpace SystemDesk  et Applied Dynamics International Beacon.

126  Voir  «Gartner  Dataquest,  logiciels  de  développement  d’application  et  de  gestion  de  projets et de portefeuille» (2006), […]*.

127  Voir la communication d’IBM du 4 décembre 2007 ([…]*), corrigé et recalculé dans la communication d’IBM du 28 janvier 2008.

128   Voir la communication d’IBM du 4 décembre 2007 ([…]*), corrigé et recalculé dans la communication

d’IBM du 28 janvier 2008.

129   IBM a pris en compte des revendeurs qui ne sont pas perçus comme des concurrents par les sociétés ayant répondu à l’enquête approfondie de la Commission (comme Microsoft Visual Studio Team System, Oracle/Agile, RallyDev, CollabNET et Atlassian JIRA). Néanmoins, certains autres outils de concurrents, qui ont été mentionnés par les clients ayant répondu à l’enquête approfondie de la Commission, ne figurent pas dans les parts de marché recalculées d’IBM (notamment, Axosoft On Time, Mantis, EPDM Enovia MatrixOne, OmniTracker OmniNet ou FORCE Ontopia). De plus, la part de marché de la catégorie « Autres revendeurs de logiciels de gestion du cycle de vie du produit » ([20- 30]*%) semble trop élevée.

130  Ce tableau est basé sur les données de vente fournies par IBM et corrigées en fonction des données de

vente obtenues des concurrents dans le cadre de l’enquête approfondie. Il est néanmoins important de ne pas oublier que la part de marché élevée d’autres revendeurs de logiciels de gestion du cycle de vie du produit n’a pas été corrigée, en l’absence de résultats pertinents émanant de l’enquête approfondie.

131 De nombreux clients font appel aux services d’analystes d’entreprise et de consultants   comme Gartner ou Ovum afin qu’ils les aident à identifier les outils potentiellement adaptés. Voir par exemple la réponse de l’administration fiscale néerlandaise du 1er novembre 2007 à la question 2 de la demande de renseignements de la Commission. En outre, dans le cas des outils de modélisation, les connaissances des clients concernant les produits de la nouvelle génération peuvent être réduites étant donné que jusqu’à récemment, l’outil de modélisation Rational Rose d’IBM constituait de facto la norme du secteur pour les clients systèmes.

132. Voir par exemple le procès-verbal de l’entretien réalisé avec Lockheed Martin le 30 novembre 2007.

133  Le groupe de sociétés interrogées comprenait Microsoft, Lockheed Martin, EADS, Siemens (UGS) et Infovista.

134 Voir  la  communication  de  Microsoft  du  14 janvier  concernant  un  rapport  de Frontier Economics. L’étude  de  marché  sur  laquelle  se  fonde  ce  rapport  a  été  menée       par  une  société  de  services

professionnels qui a préféré demeurer anonyme.

135  Cette étude complète les communications auparavant déposées par Microsoft (en particulier celui du 23 novembre 2007). La méthodologie employée dans le cadre de l’étude présente les défauts suivants

136  Voir  la  communication  d’IBM  du  21 novembre 2007  qui contient une description de ses    outils de modélisation.

137  Par exemple, bien qu’IBM RDS génère du C++, il ne génère pas de C.

138 Telelogic  commercialise  également  trois  autres  outils  de  modélisation.  System  Architect,  qui  est

davantage un outil d’architecture d’entreprise (voir la communication d’IBM du 25 septembre 2007) qu’un outil de modélisation. Il figure dans la classification de Gartner dans trois catégories différentes, à savoir, outils d’analyse et de conception orientée objet, logiciel de développement d’autres applications et outils de conception de bases de données. Il existe également deux outils de modélisation patrimoniaux de Telelogic, SDL Suite (non basée sur UML) et Statemate. La part de ces deux produits dans le chiffre d’affaires de Telelogic pour les outils de modélisation est cependant en baisse, voir la communication d’IBM du 8 novembre 2007. Tandis que Statemate cible le marché automobile (voir le document interne d’IBM «[…]*» du 15 mars 2007, Annexe 5.4, pièce 4 (c) 5 de la notification […]*), SDL Suite est plus adapté pour un usage dans le secteur des communications dans lequel le langage de programmation SDL dispose d’une meilleure compatibilité.

139     Voir la publication du Groupe Butler de juin 2007, Développement orienté par modèle.

140 C.-à-d. le cadre d’architecture du ministère de la défense développé par les autorités des   États-Unis. Il définit une norme d’organisation d’une architecture d’entreprise ou d’une architecture système en points de vue complémentaires et compatibles. Tous les principaux achats de systèmes informatiques et d’armes du ministère de la défense des États-Unis doivent développement et documenter une architecture d’entreprise en utilisant les points de vue décrits dans le DoDAF (cadre d’architecture de  du ministère de la défense). Bien qu’il soit clairement ciblé sur les systèmes militaires, le DoDAF est applicable à plus grande échelle dans les secteurs privé, public et bénévole du monde entier, et représente seulement un grand nombre de cadres d’architectures systèmes. Il est particulièrement adapté aux grands systèmes présentant des difficultés complexes en termes d’intégration et d’interopérabilité,  et est apparemment unique en termes d’utilisation des « points de vue opérationnels » détaillant le domaine d’exploitation du client externe dans lequel le système de développement fonctionnera. Le cadre d’architecture du ministère de la défense du Royaume-Uni (MODAF) définit un mode normalisé de gestion de l’architecture d’entreprise et constitue un moyen de modéliser, d’analyser et d’établir les capacités, les systèmes, les systèmes de systèmes et les processus d’entreprise.

141 Une comparaison entre les outils de modélisation de Telelogic et l’outil de modélisation  patrimonial le plus avancé d’IBM, c.-à-d. Rational Rose Technical Developer, démontre que ce dernier ne comprend pas certaines fonctions importantes comme DoDAF, MoDAF, SysML et UML 2.0.

142  Le barème de prix pour une licence classique relative aux outils de modélisation de Telelogic   en 2006

était le suivant : Rhapsody […]*, Tau […]*, Statemate […]*, SDL Suite […]*. Le barème de prix pour une licence classique relative aux outils de modélisation non patrimoniaux d’IBM en 2006 était le suivant : RSA […]*, RSD […]*, Rational Systems Modeler […]*. Voir la communication d’IBM du     5 novembre 2007.

143  Voir la communication d’IBM du 21 novembre 2007.

144  Voir l’étude LECG concernant «[…]*» présentée par IBM le 4 décembre 2007.

145  Voir l’étude LECG concernant «[…]*» présentée par IBM le 4 décembre 2007.

146  Voir l’étude LECG concernant «[…]*» présentée par IBM le 4 décembre 2007.

147 […]*.

148   […]*.

149  Voir les tableaux du calendrier de lancement de produit IBM Rational 2007 du 23 août 2007.

150   Dans le cadre de l’enquête approfondie de la Commission, il a été demandé aux clients de fournir des évaluations internes des différents outils de modélisation qu’ils avaient étudiés. Ces évaluations internes

 151 Voir la communication d’IBM du 12 décembre 2007, sur les calendriers de lancement de  produits pour les outils de gestion des besoins et de modélisation de Telelogic. Voir également la réponse d’IBM du   5 novembre 2007 à la demande de renseignements de la Commission. […]*.

152  Voir le procès-verbal d’un entretien avec Lockheed Martin le 27 novembre 2007: « Bien qu’il soit classé premier, [CONFIDENTIEL] est loin d’être l’outil « parfait » pour Lockheed Martin, étant donné qu’il a obtenu 92,6 points sur un maximum de 200. Ce résultat montre que les besoins de Lockheed Martin dépassent de loin les performances des outils de modélisation actuellement disponibles sur le marché, ce qui laisse suffisamment de champ pour de futures mises à niveau des produits. »

153 […]*, 7 août 2006, p.12. Document joint en annexe 8 à la réponse d’IBM du 5 novembre 2007 à la demande de renseignements de la Commission.

154  Les systèmes complexes permettent l’interaction du matériel et des logiciels, souvent avec plusieurs périphériques et sous-systèmes. A une petite échelle physique, le téléphone portable représente un bon exemple, car il s’agit d’un système en lui-même qui intègre souvent un appareil photo, un moteur de  jeu, un lecteur mp3, des capteurs de mouvement et de lumière pour s’adapter à l’environnement, ainsi qu’une connectivité fonctionnelle avec divers périphériques et une interaction avec une base de données de télécommunication bien plus importante. A une échelle physique plus étendue, un  système  de combat équipé de plates-formes de lancement de missiles, de centres de contrôle et de commande de satellites d’observation répartis dans le monde entier sur des navires de guerre, représente un système complexe formé de nombreux sous-systèmes. Voir la communication d’IBM du 25 septembre 2007.

155 Voir la communication d’IBM du 21 novembre 2007.

156  Voir, par exemple, les réponses de BAE du 23 novembre 2007, de Boeing du 7 novembre 2007, de Rolls-Royce  du  26 novembre 2007,  de  Northrop  Grumman   du  15 janvier 2007,  de  Qinetiq       du2 novembre 2007, de Safran du 31 octobre 2007, de Honeywell du 26 novembre 2007 et d’Elbit du       2 novembre 2007 à la question 7 de la demande de renseignements de la Commission.

157  Voir, par exemple, la réponse de Boeing du 7 novembre 2007 aux questions 7 et 9 de la demande de renseignements de la Commission. Bien que la société n’utilise pas Artisan, elle le décrit comme un « concurrent très proche pour les outils de modélisation UML aux fonctions intégrales ». Voir également la réponse de Qinetiq du 2 novembre 2007 à la question 7 de la demande de renseignements de la Commission. Qinetiq utilise, entre autres, les outils de modélisation d’Artisan.

158   Voir le procès-verbal de l’entretien avec Lockheed Martin réalisé le 30 novembre 2007.