Version classiqueVersion mobile

Langue, économie, entreprise. Gérer les échanges

 | 
Irmtraud Behr
, 
Dieter Hentschel
, 
Patrick Farges
, 
et al.

Partie 1 : Communiquer dans l’entreprise

Problèmes de coordination dans les projets internationaux de développement de logiciels

Carsten Lang

Résumé

Depuis quelques années, la délocalisation de certaines parties du processus de développement de logiciels et le développement par des équipes internationales se multiplient. Les coûts salariaux très bas et le niveau élevé de qualification des développeurs dans les régions comme l’Inde, la Russie, -l’Europe du Sud-Est ou la Chine encouragent cette tendance. Pourtant, les réductions de coûts et d’autres effets ne sont nullement aussi positifs que pourraient le laisser supposer les différences de salaires. De fait, la réduction des coûts salariaux est partiellement absorbée par une forte augmentation des coûts de coordination. Sur la base d’un modèle simplifié du processus de développement de logiciels, l’article montre en quoi la délocalisation spatiale des tâches de développement, notamment dans un contexte international, peut entraîner des coûts de coordination significatifs. Dans ce contexte, les aspects suivants sont particulièrement éclairants: les ambiguïtés dans les spécifications du produit, le rôle des clients et les interdépendances techniques entre les différents sous-processus.

Texte intégral

Introduction

  • 1 Même si le coût salarial représente souvent le motif principal de la délocalisation, il y en a d’au (...)

1Dans les dernières années, de nombreuses entreprises de logiciels ont transféré une partie de leurs processus de développement à l’étranger, souvent dans des pays à bas salaires, comme l’Inde, la Russie, la Chine ou les pays de l’Est, afin de réduire les coûts de développement1. En effet, la différence salariale entre ces pays et les pays occidentaux varie parfois de un à neuf (voir figure 1), particulièrement si l’on prend on compte les charges annexes.

  • 2 Selon une étude effectuée par l’Institut universitaire de technologie de Pforzheim (BITKOM 2005 : 1 (...)

Figure 1 : Taux journalier normalisé pour programmeurs2

Figure 1 : Taux journalier normalisé pour programmeurs2

2Malgré cette énorme différence de salaires et malgré un marché marqué par un taux de croissance remarquable, les délocalisations n’ont pas toujours produit les réductions escomptées des coûts de développement. Au lieu d’un fort optimisme, on trouve aujourd’hui, notamment chez beaucoup de PME, un sentiment de déception, même si de nombreuses entreprises réussissent et si quelques grandes entreprises de logiciels ou de technologie de l’information sont satisfaites de leurs filiales, notamment en Inde (par exemple Cisco ou Microsoft). Quelles sont les raisons de ce changement d’attitude chez un grand nombre de PME ? Pourquoi la réduction visée des coûts de développement n’a-t-elle souvent pas été effectuée ? Dans quelles conditions une délocalisation devient-elle plutôt hasardeuse ?

  • 3 Bien qu’il y ait d’autres problèmes (par exemple la sélection du partenaire approprié, les barrière (...)

3Pour élucider ces questions, l’article va premièrement présenter un modèle simplifié du processus de développement, qui décrit notamment des gros et moyens projets de logiciels, ainsi que les projets de logiciels innovants. Ce modèle montre avant tout les différents sous-processus et les rapports entre sous-processus. Par ailleurs, il explique le caractère itératif du développement. Deuxièmement, l’article analysera la délocalisation en elle-même. Quels sous-processus sont délocalisés ? Et que se passe-t-il aux interfaces entre les sous-processus délocalisés et ceux qui restent ? En combinant ces deux aspects, l’article va, troisièmement, identifier trois problèmes essentiels de coordination : un problème de structuration, un problème d’articulation et un problème technico-économique3.

1. Processus de développement

4Pour comprendre le processus de développement, il faut d’abord distinguer les sous-processus et les phases de développement (voir figure 2 – adaptée à partir de Jacobson, Booch, Rumbaugh, 1999), une différence fondamentale qui n’est guère prise en compte. Dans la littérature, on trouve souvent une structuration sur la base de phases, mais en utilisant les noms de sous-processus, ce qui fait preuve d’une confusion – par ailleurs – répandue à propos de ces deux aspects tout à fait différents. Alors que les phases décrivent l’ordre chronologique du développement, les sous-processus représentent plutôt les différents résultats partiels à développer.

5Toute stratégie de résolution des problèmes nécessite une méthode de structuration. Pour les différentes démarches d’une telle méthode, on utilise souvent des termes comme « définition de problème », « identification d’alternatives », « évaluations d’alternatives » et « réalisation de l’alternative choisie », ainsi que « préparation », « élaboration », « conception » et « construction ». Peu importe quels termes l’on choisit : ils représentent l’ordre chronologique de la résolution d’un problème. Or on peut considérer le processus de développement comme un processus de résolution de problème. Au début du développement, il y a un problème. Il existe bien une intention de développer un produit de logiciel, mais les stratégies, les méthodes, etc. ne sont pas encore connues. Par conséquent, on essaie d’abord de décrire le problème précisément. Ensuite, il faut élaborer différentes alternatives – en fractionnant le problème en sous-problèmes – pour aboutir à une solution, i.e. à un produit conforme aux demandes des clients. Finalement, l’alternative choisie reste à réaliser ou à construire. La confusion mentionnée plus haut est due au fait que la structuration du produit à développer représente également un processus de résolution de problème. Elle présente donc des ressemblances importantes avec le processus de développement. Mais si le premier concerne le produit, le second concerne le processus de développement.

Figure 2 : Processus de développement

Figure 2 : Processus de développement

6S’il y a notamment des produits innovants ou complexes à développer, la définition du produit change souvent au cours du développement. Avec une compréhension progressive des souhaits du/des client(s) et des interdépendances entre les exigences fonctionnelles et non fonctionnelles, la définition du produit s’adapte progressivement aux voeux du/des client(s) et aux restrictions techniques et économiques. Pourtant, les répercussions sur les processus de développement sont moins importantes. Un grand nombre de changements dans la définition du produit peut être effectué sans qu’il soit nécessaire d’adapter la structuration principale du processus de développement (par exemple l’alternative choisie ou la division du développement en équipes).

7La figure 2 montre le déroulement principal du développement. Alors que les phases se fondent sur une notion strictement temporelle, les sous-processus représentent plutôt différents produits partiels à développer. Un produit de logiciel, notamment un logiciel sur mesure, ne se compose pas seulement d’un code source voire d’un code exécutable et de manuels, mais aussi de toute une information sur sa structure. Chaque sous-processus a pour but d’aboutir à un de ces produits partiels (par exemple conception → définition d’un produit intelligible pour tous ; design → architecture du logiciel).

8Le tableau ci-dessous (figure 3) montre la plupart des sous-processus avec leurs produits partiels correspondants.

Figure 3 : Processus de développement

Sous-processus

Résultats

Conception

Définition provisoire du produit

– éléments de fonctionnalité

– exigences non fonctionnelles

Langue : compréhensible pour le client (p. ex. anglais)

Analyse

Transformation de la définition provisoire du produit orientée vers le client en définition de problème partiellement formalisée orientée vers le développeur

Langue : p. ex. SA (ERM, DFD), OOA

Design

– Description précise de l’architecture du logiciel

– Description au moins partiellement formalisée des structures de données et des algorithmes

Langue : p. ex. SD, OOD

Implémentation

Code source, code exécutable

Langue : divers langages de programmation

2. Délocalisation

9Même s’il n’y a pas encore beaucoup d’études sur la délocalisation des différentes tâches de développement, on peut quand même constater que la délocalisation concerne avant tout le sous-processus « implémentation ». Une étude conduite par Carmel montre que l’implémentation a été transférée à l’étranger dans 84 % des projets analysés, alors que l’analyse reste majoritairement localisée au siège principal de l’entreprise, responsable du développement (Carmel, 1999 : 135). Le design se trouvait délocalisé dans 50 % des cas. Même si cette étude ne fait pas de distinction entre le design global (notamment l’architecture) et le design détaillé (notamment les structures de données et les algorithmes), on peut tout de même supposer que le design détaillé devrait être plus souvent délocalisé que le design global. Bien que les chiffres montrent que seule une minorité des tâches du test (ou plus généralement des tâches de la gestion de qualité) était délocalisée, Carmel anticipe cependant que ce pourcentage pourrait augmenter à l’avenir, étant donné que les interdépendances entre le test et les autres sous-processus sont plutôt faciles à maîtriser.

10Les résultats de Carmel sont dans l’ensemble confirmés par une étude un peu plus récente de Moczaldo (2003 : 4). L’hypothèse concernant les deux phases du design est également confirmée. L’analyse et le design général restaient dans la plupart des cas au siège principal, tandis que le design détaillé et la programmation étaient délocalisés. La part des tâches de gestion de qualité délocalisées à l’étranger reste nettement inférieure à celle du design détaillé et de la programmation.

11En résumé, on peut constater que les tâches qui concernent le « quoi » restent plutôt au siège principal, alors que les tâches qui décident du « comment » se retrouvent plutôt à l’étranger.

3. Problèmes de coordination

12La désillusion à l’égard de la délocalisation est tout particulièrement causée par des problèmes de coordination. Les points suivants vont montrer qu’il y a notamment trois éléments menant à une hausse des coûts de coordination :

  •  un problème de structuration/de traduction multiple ;

  • un problème d’articulation ;

  •  un problème technico-économique.

3.1. Problème de structuration/de traduction multiple

3.1.1. Traduction reproductive et traduction précisante

13Pour aboutir à un code source exécutable d’un produit de logiciels, il faut « traduire » la définition du produit à développer à plusieurs reprises dans différentes langues. La définition du produit représente ce que le client souhaite. Elle est notamment composée d’exigences fonctionnelles et non fonctionnelles. Tandis que les éléments fonctionnels décrivent les différentes fonctions que le logiciel doit réaliser (par exemple un logiciel de traitement de texte offre, entre autres, les fonctions « formatage de texte », « impression de texte »), les exigences non fonctionnelles posent des restrictions à respecter (par exemple la fiabilité, le temps de réponse, la facilité d’entretien, la facilité d’utilisation, la convivialité).

  • 4 Le mot « général » indique ici une description indépendante de la plate-forme technique.

14Pour simplifier le problème de développement, on supposera qu’une définition complète et définitive du produit à développer est disponible au début du développement, hypothèse qui n’est guère satisfaite en pratique (voir point 3.1.2.). Selon le modèle de développement présenté au point 2, il faut d’abord développer les produits intermédiaires des sous--processus « analyse », « design général » et « design détaillé » pour arriver enfin au code source. Pour chacun de ces sous-processus, plusieurs langues – plutôt techniques, parfois formelles – sont utilisées afin de développer et de documenter ces produits intermédiaires. Tout produit intermédiaire est fondé sur les résultats des sous-processus d’ordre supérieur. Ainsi les résultats du sous-processus « design détaillé » sont-ils fondés sur les résultats des sous-processus « conception », « analyse » et « design détaillé ». Chaque fois que l’on développe les résultats d’un sous-processus, cela se fait par un processus de traduction. Les résultats du sous-processus supérieur sont pris et « traduits » dans les langues du sous-processus subordonné. Bien que l’on utilise ici le terme de « traduction », il convient de rappeler qu’il ne s’agit pas seulement d’un processus de traduction reproductive, où l’on remplace les mots d’une langue par ceux d’une autre langue tout en trouvant la construction qui conserve au mieux la signification du texte original. Comme deuxième élément de ce processus, il faut toujours ajouter de la précision, donc de l’information. Par exemple, l’architecture de logiciel, qui est un résultat essentiel du design général, décrit entre autres la décomposition du logiciel en modules. Elle est élaborée en utilisant des langues comme « Unified Modeling Language (UML) » ou « Fundamental Modeling Concepts (FMC) ». Dans le sous-processus subordonné – le design détaillé –, il faut notamment développer pour chaque élément fonctionnel une représentation générale4 qui décrit comment cet élément est à programmer et comment il traite les données à manipuler. Certains éléments de ces algorithmes peuvent – approximativement – être rendus par traduction reproductive. Cependant, la majorité des tâches à accomplir dans le design détaillé nécessite une traduction précisante. Appliqué à l’exemple précédent, on pourrait dire que la communication entre les différents modules peut être traduite de façon reproductive. Cependant, la description de la manipulation des données par les algorithmes nécessite une traduction précisante. L’aspect précisant est prédominant dans les sous-processus « conception », « analyse » et « design ». En revanche, l’implémentation se fonde plutôt sur l’aspect reproductif, à condition qu’il y ait un design détaillé précis et complet, ce qui n’est pas toujours le cas.

3.1.2. Découverte et prévention des fautes

15La traduction précisante n’est pas facile. Elle représente toujours un processus créatif ou intellectuel. Chaque développeur peut faire des fautes et oublier des précisions importantes. Étant donné que les résultats des sous-processus « conception », « analyse », « design général » et « design détaillé » ne sont pas exécutables sur un ordinateur, il est relativement difficile de repérer ces fautes ou omissions pendant la vérification des résultats d’un sous-processus. Ce n’est pas seulement le développement, mais aussi la vérification qui sont altérés et entravés par les restrictions cognitives humaines. Ce problème se manifeste même plus nettement encore si l’on prend en considération quelques attributs du contexte (par exemple le degré d’innovation, la complexité des liaisons entre les décisions à prendre, la dynamique d’environnement technique, les demandes changeantes des clients ; voir point 3.3.).

  • 5 Pour les exigences des compilateurs, voir Wegener, 2005 : 128, 197 ; pour les grammaires des langue (...)

16Or à la fin du développement, on est contraint d’aboutir à une précision maximale. Les compilateurs qui, finalement, traduisent d’une façon automatique le code source, résultat principal du sous-processus « implémentation », en code exécutable ont besoin d’un code source qui soit conforme aux règles des grammaires d’une sous-catégorie des langues de type 2 (i.e. les langues déterministes hors-contexte ; voir figure 4), donc des langues avec une grammaire très restreinte5. Une utilisation des langues avec des grammaires plus puissantes n’est pas possible parce qu’elle rendrait le code source intraduisible ou la durée de traduction inacceptable.

Figure 4 : Langues formelles et utilité pratique

Langues de type 0

Langues générales/récursivement énumérables

Non décidable

Langues de type 1

Langues contextuelles

NP-complète

Langues de type 2

Langues hors contexte/algébriques

L. déterministes h.-c.

Temps d’exécution: O(n3)

O(n)

Langues de type 3

Langues rationnelles

insuffisamment puissantes

17En résumé, on peut constater qu’un projet de logiciel est toujours caractérisé par une situation où il faut transformer un état initial avec beaucoup d’ambiguïté en un état final sans aucune ambiguïté c’est-à-dire avec précision maximale. Dans la pratique, cette transformation n’est presque jamais possible sans itérations : d’abord, on commence le processus de structuration ou de traduction multiple, après quelque temps on comprend que certaines hypothèses ne fonctionnaient pas ou bien on prend conscience de quelques fautes ou omissions. Ensuite, on essaie de les corriger et on continue sur la base de nouveaux résultats intermédiaires.

18Plus les fautes ou omissions sont repérées tardivement, plus élevés sont les coûts pour les corriger. Au cours d’une évaluation de gros et de petits projets de logiciels, Boehm a découvert que les coûts de correction augmentent progressivement pour chaque sous-processus qui se trouve entre l’origine d’une faute ou omission et sa découverte (Boehm, 1981 : 39). Selon cette étude, il est, pour les gros projets de logiciels, en moyenne cent fois plus coûteux de corriger une faute qui a été commise pendant la conception ou l’analyse et qui a été découverte pendant l’utilisation, par rapport à une situation où cette faute aurait été repérée au cours de la même itération de la conception.

3.1.3. Nécessité d’une communication intensive

19Se pose maintenant la question des rapports entre ces connaissances scientifiques et les projets internationaux. Pour répondre à cette question, il est important de constater que le nombre des fautes ou omissions commises ou trouvées tardivement pendant un projet de logiciels est parfois influencé par l’organisation et les méthodes de développement. D’une part, quelques fautes ou omissions peuvent être évitées par une communication intensive entre les développeurs travaillant à l’élaboration des résultats partiels des différents sous-processus. D’autre part, quelques fautes peuvent être retrouvées plus rapidement si l’on optimise le choix des méthodes de vérification. Certaines études ont notamment prouvé que les inspections sont un instrument efficace pour trouver (certaines) fautes ou omissions tôt au cours du développement (Grady, 1997 : 233). Cette méthode atteint souvent une efficacité optimale si elle est pratiquée par une équipe composée de développeurs responsables de différents sous-processus.

20En résumé, cette stratégie de découverte plus rapide des fautes et des omissions, de même que la stratégie de prévention des fautes ou omissions ont davantage de chances de réussir si elles sont accompagnées d’une communication intensifiée entre les développeurs des différents sous-processus.

  • 6 Il est évident que l’importance de ces facteurs dépend des propriétés du projet. Les projets innova (...)

21C’est exactement à cette étape que l’on retrouve le problème des projets internationaux. Comme l’évoquait le point 2, les projets internationaux sont caractérisés par le fait que quelques tâches, notamment celles qui font partie de la conception, de l’analyse et du design général, sont effectuées au siège principal, alors que celles qui sont nécessaires à achever le design détaillé et l’implémentation sont délocalisées à l’étranger. Par conséquent, les développeurs, dont la communication intensifiée pourrait aboutir à un développement plus efficace, se retrouvent loin les uns des autres. Certaines études sur la communication dans des projets de recherche et de développement montrent que l’intensité de la communication baisse progressivement avec l’augmentation de la distance géographique entre les chercheurs ou les développeurs (Allen, 1993 ; Brockhoff, 1994; Cusumano, Selby, 1995). Allen, par exemple, montre qu’à partir d’une distance de 25 mètres déjà, une nette diminution de la communication est détectable (Allen, 1993 : 236). Car la confiance, la compréhension mutuelle et la créativité sont positivement influencées par une proximité qui s’exprime par une communication informelle et en face-à-face6.

3.1.4. Qualité de la communication

22L’intensité de la communication n’est qu’une facette du problème. Également importantes, et déjà évoquées au point précédent, sont la qualité de la communication et la confiance que les interlocuteurs peuvent avoir dans les informations obtenues. La qualité de la communication peut être décrite par l’intégrité des informations transmises. Les formes de communication les plus simples se limitent à transmettre des textes non adressés. Plus riches sont celles qui y ajoutent des gestes ou la mimique. Les documents non adressés, donc ceux dont le contenu n’est pas adapté aux besoins ou exigences d’une personne concrète, mais seulement à un rôle abstrait, représentent une communication peu riche. Le destinataire obtient les documents recherchés en les retrouvant, par exemple dans une banque de données. Pourtant, l’utilité de telles informations est restreinte. Même si ces documents s’adressent à un certain rôle (par exemple un document par un développeur du design général et adressé à un développeur du design spécialisé), ils divergent tout de même des expériences, des exigences et des intérêts du destinataire concret. Dans les projets internationaux, beaucoup d’informations sont échangées sur la base de cette communication très restreinte. On codifie par exemple le design général et on le transmet après au développeur du design détaillé. Même si cette transmission est parfois accompagnée de réunions, de coups de téléphone ou de petits entretiens pour donner une explication générale des résultats ou pour échanger quelques informations explicatives, il est évident que ces instruments de communication, de coordination ou de compréhension mutuelle reculent avec la distance géographique, a fortiori si le design général et le design détaillé sont développés dans des pays ou des continents différents.

  • 7 La délocalisation entraîne d’importants coûts de coordination. Les propriétés du projet vont déterm (...)
  • 8 Souvent, lorsqu’il y a échange d’information entre différentes entreprises, les supérieurs sont ass (...)

23À l’autre bout de l’éventail des formes de communication, on trouve les vidéoconférences voire, plus riche encore, la communication en face-à-face. Les occasions pour communiquer en face-à-face doivent être plutôt restreintes, si l’on veut garder le bénéfice des réductions de coûts réalisées grâce à la délocalisation7. Aussi les vidéoconférences présentent-elles quelques inconvénients. La transmission de la communication non verbale n’est pas aussi complète que dans le cas de la communication en face-à-face. Par ailleurs, une vidéoconférence ne se fait pas toujours de manière spontanée. Souvent, il faut réserver des salles conformément équipées et planifier les réunions, des choses pas toujours simples si l’on tient compte du fait que les participants appartiennent souvent à des entreprises différentes et qu’il y a des règles à respecter8, sans mentionner les problèmes liés au décalage horaire. En plus, il y a une légère perte d’informations, étant donné que la transmission des gestes et des mimiques, importants éléments de la communication non verbale pour l’établissement de la confiance, n’est pas aussi parfaite pendant les vidéoconférences que lors d’une communication en face-à-face.

  • 9 Souvent, cette ambiguïté disparaît seulement après quelques itérations durant le développement.

24Or selon la théorie de la « media richness », plus une tâche est ambiguë et incertaine, plus les moyens de communication doivent être riches (Daft, Lengel, 1984 ; Daft, Lengel, Trevino, 1987). Et évidemment, de nombreux projets de logiciels sont caractérisés par cette ambiguïté et incertitude. Au début du développement, on a souvent une idée vague du produit à développer, de la faisabilité de certaines stratégies de réalisation, des restrictions techniques et budgétaires, ainsi que du savoir-faire disponible. En plus, le client peut changer certaines de ses exigences en cours de développement. Tout cela conduit régulièrement à des résultats provisoires pour des sous-processus assez ambigus, et exige une communication répétitive et riche afin d’identifier l’ambiguïté et de la transformer en précision au cours du développement9.

25En résumé, on peut constater que là où les moyens de communication les plus riches seraient justement souhaitables, il faut régulièrement se contenter d’une communication plutôt restreinte.

3.1.5. Le rôle de la confiance

26La forme que prend la communication est fondamentale pour l’établissement de la confiance. Pendant un projet de développement, il y a de nombreuses décisions à prendre qui ont des conséquences importantes sur le déroulement futur du projet. Beaucoup de ces décisions nécessitent une collaboration entre des experts ayant des domaines d’expertise différents. Si l’on prend en compte le fait que chacun peut être rendu responsable des décisions qu’il a prises, il est évident qu’il faut qu’un supérieur ait un minimum de confiance en ses collaborateurs pour pouvoir s’appuyer sur leurs propositions ou recommandations. Selon Carmel, cette confiance est avant tout établie au cours de processus interactifs et personnels, donc par collaboration immédiate (Carmel, 1999 : 142).

3.1.6. Facteurs de risque

27Les risques qui peuvent se manifester au cours d’un projet de développement sont variés. Trois de ces risques sont par exemple l’abandon du design détaillé, la distance culturelle et l’anglais comme langue étrangère. Alors que le premier facteur décrit un problème général, les deux autres sont typiques des projets internationaux.

28Parfois, la direction du projet renonce au design détaillé pour accélérer le développement ou réduire les coûts. Cette décision a souvent des conséquences dommageables pour l’entretenabilité, notamment dans le cas de systèmes complexes de logiciels. Elle peut également empêcher le développement. Les résultats (provisoires) de l’analyse et du design général sont souvent ambigus. Par ailleurs, il existe des incertitudes concernant la faisabilité technique ou la stratégie de réalisation. Le design détaillé a comme fonction importante d’ajouter de la précision et de trouver des stratégies de réalisation. En plus, il contribue à établir une certaine indépendance entre les différents modules du système de logiciels. Sans design détaillé, il y a une forte probabilité que des interdépendances essentielles ne soient identifiées qu’au moment de la programmation. Par conséquent, le risque d’être contraint de réaliser des travaux importants de retouche augmente, ce qui entraîne des répercussions sur le temps et les coûts de développement.

  • 10 Cette dernière dimension a été ajoutée plus tard.

29La distance culturelle a été jugée le facteur de risque le plus important dans les projets internationaux effectués par IBM. Dans l’étude influente de Hofstede, la distance culturelle a été explicitée par cinq dimensions : « individualisme/collectivisme », « distance au pouvoir », « masculinité/féminité », « suppression de l’incertitude » et « orientation long-terme/court-terme »10. Il s’impose de choisir des pays avec une distance culturelle minimale afin de réduire les risques de la délocalisation. Malheureusement, la distance culturelle ne correspond pas nécessairement à la distance géographique. Selon la partie empirique de l’étude de Hofstede, la distance culturelle entre l’Allemagne et le Portugal par exemple est pour la majorité des cas plus élevée qu’entre l’Allemagne et l’Inde (cf. Hofstede, Hofstede, 2004) !

30Même si les développeurs dans des projets internationaux sont habitués à l’anglais comme langue de travail, l’utilisation d’une langue étrangère entraîne cependant quelques difficultés. Ainsi que je l’ai mentionné au point 3.1.1., la tâche essentielle de chaque projet de logiciel consiste à transformer une définition de produit plutôt ambiguë en un code source sans ambiguïté. À chaque étape de cette traduction multiple, on peut faire disparaître la polysémie en utilisant par exemple un vocabulaire riche. Malheureusement, ce vocabulaire est souvent seulement disponible aux locuteurs natifs. D’autres problèmes lexicaux, de syntaxe ainsi que des malentendus s’y ajoutent. Par conséquent, des mesures supplémentaires de concrétisation deviennent nécessaires, tout en augmentant les besoins de communication.

3.2. Problèmes d’articulation

31Parfois, le développement est compliqué par le fait qu’une identification fiable des exigences fonctionnelles ou non fonctionnelles au début du développement n’est pas possible. Ce problème comporte trois aspects différents. Premièrement, l’équipe de développement est souvent confrontée à une situation où le client a seulement une vague idée du produit à développer. Deuxièmement, le client peut avoir du mal à articuler son idée ou sa conception du produit, un phénomène qui est souvent décrit dans la littérature par des termes comme « implicit knowledge », « tacit knowledge » ou « sticky information » (Polanyi, 1962 ; Hansen, 1999 ; von Hippel, 1998). Ce second aspect est souvent évident dans l’analyse. Troisièmement, la complexité du développement peut augmenter parce que le produit n’est pas développé pour un seul client bien connu, mais pour un marché anonyme. Cette dernière facette a moins de conséquences pour l’organisation du développement lorsqu’elle n’est pas liée aux deux premières, parce que les exigences fonctionnelles et non fonctionnelles peuvent être identifiées en utilisant de puissantes méthodes d’étude de marché (par exemple la « Conjoint Analysis » ou le « Quality Function Deployment »). Ces dernières peuvent être utilisées pour identifier et prioriser les différentes exigences : en conséquence, une définition du produit sera en principe disponible au début du développement. Pourtant, la définition peut changer au cours du développement. Les deux premières facettes sont caractéristiques de deux sortes de logiciels : les logiciels standards renouvelés et les logiciels sur mesure innovants. Elles se retrouvent notamment dans des situations caractérisées par une forte dynamique de l’environnement technique ou du contexte d’application.

32Les différentes approches choisies pour résoudre ces problèmes se fondent sur deux éléments : le prototypage et l’intensification de la collaboration (Lang, 2004 : 41, 289 ; von Hippel, 1998 : 65). Le prototypage est une stratégie importante pour surmonter les problèmes d’articulation. Sur la base des exigences incomplètes du client et des connaissances qu’ont les développeurs du contexte d’application, une version nettement simplifiée du produit est développée. Ce prototype est alors remis au client pour qu’il puisse concrétiser son idée du produit en testant la fonctionnalité du prototype. L’identification des points faibles du prototype va aider le client à mieux comprendre ce qu’il veut. Ensuite, cette meilleure compréhension l’aide à mieux préciser les exigences fonctionnelles et non fonctionnelles, dans un processus interactif avec l’entreprise de logiciels (un processus itératif la plupart du temps). D’autres approches, par exemple l’intégration de représentants du client au sein de l’équipe de développement ou des entretiens réguliers entre le client et l’entreprise se fondent également sur cette communication intensifiée. Il est évident que la communication intensifiée augmente les coûts de coordination, notamment dans des projets internationaux. Avec trois sites différents (client, siège principal, étranger), avec l’importance de la communication en face-à-face et avec une volonté restreinte du client de voyager entre ces trois sites, la délocalisation empêche alors le processus de communication.

3.3. Problèmes technico-économiques

33Le développement de logiciels doit faire face à plusieurs restrictions. Elles concernent les coûts de développement, la durée de développement, les exigences fonctionnelles et non fonctionnelles ainsi que le savoir technique. Autrefois, le prix d’un produit de logiciels était seulement un critère secondaire ou tertiaire. Mais depuis quelques années, les clients, notamment les clients industriels, sont devenus plus sensibles concernant le prix. Les budgets des départements de technologie de l’information sont beaucoup plus surveillés qu’autrefois. Les entreprises de logiciels sur mesure sont aujourd’hui souvent forcées de signer des contrats à prix fixe. Par conséquent, c’est l’entreprise de logiciels qui assume les coûts et les risques d’événements imprévus au cours du développement. La durée de développement est un critère prioritaire pour le client dans les projets de logiciels sur mesure. Les clients, majoritairement des entreprises, demandent souvent des solutions rapidement disponibles qui correspondent à des changements dans leur structure organisationnelle ou leurs processus.

  • 11 Une programmation partielle suffit souvent, pourvu qu’il existe un prototype exécutable.

34Quelques exigences non fonctionnelles ne peuvent que difficilement être conçues de manière fiable pendant l’analyse et le design. En réalité, le temps de réponse ou la fiabilité ne peuvent être mesurés qu’après que la fonctionnalité a été programmée et le programme exécuté sur un ordinateur11. Le savoir technique concernant les conséquences réelles des décisions de l’analyse ou du design est assez restreint. Par conséquent, il y a des interdépendances importantes entre les différents sous-processus. L’analyse entraîne des décisions implicites concernant le design et l’implémentation, dont la validation nécessite le design, l’implémentation et le test. Quelques éléments fonctionnels et non fonctionnels ne sont identifiés que lors des phases « design » et « implémentation ». L’architecture est fondamentale pour la réalisation des exigences non fonctionnelles. Mais sa qualité n’est jugée précisément que sur la base de l’implémentation et du test.

35Pour maîtriser ces interdépendances, plusieurs stratégies ont été développées, dont les plus importantes sont le recouvrement temporel des sous-processus et le prototypage technique.

36Le recouvrement temporel se fonde sur l’idée qu’un feedback immédiat par les sous-processus sur les conséquences des décisions de la conception, de l’analyse ou du design va révéler des interdépendances inconnues ou imprévues. Pour obtenir ce feedback immédiat, les sous-processus subordonnés doivent être commencés bien avant que les sous-processus supérieurs soient terminés. Par conséquent, on devrait ainsi commencer le design dès que les premières décisions de l’analyse ont été prises et l’implémentation dès que les premières décisions du design ont été prises.

37Sur la base de ce feedback immédiat, les anciennes décisions de l’analyse ou du design peuvent être modifiées ou adaptées. Ensuite, on continue l’analyse et le design et on entre dans un nouveau cycle de « décisions, évaluation, adaptation ». Il est évident que le succès de ce processus itératif se fonde sur un échange rapide entre les différents sous-processus, ce qui nécessite parfois une communication spontanée et riche.

38Le prototypage ressemble un peu à ce recouvrement temporel des sous-processus. Tous deux veulent réduire les risques en obtenant un feedback de l’implémentation et du test le plus tôt possible. Dans ce contexte, le prototypage remplit deux objectifs. D’abord, il contribue à l’identification des alternatives et des restrictions concernant l’implémentation. Ensuite, il s’affirme comme une stratégie efficace afin d’intégrer savoir technique des développeurs et savoir contextuel du client. Comme le recouvrement temporel des sous-processus, le prototypage est fondé sur un échange efficace d’informations pour permettre que les coûts de développement et le temps de développement restent dans la fourchette prévue.

4. Champ de la problématique

39Les projets de logiciels peuvent être décrits par plusieurs dimensions : degré d’innovation, complexité, dynamisme (par exemple des technologies, du contexte d’application, de la compétition). Les problèmes décrits dans cet article concernent d’abord les projets de logiciels qui manifestent un degré élevé d’innovation, une complexité supérieure à la moyenne et un fort dynamisme. Les projets moins innovants, moins complexes et avec un contexte moins dynamique sont plus faciles à planifier. Le savoir nécessaire sur les technologies et le contexte d’application est alors disponible au début du développement et ne vieillit guère pendant l’exécution du projet. Il est plus facile de maîtriser ces projets si l’entreprise a déjà exécuté des projets identiques et si elle a donc acquis une expérience concernant des problèmes potentiels et des stratégies de résolution adéquates. Chaque fois qu’un projet est facile à planifier, il est possible de remplacer une partie de la coordination réactive (sur la base du feedback) par une sorte de coordination anticipative, qui est en général moins coûteuse et beaucoup plus facile à effectuer dans des projets internationaux. Par conséquent, les projets de logiciels relativement peu innovants, peu dynamiques et peu complexes sont plus aptes à la délocalisation. En revanche, les risques augmentent progressivement auprès des gros projets de logiciels (standards et sur mesure) avec un contexte dynamique et auprès des projets de logiciels innovants (standard ou sur mesure).

40Si une délocalisation partielle (par exemple du design détaillé et de l’implémentation) est prévue sous de telles conditions, le succès dépend de plusieurs facteurs :

  •  les expériences précédentes avec le partenaire à l’étranger ;

  • les structures de communication établies pour des nécessités variées de coordination/communication ;

  •  l’intégration des systèmes de développement.

Bibliographie

Allen, Thomas J., 1993, Managing the Flow of Technology: Technology Transfer and the Dissemination of Technological Information within the R&D Organization, Cambridge (MA)-Londres, MIT Press.

BITKOM (Bundesverband Informationswirtschaft, Telekommunikation und neue Medien e.V.) (éd.), 2005, « Leitfaden Outsourcing », www.bitkom.eu/files/documents/BITKOM_Leitfaden_BPO_Stand_20.09.05.pdf (consulté le 29/03/2008).

Boehm, Barry W., 1981, Software Engineering Economics, Englewood Cliffs (NJ), Prentice-Hall.

Brockhoff, Klaus, 1994, Management organisatorischer Schnittstellen – unter besonderer Berücksichtigung der Koordination von Marketingbereichen mit Forschung und Entwicklung, Göttingen, Vandenhoeck & Ruprecht.

Carmel, Erran, 1999, Global Software Teams. Collaborating Across Borders and Time Zones, Englewood Cliffs (NJ), Prentice-Hall.

Chomsky, Noam, 1956, « Three models for the description of language », in IRE Transactions on Information Theory, 2, p. 113-124.

Cusumano, Michael A., Selby, Richard W., 1995, Microsoft Secrets. How the World’s Most Powerful Software Company Creates Technology, Shapes Markets and Manages People, New York, The Free Press.

Daft, Richard L., Lengel, Robert H., 1984, « Information richness: A new approach to managerial behavior and organizations design », in Staw, Barry M., Cummings, Larry L. (éds), Research in Organizational Behavior, t. 6, Greenwich (CT)-Londres, JAI Press, p. 191-233.

Daft, Richard L., Lengel, Robert H., Trevino, Linda Klebe, 1987, « Message equivocality, media selection, and manager performance: Implications for information systems », in MIS Quarterly, 11, n° 3, p. 355-366.

Deloitte & Touche (éd.), 2003, « Outsourcing und Offshoring mit indischen IT-Unternehmen. Die IT-Welt im Wandel », http://bytewerk.webhop.net/support/1.RTFM.stuff/Studie%20Outsourcing%20und%20Offshoring%20mit%20indischen%20IT-Unternehmen.pdf (consulté le 29/03/2008).

Grady, Robert B., 1997, Successful Software Process Improvement, Englewood Cliffs (NJ), Prentice Hall.

Hansen, Morten T., 1999, « The search-transfer problem: The role of weak ties in sharing knowledge across organization subunits », in Administrative Science Quarterly, 44, p. 82-111.

von Hippel, Eric, 1998, « “Sticky Information” and the locus of problem -solving: Implications for innovation », in Chandler, Alfred D., Hagström, Peter, Sölvell, Örjan (éds), The Dynamic Firm. The Role of Technology, -Strategy, Organization, and Regions, New York-Oxford, Oxford University Press , p. 60-77.

Hofstede, Geert, Hofstede, Gert Jan, 20042, Cultures and Organizations: Software of the Mind, New York, McGraw-Hill.

Jacobson, Ivar, Booch, Grady, Rumbaugh, James, 1999, The Unified Software Development Process, Reading (MA), Addison-Wesley.

Lang, Carsten, 2004, Organisation der Software-Entwicklung. Probleme, Konzepte, Lösungen, Wiesbaden, Gabler.

Lullies, Veronika, Bollinger, Heinrich, Weltz, Friedrich, 1993, Wissens-logistik. Über den betrieblichen Umgang mit Wissen bei Entwicklungsvorhaben, Francfort/M.-New York, Campus.

Moczadlo, Regina, 2003, Chancen und Risiken des -Offshore Development.
Empirische Analyse der Erfahrungen deutscher Unternehmen
, http://www.competence-site.de//offshore.nsf/8FB68EAB823EF285C1256D72005BBCD1/$File/studie_offshore_prof_moczadlo.pdf (consulté le 29/03/2008).

Polanyi, Michael, 19622, Personal Knowledge. Towards a Post-Critical Philosophy, Londres-Chicago, University of Chicago Press.

Uniware (éd.), 2003, Sourcing von IT-Services im Offshore Verfahren, http://www.competence-site.de/offshore.nsf/EDA093463CB18584C1256E9200300F98/$File/sourcing_von_it-services_im_offshore_verfahren.pdf (consulté le 29/03/2008).

Wegener, Ingo, 20053, Theoretische Informatik. Eine algorithmenorientierte Einführung, Wiesbaden, Teubner.

Notes

1 Même si le coût salarial représente souvent le motif principal de la délocalisation, il y en a d’autres, par exemple l’accélération du développement, le manque de main-d’œuvre qualifiée, un goulet d’étranglement temporaire ou la transformation des coûts fixes en coûts variables (Moczaldo, 2003 : 3). Au début, la délocalisation était due à la pénurie de personnel qualifié dans le secteur informatique.

2 Selon une étude effectuée par l’Institut universitaire de technologie de Pforzheim (BITKOM 2005 : 11). Pour les coûts du travail horaire, voir aussi Uniware, 2003. Entre 1991 et 2002, les exportations de logiciels d’Inde ont été multipliées par 60, souvent avec un taux de croissance annuel supérieur à 50 % (Deloitte & Touche, 2003 : 8).

3 Bien qu’il y ait d’autres problèmes (par exemple la sélection du partenaire approprié, les barrières culturelles et langagières, les problèmes juridiques), cet article se concentre sur les problèmes de coordination et de communication, problèmes dominants selon Moczadlo (2003). Voir également BITKOM, 2005 : 17.

4 Le mot « général » indique ici une description indépendante de la plate-forme technique.

5 Pour les exigences des compilateurs, voir Wegener, 2005 : 128, 197 ; pour les grammaires des langues formelles, voir Chomsky, 1956.

6 Il est évident que l’importance de ces facteurs dépend des propriétés du projet. Les projets innovants notamment, mal structurés, et avec des demandes changeantes, profitent de ces facteurs, alors qu’ils sont moins importants dans des projets d’adaptation ou de perfectionnement (cf. Lullies, Bollinger, Weltz, 1993 : 187).

7 La délocalisation entraîne d’importants coûts de coordination. Les propriétés du projet vont déterminer l’ampleur de la coordination nécessaire. Dans certains projets, ces coûts peuvent atteindre un niveau prohibitif. Parfois, les coûts de coordination se montrent directement, par exemple sous forme de frais de déplacement, parfois ils sont moins évidents (voir le point 3.3. pour les instruments de coordination).

8 Souvent, lorsqu’il y a échange d’information entre différentes entreprises, les supérieurs sont assez sensibles à la forme de l’échange. Même si la communication directe entre des membres des différents départements d’une entreprise peut être acceptée ou même souhaitée par les supérieurs, les mêmes supérieurs vont probablement exiger que toute communication inter-entreprises se fasse en leur présence ou au moins avec leur concours.

9 Souvent, cette ambiguïté disparaît seulement après quelques itérations durant le développement.

10 Cette dernière dimension a été ajoutée plus tard.

11 Une programmation partielle suffit souvent, pourvu qu’il existe un prototype exécutable.

Table des illustrations

Titre Figure 1 : Taux journalier normalisé pour programmeurs2
URL http://books.openedition.org/psn/docannexe/image/6589/img-1.jpg
Fichier image/jpeg, 20k
Titre Figure 2 : Processus de développement
URL http://books.openedition.org/psn/docannexe/image/6589/img-2.jpg
Fichier image/jpeg, 39k

Auteur

Université Sorbonne Nouvelle – Paris 3

Le texte et les autres éléments (illustrations, fichiers annexes importés) sont sous Licence OpenEdition Books, sauf mention contraire.

Rechercher dans OpenEdition Search

Vous allez être redirigé vers OpenEdition Search