La chose aura beaucoup fait parler d'elle : avec iPhone OS 4, Apple interdit le développement d'applications par le biais de SDK alternatifs, au grand dam d'Adobe qui dévoile dans le même temps Flash CS5. À part pour le seul plaisir d'enquiquiner Adobe, pourquoi Apple a-t-elle ajouté cette nouvelle règle ? Après tout, elle aurait tout aussi bien pu voir d'un bon œil que Flash, loin de fragiliser l'App Store comme il aurait pu le faire sous forme de plug-in web, ne faisait qu'apporter de nombreuses applications supplémentaires sur son magasin. (lire : Apple, Adobe et Flash).
Les choses sont moins évidentes qu'elle n'y paraissent : il s'agit pour Apple d'une question de qualité et de stratégie. Pour le cas spécifique de Flash CS5, le logiciel permet la création d'une application directement compilée pour iPhone à l'aide de LLVM. L'approche ne manque pas d'épineux inconvénients : ainsi, il est non seulement impossible de débugger l'application, mais en outre aucun des éléments natifs de l'interface d'iPhone OS ne peuvent être exploités. Ça n'est pas nécessairement problématique pour les jeux, qui souvent contiennent leurs propres univers graphiques, mais les autres types d'applications qui seraient réalisées à l'aide de Flash auraient dû intégrer leurs propres éléments d'interface, comme c'est souvent le cas pour les applications multiplateformes.
Des SDK alternatif pour répondre à des besoins spécifiques
Et bien loin de s'arrêter à Flash, cette nouvelle règle met dans l'embarras une dizaine de SDK alternatifs (lire : iPhone OS 4.0 : Vent de panique pour les SDK alternatifs). La profusion de ces environnements de développement souligne qu'il y a un certain nombre de besoins auxquels Xcode ne satisfait pas à lui seul. On peut souligner deux grandes tendances : le développement multiplateforme, et la facilité d'accès.
Concernant cette dernière, elle consiste en différentes approches : certains SDK proposent un moyen plus simple de réaliser des applications pour les apprentis développeurs (comme c'est le cas de GameSalad qui permet de réaliser des jeux sans la moindre ligne de code), d'autres proposent une réponse simple à un problème compliqué (Unity intègre par exemple un moteur physique pour les jeux 3D), d'autres encore permettent à des développeurs qui maîtrisent déjà un langage de l'utiliser sans avoir à apprendre l'Objective-C.
Les SDK orientés multiplateformes quant à eux permettent de créer un projet qui sera compilé pour différentes machines. Ainsi, un projet réalisé avec Unity permet de créer un jeu qui pourra être exécuté dans un plug-in web, dans une application autonome sur Mac OS X comme sur Windows, de même que sur les consoles de jeux (Xbox 360, Wii, PS3), et enfin sur l'App Store, en limitant les modifications spécifiques à chaque plateforme au maximum.
Ces deux approches sont complémentaires et non-exclusives. On pourrait croire qu'Apple verrait d'un bon œil la manne de nouveaux développeurs que ces environnements de développement apportent, d'autant qu'un certain nombre d'applications réalisées avec ces SDK se sont fort bien vendues. Mais comme chaque pièce a son revers, ces avantages ont un prix qu'Apple ne semble pas disposée à payer.
Des partenaires encombrants
Les environnements de développement multiplateforme posent de nombreux problèmes : avec eux, l'App Store n'est plus qu'une des nombreuses destinations possibles d'un logiciel. Les développeurs ne codent plus pour l'iPhone, ils codent pour l'environnement de développement, qui prend par voie de conséquence tout l'ascendant en terme de plateforme, un ascendant qu'Apple n'est pas disposée à lâcher si facilement. D'autre part, sachant que la philosophie de ces IDE (Integrated Development Environment) se résume à "code once, run anywhere" (programmez une fois, exécutez n'importe où), celle-ci tend à gommer les spécificités de chaque plateforme. Si une fonction n'est pas disponible uniformément, il y a de fortes chances qu'elle ne soit tout simplement pas gérée, ce qui résulte à un nivellement par le bas. D'autre part, sachant que chaque plateforme propose une interface utilisateur qui lui est propre, tant en terme de fonctionnement que d'apparence, il est impossible de réaliser une application qui tire parti de ces spécificités : les boutons n'ont pas la même taille d'un OS à l'autre, on ne peut donc créer de mise en page cohérente et harmonieuse d'une machine à l'autre. Les IDE sont donc contraints d'intégrer leurs propres éléments d'interface qui sont appliqués à tous, ce qui provoque des disparités parfois ennuyeuses.
Tout ceci participe à une dilution de l'influence de l'App Store : en perdant de sa spécificité, il perd de son attractivité. Si les logiciels sont indifféremment distribués sur toutes les plateformes mobiles, il n'y a plus lieu d'en préférer une par rapport à l'autre. Mais John Gruber souligne un autre inconvénient : ces SDK sont un intermédiaire entre Apple et les développeurs. Si un tel SDK devait devenir prédominant, celui-ci pourrait avoir une influence catastrophique pour Apple : il suffirait que celui-ci mette du temps (ou de la mauvaise volonté) à intégrer une nouveauté d'iPhone OS pour que celle-ci soit tout simplement inaccessible aux développeurs qui utilisent ce SDK. Ce qui par voie de conséquence lui donnerait un contrôle sur la plateforme qu'Apple ne peut pas céder.
Steve Jobs n'a d'ailleurs pas manqué de souligner l'article de John Gruber en le qualifiant de "très perspicace". Le patron d'Apple a également souligné que toute couche intermédiaire entre la plateforme et le développeur ne conduit qu'à des réalisations en-deçà de ses critères qualitatifs, et empêche le développement de la plateforme (lire : SDK iPhone : Steve Jobs livre sa réponse). Apple compte donc que l'attractivité de sa plateforme encouragera les développeurs suffisamment motivés à se convertir pleinement à Xcode, même au sacrifice d'une sortie multiplateforme.
Un SDK pour les gouverner tous
L'argument qualitatif est toutefois quelque peu contestable, dans la mesure où une recherche du mot "fart" sur l'App Store rapporte quelques 518 applications, soit 0,3 % de l'App Store, dont l'essentiel consiste à émettre le son d'une flatulence à la pression d'un bouton… Le développement d'une application dans tel ou tel environnement n'est aucunement un gage de qualité : la pire des applications réalisée avec Unity a sans aucun doute une "production value" supérieure au bas du panier produit avec Xcode. Cependant, Apple fait toutefois preuve de cohérence dans la mesure où elle semble avoir décidé de serrer la vis au niveau de la qualité des applications (lire : Une application rejetée… pour cause d'inanité).
Quoi qu'il en soit, cette nouvelle politique met Adobe dans une situation particulièrement inconfortable : jusqu'ici Flash était une réponse universelle, puisque les contenus qui se destinent au plug-in d'Adobe était susceptibles de fonctionner sur n'importe quelle machine. L'arrivée de l'iPhone a remis en question cette hégémonie. Adobe avait trouvé un moyen de contourner cette limitation en offrant la possibilité de créer des applications pour l'iPhone avec Flash CS5, redonnant à sa plateforme un aspect universel bon gré mal gré. Seulement quatre jours avant la sortie de la Creative Suite 5, Apple annihile les efforts d'Adobe : Flash est indésirable y compris sur l'App Store. La réaction épidermique de Lee Brimelow montre bien l'état d'esprit qui doit régner dans les locaux de San Jose (lire : Evangéliste Adobe : « Apple, va te faire… »). De son côté, John Dowdell indique sur Twitter qu'il sait que « nombre de personnes de qualité travaillent chez Apple. S'ils souhaitent travailler pour une société plus soucieuse de l'éthique, Adobe embauche ».
Naturellement les hauts responsables d'Adobe font preuve de plus de retenue. Après avoir donné son sentiment sur son blog (lire : SDK iPhone : le directeur technique d'Adobe relativise), Kevin Lynch souligne dans une interview accordée à All Things Digital qu'il ne s'agit que d'une fonctionnalité parmi tant d'autres de la suite CS5, et que l'iPhone n'est qu'un écran parmi tant d'autres sur lesquels Flash sera bel et bien disponible (lire Vers un procès Apple/Adobe ?).
Apple casse le standard d'Adobe
Adobe a beau jeu de minimiser l'impact de la décision d'Apple, la fonctionnalité en question a été très mise en avant depuis sa révélation début octobre 2009, et on ne doute pas que le revirement d'Apple la met dans l'embarras. Quant au nombre de destinations possibles pour Flash, s'il fait naturellement partie des avantages indéniables du logiciel de création, c'est bien seulement l'iPhone qui était jusqu'ici mis en avant par Adobe, et non un nombre de plateformes qui vient de baisser d'une unité. Car l'App Store a un pouvoir d'attraction très conséquent, et fait beaucoup parler de lui. Les retombées média d'une application pour McDonald's ont une portée conséquente pour un investissement bien moindre à une campagne publicitaire. Non seulement cette nouvelle politique détruit les efforts d'Adobe pour intégrer cette fonctionnalité à Flash CS5, mais en outre elle met à mal Adobe qui s'est plue jusqu'ici à vanter les mérites "d'un web unique, sur n'importe quel écran", il lui faudra dorénavant modérer ses ambitions.
D'aucuns voient dans ce funeste retournement de situation un juste retour de bâton pour Adobe : en 1996, alors qu'Apple était au plus bas, Adobe a décidé de faire de Windows sa plateforme de prédilection, réévaluant au cas par cas la sortie de ses nouveaux logiciels sur Mac OS X, et interrompant même la publication de logiciels précédemment sortis sur Mac. À l'époque, c'était Apple qui était en demande, et c'était à Adobe d'évaluer s'il était justifié ou non d'ouvrir son catalogue aux machines d'Apple. La situation est aujourd'hui inversée, et c'est Adobe qui se trouve en situation de demande, et qui dépend du seul bon vouloir d'Apple. Un coup du sort bien cruel et ironique, mais ne nous y leurrons pas : seule la stratégie et les réalités économiques prévalent sur ce type de décision, et non les quelconques amertumes et ressentiments nourris au fil des ans. Apple ne s'encombrerait nullement de telles considérations si là était son propre intérêt. Adobe n'a d'ailleurs pas la moindre intention de lui rendre la pareille et exclut toute velléité de laisser tomber Mac OS X en guise de mesure coercitive : elle aurait bien plus à y perdre qu'à y gagner.
Tabula rasa ?
Même si elle est manifestement la première visée, Adobe est cependant loin d'être la seule concernée par la nouvelle règle. Comble de l'ironie, alors qu'Ansca Mobile soulignait que, contrairement à son SDK Corona, Flash était susceptible de violer les précédentes conditions d'utilisation de l'App Store (lire : Et si Apple refusait les applications Flash ?), ce sont tous les SDK alternatifs qui pourraient bien se voir refuser l'entrée de l'App Store (lire : iPhone OS 4.0 : Vent de panique pour les SDK alternatifs). Quand bien même ceux-ci parviendraient-ils à contourner cette limitation, comme ils sont nombreux à l'annoncer, le mal est fait : pour les utilisateurs de ces SDK, Apple sera toujours susceptible de modifier à nouveau ses règles et anéantir leurs investissements. Le seul moyen d'avoir toutes ses chances pour faire valider son application sera donc d'en passer par les outils qui ont reçu la bénédiction officielle d'Apple. Il faudra donc dorénavant être un développeur es qualité en Objective-C, ou du moins C/C++, pour créer des applications pour l'App Store.
On se doute néanmoins qu'Apple fera preuve de magnanimité concernant certaines applications. La plupart des jeux basés sur un moteur ouvert, tels que l'Unreal Engine par exemple, sont personnalisés à l'aide de scripts écrits avec LUA, un langage dédié (d'ailleurs utilisé par Corona). On peut les considérer comme des "super" fichiers de paramètres, permettant de personnaliser un moteur de jeu à d'autres couleurs, mais ceux-ci permettent également de définir le comportement même du moteur de jeu, et à ce titre sont en plein dans le domaine de la programmation à proprement parler. Apple ne peut décemment pas claquer la porte à certains titres sous prétexte que ses règles ne sont pas en adéquation avec les standards de l'industrie, comme le souligne le développeur Louis Gerbarg sur son blog.
Le délicat équilibre entre créativité et professionnalisme
Apple se trouve en fait face à un paradoxe épineux : avec un ticket d'entrée à $99 par an, l'App Store est potentiellement ouvert à tous les budgets. Cet état de fait offre à l'App Store du sang neuf avec nombre de productions indépendantes qui sortent des sentiers battus, et favorise l'innovation : il est plus facile de prendre des risques avec des petits budgets, alors que les grosses productions ont tendance à rester dans le sillon des logiciels qui ont déjà fait leurs preuves. L'autre avantage d'un tel tarif c'est qu'il permet d'ouvrir grand les portes de l'App Store et de lui fournir l'impressionnante quantité d'applications qu'on lui connaît (près de 160.000 à ce jour). Mais ces avantages ont également leurs revers : il est plus difficile pour une application de qualité de sortir du lot, et elle peut se voir noyée dans la masse de logiciels de moindre intérêt. D'autre part, certains "petits" développeurs, jusque-là habitués à pouvoir proposer leurs logiciels librement sur ordinateur, ont parfois du mal à tolérer les exigences d'Apple, dont les règles changent régulièrement et se voient inégalement appliquées, ce qui crée des polémiques à répétition.
Un problème que ne connaissent pas les gros éditeurs, habitués depuis des années à se voir soumis à ces conditions dans le monde des consoles, dont le ticket d'entrée est autrement plus élevé. Le SDK de la PS3 coûte $10.250 en Amérique du Nord et 7.500 € en Europe, celui de la Wii se monte aux environs de $2.000. Si le SDK de la Wii reste accessible à certains développeurs indépendants, ces tarifs les mettent hors de portée des amateurs et hobbyistes de tout poil, et garantissent un minimum de sérieux et d'investissement de la part des développeurs. Il faut toutefois noter que ces tarifs n'assurent aucun passe-droit aux éditeurs qui peuvent tout aussi bien se voir recalés par la validation des constructeurs, malgré un investissement autrement plus conséquent que sur l'App Store.
Ajoutons tout de même qu'en dehors du circuit de distribution classique, chacune des consoles offre un magasin en ligne sur lesquels sont distribués démos et jeux indépendants. Le kit de Microsoft pour la Xbox 360 propose une licence qui reprend le schéma de l'App Store. Vendue $99 par an, elle offre aux développeurs indépendants la possibilité de vendre leurs jeux sur le Xbox Live Arcade (Microsoft conserve 30 % de commission). D'autre part, Unity permet justement de créer des jeux pour les trois consoles, à un tarif bien moindre que les kits officiels.
Avec 85 millions d'iPhone et d'iPod touch vendus, l'App Store s'adresse à un marché potentiel supérieur à celui de la GameBoy Advance (81,47 millions de ventes dans le monde), ce qui place la plateforme d'Apple en cinquième position des consoles les plus vendues de tous les temps, juste derrière la première PlayStation et loin devant la Wii (67,45 millions), la PSP (60,2 millions), la Xbox 360 (39 millions), ou la PlayStation 3 (33,5 millions). Parmi les consoles actuellement en exploitation, seule la Nintendo DS fait mieux avec 125,13 millions de ventes. Pourquoi donc ne pas limiter l'accès de l'App Store aux mêmes éditeurs et rester entre gens de bonne compagnie ?
Puisqu'à l'image de TF1 en 1997, Apple semble avoir entamé une "quête de sens" pour son catalogue d'applications, elle pourrait légitimement estimer que sa plateforme a atteint la masse critique qui pourrait justifier de limiter l'accès de son App Store à une élite plus restreinte d'éditeurs et développeurs triés sur le volet, en augmentant le tarif de la licence annuelle. Une telle décision entraînerait de facto la professionnalisation de l'offre, et sa limitation à des investissements plus importants. La qualité générale des applications s'en ressentirait, et cela limiterait les polémiques autour de la validation. Mais ce choix induirait également l'augmentation du prix moyen des applications, la limitation des applications gratuites à celles qui font la promotion des marques, ou du moins à celles qui s'inscriraient dans des solutions dont le modèle économique justifierait cet investissement, et la limitation de la taille du catalogue. À l'heure où c'est la politique actuelle d'Apple qui a donné le la des plateformes mobiles et où la concurrence fait rage, un tel choix pourrait bien se faire à son désavantage.
Mais la sélection naturelle se fera peut-être autrement : avec des exigences changeantes et toujours plus importantes, Apple pourrait décourager les développeurs amateurs, et seuls ceux pour qui l'App Store représente un avantage bien supérieur à ces petites déconvenues pourront se permettre de continuer à investir sur cette plateforme. Apple laisserait à Flash et aux plateformes plus souples le soin d'intégrer les applications de seconde zone, tout en ne leur ayant jamais officiellement claqué la porte au nez.
Les choses sont moins évidentes qu'elle n'y paraissent : il s'agit pour Apple d'une question de qualité et de stratégie. Pour le cas spécifique de Flash CS5, le logiciel permet la création d'une application directement compilée pour iPhone à l'aide de LLVM. L'approche ne manque pas d'épineux inconvénients : ainsi, il est non seulement impossible de débugger l'application, mais en outre aucun des éléments natifs de l'interface d'iPhone OS ne peuvent être exploités. Ça n'est pas nécessairement problématique pour les jeux, qui souvent contiennent leurs propres univers graphiques, mais les autres types d'applications qui seraient réalisées à l'aide de Flash auraient dû intégrer leurs propres éléments d'interface, comme c'est souvent le cas pour les applications multiplateformes.
Des SDK alternatif pour répondre à des besoins spécifiques
Et bien loin de s'arrêter à Flash, cette nouvelle règle met dans l'embarras une dizaine de SDK alternatifs (lire : iPhone OS 4.0 : Vent de panique pour les SDK alternatifs). La profusion de ces environnements de développement souligne qu'il y a un certain nombre de besoins auxquels Xcode ne satisfait pas à lui seul. On peut souligner deux grandes tendances : le développement multiplateforme, et la facilité d'accès.
Concernant cette dernière, elle consiste en différentes approches : certains SDK proposent un moyen plus simple de réaliser des applications pour les apprentis développeurs (comme c'est le cas de GameSalad qui permet de réaliser des jeux sans la moindre ligne de code), d'autres proposent une réponse simple à un problème compliqué (Unity intègre par exemple un moteur physique pour les jeux 3D), d'autres encore permettent à des développeurs qui maîtrisent déjà un langage de l'utiliser sans avoir à apprendre l'Objective-C.
Les SDK orientés multiplateformes quant à eux permettent de créer un projet qui sera compilé pour différentes machines. Ainsi, un projet réalisé avec Unity permet de créer un jeu qui pourra être exécuté dans un plug-in web, dans une application autonome sur Mac OS X comme sur Windows, de même que sur les consoles de jeux (Xbox 360, Wii, PS3), et enfin sur l'App Store, en limitant les modifications spécifiques à chaque plateforme au maximum.
Ces deux approches sont complémentaires et non-exclusives. On pourrait croire qu'Apple verrait d'un bon œil la manne de nouveaux développeurs que ces environnements de développement apportent, d'autant qu'un certain nombre d'applications réalisées avec ces SDK se sont fort bien vendues. Mais comme chaque pièce a son revers, ces avantages ont un prix qu'Apple ne semble pas disposée à payer.
Des partenaires encombrants
Les environnements de développement multiplateforme posent de nombreux problèmes : avec eux, l'App Store n'est plus qu'une des nombreuses destinations possibles d'un logiciel. Les développeurs ne codent plus pour l'iPhone, ils codent pour l'environnement de développement, qui prend par voie de conséquence tout l'ascendant en terme de plateforme, un ascendant qu'Apple n'est pas disposée à lâcher si facilement. D'autre part, sachant que la philosophie de ces IDE (Integrated Development Environment) se résume à "code once, run anywhere" (programmez une fois, exécutez n'importe où), celle-ci tend à gommer les spécificités de chaque plateforme. Si une fonction n'est pas disponible uniformément, il y a de fortes chances qu'elle ne soit tout simplement pas gérée, ce qui résulte à un nivellement par le bas. D'autre part, sachant que chaque plateforme propose une interface utilisateur qui lui est propre, tant en terme de fonctionnement que d'apparence, il est impossible de réaliser une application qui tire parti de ces spécificités : les boutons n'ont pas la même taille d'un OS à l'autre, on ne peut donc créer de mise en page cohérente et harmonieuse d'une machine à l'autre. Les IDE sont donc contraints d'intégrer leurs propres éléments d'interface qui sont appliqués à tous, ce qui provoque des disparités parfois ennuyeuses.
Tout ceci participe à une dilution de l'influence de l'App Store : en perdant de sa spécificité, il perd de son attractivité. Si les logiciels sont indifféremment distribués sur toutes les plateformes mobiles, il n'y a plus lieu d'en préférer une par rapport à l'autre. Mais John Gruber souligne un autre inconvénient : ces SDK sont un intermédiaire entre Apple et les développeurs. Si un tel SDK devait devenir prédominant, celui-ci pourrait avoir une influence catastrophique pour Apple : il suffirait que celui-ci mette du temps (ou de la mauvaise volonté) à intégrer une nouveauté d'iPhone OS pour que celle-ci soit tout simplement inaccessible aux développeurs qui utilisent ce SDK. Ce qui par voie de conséquence lui donnerait un contrôle sur la plateforme qu'Apple ne peut pas céder.
Steve Jobs n'a d'ailleurs pas manqué de souligner l'article de John Gruber en le qualifiant de "très perspicace". Le patron d'Apple a également souligné que toute couche intermédiaire entre la plateforme et le développeur ne conduit qu'à des réalisations en-deçà de ses critères qualitatifs, et empêche le développement de la plateforme (lire : SDK iPhone : Steve Jobs livre sa réponse). Apple compte donc que l'attractivité de sa plateforme encouragera les développeurs suffisamment motivés à se convertir pleinement à Xcode, même au sacrifice d'une sortie multiplateforme.
Un SDK pour les gouverner tous
L'argument qualitatif est toutefois quelque peu contestable, dans la mesure où une recherche du mot "fart" sur l'App Store rapporte quelques 518 applications, soit 0,3 % de l'App Store, dont l'essentiel consiste à émettre le son d'une flatulence à la pression d'un bouton… Le développement d'une application dans tel ou tel environnement n'est aucunement un gage de qualité : la pire des applications réalisée avec Unity a sans aucun doute une "production value" supérieure au bas du panier produit avec Xcode. Cependant, Apple fait toutefois preuve de cohérence dans la mesure où elle semble avoir décidé de serrer la vis au niveau de la qualité des applications (lire : Une application rejetée… pour cause d'inanité).
Quoi qu'il en soit, cette nouvelle politique met Adobe dans une situation particulièrement inconfortable : jusqu'ici Flash était une réponse universelle, puisque les contenus qui se destinent au plug-in d'Adobe était susceptibles de fonctionner sur n'importe quelle machine. L'arrivée de l'iPhone a remis en question cette hégémonie. Adobe avait trouvé un moyen de contourner cette limitation en offrant la possibilité de créer des applications pour l'iPhone avec Flash CS5, redonnant à sa plateforme un aspect universel bon gré mal gré. Seulement quatre jours avant la sortie de la Creative Suite 5, Apple annihile les efforts d'Adobe : Flash est indésirable y compris sur l'App Store. La réaction épidermique de Lee Brimelow montre bien l'état d'esprit qui doit régner dans les locaux de San Jose (lire : Evangéliste Adobe : « Apple, va te faire… »). De son côté, John Dowdell indique sur Twitter qu'il sait que « nombre de personnes de qualité travaillent chez Apple. S'ils souhaitent travailler pour une société plus soucieuse de l'éthique, Adobe embauche ».
Naturellement les hauts responsables d'Adobe font preuve de plus de retenue. Après avoir donné son sentiment sur son blog (lire : SDK iPhone : le directeur technique d'Adobe relativise), Kevin Lynch souligne dans une interview accordée à All Things Digital qu'il ne s'agit que d'une fonctionnalité parmi tant d'autres de la suite CS5, et que l'iPhone n'est qu'un écran parmi tant d'autres sur lesquels Flash sera bel et bien disponible (lire Vers un procès Apple/Adobe ?).
Apple casse le standard d'Adobe
Adobe a beau jeu de minimiser l'impact de la décision d'Apple, la fonctionnalité en question a été très mise en avant depuis sa révélation début octobre 2009, et on ne doute pas que le revirement d'Apple la met dans l'embarras. Quant au nombre de destinations possibles pour Flash, s'il fait naturellement partie des avantages indéniables du logiciel de création, c'est bien seulement l'iPhone qui était jusqu'ici mis en avant par Adobe, et non un nombre de plateformes qui vient de baisser d'une unité. Car l'App Store a un pouvoir d'attraction très conséquent, et fait beaucoup parler de lui. Les retombées média d'une application pour McDonald's ont une portée conséquente pour un investissement bien moindre à une campagne publicitaire. Non seulement cette nouvelle politique détruit les efforts d'Adobe pour intégrer cette fonctionnalité à Flash CS5, mais en outre elle met à mal Adobe qui s'est plue jusqu'ici à vanter les mérites "d'un web unique, sur n'importe quel écran", il lui faudra dorénavant modérer ses ambitions.
D'aucuns voient dans ce funeste retournement de situation un juste retour de bâton pour Adobe : en 1996, alors qu'Apple était au plus bas, Adobe a décidé de faire de Windows sa plateforme de prédilection, réévaluant au cas par cas la sortie de ses nouveaux logiciels sur Mac OS X, et interrompant même la publication de logiciels précédemment sortis sur Mac. À l'époque, c'était Apple qui était en demande, et c'était à Adobe d'évaluer s'il était justifié ou non d'ouvrir son catalogue aux machines d'Apple. La situation est aujourd'hui inversée, et c'est Adobe qui se trouve en situation de demande, et qui dépend du seul bon vouloir d'Apple. Un coup du sort bien cruel et ironique, mais ne nous y leurrons pas : seule la stratégie et les réalités économiques prévalent sur ce type de décision, et non les quelconques amertumes et ressentiments nourris au fil des ans. Apple ne s'encombrerait nullement de telles considérations si là était son propre intérêt. Adobe n'a d'ailleurs pas la moindre intention de lui rendre la pareille et exclut toute velléité de laisser tomber Mac OS X en guise de mesure coercitive : elle aurait bien plus à y perdre qu'à y gagner.
Tabula rasa ?
Même si elle est manifestement la première visée, Adobe est cependant loin d'être la seule concernée par la nouvelle règle. Comble de l'ironie, alors qu'Ansca Mobile soulignait que, contrairement à son SDK Corona, Flash était susceptible de violer les précédentes conditions d'utilisation de l'App Store (lire : Et si Apple refusait les applications Flash ?), ce sont tous les SDK alternatifs qui pourraient bien se voir refuser l'entrée de l'App Store (lire : iPhone OS 4.0 : Vent de panique pour les SDK alternatifs). Quand bien même ceux-ci parviendraient-ils à contourner cette limitation, comme ils sont nombreux à l'annoncer, le mal est fait : pour les utilisateurs de ces SDK, Apple sera toujours susceptible de modifier à nouveau ses règles et anéantir leurs investissements. Le seul moyen d'avoir toutes ses chances pour faire valider son application sera donc d'en passer par les outils qui ont reçu la bénédiction officielle d'Apple. Il faudra donc dorénavant être un développeur es qualité en Objective-C, ou du moins C/C++, pour créer des applications pour l'App Store.
On se doute néanmoins qu'Apple fera preuve de magnanimité concernant certaines applications. La plupart des jeux basés sur un moteur ouvert, tels que l'Unreal Engine par exemple, sont personnalisés à l'aide de scripts écrits avec LUA, un langage dédié (d'ailleurs utilisé par Corona). On peut les considérer comme des "super" fichiers de paramètres, permettant de personnaliser un moteur de jeu à d'autres couleurs, mais ceux-ci permettent également de définir le comportement même du moteur de jeu, et à ce titre sont en plein dans le domaine de la programmation à proprement parler. Apple ne peut décemment pas claquer la porte à certains titres sous prétexte que ses règles ne sont pas en adéquation avec les standards de l'industrie, comme le souligne le développeur Louis Gerbarg sur son blog.
Le délicat équilibre entre créativité et professionnalisme
Apple se trouve en fait face à un paradoxe épineux : avec un ticket d'entrée à $99 par an, l'App Store est potentiellement ouvert à tous les budgets. Cet état de fait offre à l'App Store du sang neuf avec nombre de productions indépendantes qui sortent des sentiers battus, et favorise l'innovation : il est plus facile de prendre des risques avec des petits budgets, alors que les grosses productions ont tendance à rester dans le sillon des logiciels qui ont déjà fait leurs preuves. L'autre avantage d'un tel tarif c'est qu'il permet d'ouvrir grand les portes de l'App Store et de lui fournir l'impressionnante quantité d'applications qu'on lui connaît (près de 160.000 à ce jour). Mais ces avantages ont également leurs revers : il est plus difficile pour une application de qualité de sortir du lot, et elle peut se voir noyée dans la masse de logiciels de moindre intérêt. D'autre part, certains "petits" développeurs, jusque-là habitués à pouvoir proposer leurs logiciels librement sur ordinateur, ont parfois du mal à tolérer les exigences d'Apple, dont les règles changent régulièrement et se voient inégalement appliquées, ce qui crée des polémiques à répétition.
Un problème que ne connaissent pas les gros éditeurs, habitués depuis des années à se voir soumis à ces conditions dans le monde des consoles, dont le ticket d'entrée est autrement plus élevé. Le SDK de la PS3 coûte $10.250 en Amérique du Nord et 7.500 € en Europe, celui de la Wii se monte aux environs de $2.000. Si le SDK de la Wii reste accessible à certains développeurs indépendants, ces tarifs les mettent hors de portée des amateurs et hobbyistes de tout poil, et garantissent un minimum de sérieux et d'investissement de la part des développeurs. Il faut toutefois noter que ces tarifs n'assurent aucun passe-droit aux éditeurs qui peuvent tout aussi bien se voir recalés par la validation des constructeurs, malgré un investissement autrement plus conséquent que sur l'App Store.
Ajoutons tout de même qu'en dehors du circuit de distribution classique, chacune des consoles offre un magasin en ligne sur lesquels sont distribués démos et jeux indépendants. Le kit de Microsoft pour la Xbox 360 propose une licence qui reprend le schéma de l'App Store. Vendue $99 par an, elle offre aux développeurs indépendants la possibilité de vendre leurs jeux sur le Xbox Live Arcade (Microsoft conserve 30 % de commission). D'autre part, Unity permet justement de créer des jeux pour les trois consoles, à un tarif bien moindre que les kits officiels.
Avec 85 millions d'iPhone et d'iPod touch vendus, l'App Store s'adresse à un marché potentiel supérieur à celui de la GameBoy Advance (81,47 millions de ventes dans le monde), ce qui place la plateforme d'Apple en cinquième position des consoles les plus vendues de tous les temps, juste derrière la première PlayStation et loin devant la Wii (67,45 millions), la PSP (60,2 millions), la Xbox 360 (39 millions), ou la PlayStation 3 (33,5 millions). Parmi les consoles actuellement en exploitation, seule la Nintendo DS fait mieux avec 125,13 millions de ventes. Pourquoi donc ne pas limiter l'accès de l'App Store aux mêmes éditeurs et rester entre gens de bonne compagnie ?
Puisqu'à l'image de TF1 en 1997, Apple semble avoir entamé une "quête de sens" pour son catalogue d'applications, elle pourrait légitimement estimer que sa plateforme a atteint la masse critique qui pourrait justifier de limiter l'accès de son App Store à une élite plus restreinte d'éditeurs et développeurs triés sur le volet, en augmentant le tarif de la licence annuelle. Une telle décision entraînerait de facto la professionnalisation de l'offre, et sa limitation à des investissements plus importants. La qualité générale des applications s'en ressentirait, et cela limiterait les polémiques autour de la validation. Mais ce choix induirait également l'augmentation du prix moyen des applications, la limitation des applications gratuites à celles qui font la promotion des marques, ou du moins à celles qui s'inscriraient dans des solutions dont le modèle économique justifierait cet investissement, et la limitation de la taille du catalogue. À l'heure où c'est la politique actuelle d'Apple qui a donné le la des plateformes mobiles et où la concurrence fait rage, un tel choix pourrait bien se faire à son désavantage.
Mais la sélection naturelle se fera peut-être autrement : avec des exigences changeantes et toujours plus importantes, Apple pourrait décourager les développeurs amateurs, et seuls ceux pour qui l'App Store représente un avantage bien supérieur à ces petites déconvenues pourront se permettre de continuer à investir sur cette plateforme. Apple laisserait à Flash et aux plateformes plus souples le soin d'intégrer les applications de seconde zone, tout en ne leur ayant jamais officiellement claqué la porte au nez.
