Consultation

Quand vous avez une bonne idée d’où vous voulez aller, nous sommes ici pour vous donner le « comment ».

Nous fournissons des solutions en consultation pour la recherche et le développement d’applications haute-performances. Comme indiqué sur la figure en bas de page, la nature exacte de notre expertise dépendra grandement de votre contexte.

Expliquons la figure dans son ensemble. Elle décrit le processus de création, depuis une idée générale jusqu’à une application commerciale. La hauteur de la figure peut être vue grossièrement comme l’ordre de magnitude de l’investissement (en temps et en argent) nécessaire. Par exemple, aller d’une application optimisée à commerciale est plus rapide (et moins cher) que d’aller d’une application à son optimisation, ce qui est lui-même plus rapide que d’aller d’un cas particulier à une application générale…

Une bonne méthode peut être meilleure qu’une bonne idée.

La première étape, de l’ordre de l’idée, va du simple « il faut un code pour résoudre <ce problème> » à une supposition pertinente éclairée par des sources (appelées comm dans la figure). Il n’est pas nécessaire que cette idée soit la vôtre, ni qu’elle serve de but rigide pour votre future application. De nombreux projets commencent par « je veux faire B à partir de A » et finissent par une application qui transforme C en D.

Malgré tout, il faut passer à l’étape suivante : l’étape des équations. Cette étape, même si elle n’implique pas forcément de réelles équations, peut être vue comme « nous avons les moyens de résoudre le problème… sur le papier ». Pendant cette première phase de recherche et développement (R&D sur la figure), il y a en réalité peu de chose que nous pouvons faire – à moins que vous ne soyez prêt a investir un très important budget sur une période qui se compte en années. Ce que nous pouvons faire de mieux est de vous conseiller des noms, que vous connaissez sûrement déjà d’après vos propres recherches (comm).

Passer du papier à la réalité…

Dans cette seconde étape, du papier à un cas concret, nous pouvons vous fournir une estimation de ce qui doit être fait, en tenant compte de vos besoins matériels, et de l’intervalle de temps pour la réalisation. Bien sur, en fonction de l’application, nous pouvons même commencer à travailler avec vous à cette étape. Il s’agit toujours d’un processus long et d’un investissement important, mais nous pouvons prendre des raccourcis, et même écourter les étapes suivantes.

Ce passage à un cas concret est déterminant parce qu’il va orienter le projet dans son ensemble. C’est là que le fait d’utiliser des méthodes générales, documentées, et prouvées va payer le plus. Supposons que vous ayez un long script écrit en Python/Matlab/R, faisant appel à d’obscures mathématiques, pour résoudre votre problème. Il y a toutes les chances pour que votre application finale reste un long script, à moins qu’une documentation complète (et détaillée) ne soit fournie. Ce genre d’application a tendance à disparaître dès que son auteur ne la maintient plus. Pour faire simple, l’effort nécessaire pour réinterpréter et comprendre le code original est plus important que celui de recommencer tout depuis le début.

De résoudre votre problème à résoudre celui des autres.

C’est pour aller d’un cas concret fonctionnel à une application, c’est-à-dire un cas général, que vos idées et vos méthodes initiales vont s’avérer payantes. Dans un cas idéal, ce processus ne devrait correspondre qu’à quelques ajustements de votre code pour s’adapter à de plus amples spécifications. Malheureusement, de façon plus réaliste, il vous faudra souvent revenir au stade des équations, et perdre un temps précieux à corriger des problèmes passes inaperçus à l’étape précédente. Avoir un panel d’utilisateurs d’horizons diverses et avec des problèmes différents va nous permettre de concevoir une application à succès.

c’est aussi à ce moment qu’un « business model » devrait être choisi, et ce choix aura des conséquences sur la future application (un descriptif concit de differents business models est donné plus bas).

Une application performante est la plus rapide à faire le plus, en utilisant le moins de ressources.

Quand l’étape de l’application est atteinte, le chemin est loin d’être fini. A présent l’application peut répondre à vos problèmes et à ceux des autres, mais elle doit encore pouvoir le faire de façon efficace. Cela ne veut pas forcément dire que votre application doit être la plus rapide – bien que cela puisse aider – mais qu’elle doit être :

  1. Conviviale : si un utilisateur doit passer plusieurs mois simplement pour apprendre à effectuer les tâches les plus basiques avec votre application, cela veut dire qu’il va probablement l’abandonner et en choisir une plus facile. Dans le cas ou votre application se destinerait à une audience très spécialisée, cela veut dire aussi que l’utilisation devra être simplifie aux termes les plus acceptés par cette communauté.
  2. Attrayante : c’est un point qui est souvent laissé de côté, mais avoir une interface agréable pour votre application – si possible une interface graphique (IG) est toujours meilleur que de devoir laisser l’utilisateur remplir à la main des colonnes de données dans un format abscons.
  3. Rapide : si l’application met plusieurs semaines a produire un résultat que d’autres applications peuvent obtenir en quelques jours, elle sera délaissée, même si elle apporte de précieuses fonctionnalités. Cela implique d’être à jour avec les dernières optimisations matérielles et logicielles, au maximum de leurs capacités.
  4. Portable : si votre application ne peut être utilisée que par un matériel fait-main que seuls quelques laboratoires dans le monde possèdent, aucun utilisateur autre que les membres de ces laboratoires ne seront intéressés. C’est aussi vrai pour les dépendances logicielles, si votre application dépend de bibliothèques informatiques, ces dernières doivent être fiables et régulièrement maintenues.

A OVHPA – High Performance Applications, nous avons l’expérience dans la conception d’interface pour des systèmes d’une dimension allant du super-ordinateur jusqu’au microcontrôleur, et allant des scripts de soumission spécialisés pour les premiers jusqu’aux codes optimisés pour une faible taille pour les seconds. Mais aussi des IGs 3D pour les ordinateurs et des afficheurs simples pour les technologies embarquées. Voir la page Interfaces pour plus de détails.

Nous avons aussi beaucoup d’expérience dans l’optimisation de programmes ciblant les systèmes multi-noeuds, multi-cores, et multi-GPUs. Ce qui est bénéfique pour les applications visant des tailles du super-ordinateur jusqu’aux ordinateurs simples (et même parfois incluant l’embarqué). Les systèmes plus petits ont généralement plutôt besoin de sécurité et de contrôle de taille de code (pour l’embarqué, l’internet des objets et les microcontrôleurs). Voir la page Programming pour plus de détails.

Quand le niveau de l’application optimisée est atteint, le travail est presque fini… enfin c’est ce que nous aimerions vous dire. Mais il reste à s’occuper de nombreux problèmes gênants.

Même si vous avez déjà choisi votre business model (voir plus bas pour des exemples), nous devons nous assurer que votre application convient à ce modèle. Par exemple la licence choisie pour l’application doit refléter tous les codes tiers que votre application peut utiliser. Il y a en effet de nombreuses tracasseries légales qui vous attendent, et si nous pouvons vous aider avec certaines d’entre elles, vous devez savoir qu’a un moment il vous faudra peut-être requérir l’aide de professionnels du droit. Ils seront à même de vous fournir les documents nécessaires comme les conditions d’utilisation, avertissement, termes de contrat de service et autres qui devraient vous éviter d’être poursuivit ou mis en faillite, ce qui compense généralement leur coût initial. Nous pourrons au moins vous preparer aux questions qu’ils vous poseront, ou nous pouvons vous diriger vers ces services professionnels (auxquels nous ne sommes pas affiliés), au moins au Japon.

A ce point vous devriez être l’heureux propriétaire d’une sympathique application dont vous allez pouvoir profiter et faire profiter vos utilisateurs pendant longtemps, toutes nos félicitations ! Cela veut dire aussi que ce sera la fin de notre collaboration. Souvenez-vous de nous quand vous aurez atteint le succès !


Le processus de création d’une application.


De nombreuses très bonnes application échouent a cause d’un business model mal choisi.

Même avec une conception efficace et performante, le choix d’un business model approprié pour une application est critique pour son avenir. Il existe de nombreuses possibilités, en fonction de la taille et de la capacité de maintenance de la compagnie mère de l’application. Voici quelques exemples parmi les plus populaires :

  • Une application commerciale et propriétaires (dite closed-source) est le modèle qui vient naturellement à l’esprit, car il est celui que les grands éditeurs de logiciel ont historiquement choisi pour leurs produits. C’est un modèle qui est durable seulement si une équipe est dédiée au support de l’application pour de nombreuses années. De plus des développeurs fiables doivent aussi être assignés à l’évolution du logiciel de l’application en fonction du changement de la demande et de la modernisation du matériel. C’est un des modèles les moins rentables pour une petite à moyenne entreprise, en particulier si elle ne dispose pas d’un service informatique dédié.
  • Une source distribuée sous un modèle commercial est souvent choisi par les moyennes entreprises. Dans ce cas, tout ou partie du code source de l’application est mis à disposition du client après payement. L’avantage principal est qu’il diminue sur l’entreprise la pression de posséder une grande équipe dédiée au support. Certains utilisateurs peuvent notamment adapter le code de votre application eux-mêmes et laisser la communauté d’utilisateurs profiter de leurs additions. Ceci est mis en œuvre dans la licence de distribution qui va souvent exhorter les utilisateurs à rendre publique leurs modifications. Malheureusement, le cout associé à l’intégration periodique de ces nouvelles parties de code, quand elles sont nécessaires, tout en fournissant un support constant de l’application est souvent trop important pour certaines entreprises.
  • Une application gratuite et opensource avec un support payant est le modèle de choix de petites (et moyennes) entreprises. En revanche ce modèle est très dépendant de la capacité à réunir une communauté autour de l’application. Dans ce cas, seul une équipe de support limitée à l’usage commercial est nécessaire. Les bénéfices pour le développement de l’application sont les mêmes que dans les modèles de type opensource.
  • Un modèle opensource / closed-source avec respectivement une partie logicielle gratuite et une partie payante, est aussi possible. Dans ce cas, les capacités des applications payantes et gratuites doivent être choisies avec beaucoup de précautions. C’est un choix difficile : si l’application gratuite propose trop de fonctionnalités, les utilisateurs ne trouveront aucun intérêt à acheter la partie payante ; à l’inverse, si la partie gratuite n’est pas assez attrayante, il n’y aura pas d’engouement pour la partie payante non plus. Dans ce modèle, la partie maintenance est grandement simplifiée, car les développements les plus intéressants sur la version gratuite peuvent être simplement intégrés à la partie payante.
  • Finalement un modèle de distribution opensource et gratuit est aussi possible. Dans ce modèle la rentabilité est souvent déportée à d’autres aspects de l’application. Elle peut venir de la publicité (par exemple pour une application mobile) ou d’une vente physique, dans le cas où l’application est intégrée à un matériel spécifique. Les solutions basées sur les donations ou la charité, ainsi que le financement participatif sont de plus en plus populaires pour les très petites équipes voire les équipes composées d’une seule personne. N’oublions pas aussi le financement public ou par subventions gouvernementales, qui peuvent d’ailleurs dans certains cas proscrire la prise d’intérêt pour les applications qu’elles ont subventionnées.

Le choix vous appartient – bien que nous seront évidemment là pour vous conseiller – rappelez vous seulement que, quel que soit le business model que vous aurez choisi, il vous sera toujours possible d’aller vers un code plus ouvert et plus de gratuité ! Aller dans l’autre sens, par contre, sera aussi aisé que de nager à contre-courant… sur les chutes du Niagara.

(C) OVHPA 2020, High Performance Applications.

All rights reserved.

Report problems to webmaster.