Qt : distribuer ses applications

La distribution d’une application est une étape importante de la vie d’une application, elle nécessite d’être pensée très tôt dans la conception. Cette série d’articles présente les différents aspects et étapes depuis la conception jusqu’à la distribution.

Parmi les problématiques qui devront être gérées se trouvent la gestion des licences, le mode de compilation, les licences d’exploitation, l’empaquetage lui-même, la façon de distribuer l’application, sa mise à jour, la vente sur un Store, la signature numérique du paquet de distribution et la gestion des crashs de l’application pour un déboguage facilité.

Cela fait un grand nombre de sujets que je tâcherai de traiter dans une série d’articles. Celui-ci est une introduction qui vous permettra de commencer à vous poser certaines questions auxquelles vous n’avez pas encore pensé dans votre conception.

Les articles suivant aborderont chacun en détail un des sujets énoncés plus haut.

La licence de l’application

L’élément le plus déterminant, dans cette phase de distribution, est la licence d’utilisation que vous allez accorder à vos utilisateurs. En l’absence de licence vous ne pourrez pas régler les litiges qui pourraient vous opposer à vos utilisateurs, fournisseurs et concurrents.

Prenons plusieurs exemples pour vous aider à envisager les difficultés que vous pourriez avoir à gérer :

  • Vous donnez votre application compilée en téléchargement, sans les sources. Un de vos clients l’utilise et celle-ci cause des dommages importants sur un système stratégique (blocage, saturation de mémoire, perte de données, trou de sécurité, etc). En l’absence de licence, les avocats de votre client pourront éventuellement vous reprocher le fait que votre programme a causé une perte d’exploitation ou de données à votre client. Cela pourrait vous coûter fort cher. Vous devriez donc au moins prévoir une licence qui vous décharge de toute responsabilité quant à l’usage du logiciel… et avoir une assurance RC Pro !
  • Vous utilisez des bibliothèques tierces et des composants sous licence qui ne vous autorisent pas à commercialiser votre application (GPL, commerciale) ou qui vous oblige à verser des royautés ou encore à livrer le code source de votre logiciel (GPL et dérivées). Si quelqu’un s’en rend compte, il vous faudra corriger le problème dans un délai très court, livrer éventuellement votre code source ou régler des royautés pour un montant important, et non prévu.
  • Certains composants logiciels ne peuvent pas être utilisés pour des produits commerciaux, mais uniquement pour un usage individuel. Si vous êtes repéré, vous devrez incessamment remplacer le composant en question, ou le réécrire vous-même.

Ce ne sont que quelques exemples qui illustrent l’importance de réfléchir à la question des licences bien avant la conception de votre application.

En ce qui concerne Qt, vous devrez prendre aussi une décision de cette nature car, si en version commerciale vous pouvez faire ce que vous voulez avec l’application, en version open source les licences des composants sont LGPL et GPL dans différentes versions. Vous devrez, dans le meilleur des cas livrer le code source de vos applications si on vous en fait la demande.

Ce raisonnement s’applique à tous les composants logiciels que vous utiliserez et qui ne sont pas inclus dans Qt (bibliothèques tierces). De plus, il s’applique aussi au compilateur et à l’environnement de développement que vous utilisez. Si vous utilisez MinGW ou MSVC sous Windows, clang et le SDK OS.X vous n’aurez pas de difficulté pour déployer vos applications, les licences sont très permissives. En revanche, si vous vendez votre application sous GNU/Linux vous devrez prêter une attention particulière à tous les composants liés à votre application (statiquement comme dynamiquement), y compris la libc, car de nombreuses bibliothèques utilisées dans les distributions GNU/Linux, à commencer par le noyau lui-même sont sous licence GPL ou dérivées.

Notez que certaines bibliothèques de Qt intègrent des composants sous licence, celles-ci sont précisées dans la documentation de Qt.

Les points de conception importants

Au delà de la question des licences, vous devrez envisager plusieurs points importants dès la phase de conception. Ceux-ci vous obligeront à faire certains choix lors de la programmation de votre application :

  • comment allez-vous mettre votre application à jour ? Le gérez-vous dans l’application elle-même ou le faites-vous avec un programme externe ? Si oui, quelle est sa licence d’exploitation ?
  • Comment allez-vous gérer les dysfonctionnements de votre application ? Souhaitez-vous recevoir automatiquement les rapports d’erreur ou demander à l’utilisateur de vous les envoyer ? Vous devrez dans tous les cas utiliser des composants tierce partie car rien n’est prévu dans Qt. Vous devrez donc vérifier la licence du composant et informer votre utilisateur dans la licence d’exploitation de votre application sur la manière dont vous gérez les informations personnelles contenues dans les rapports de crash.
  • Quel système de gestion de données utiliserez-vous ? Quelle est sa licence d’utilisation ?
  • Concevez-vous et codez-vous vous-même tous vos algorithmes ? N’y a-t-il pas des algorithmes que vous codez mais qui sont protégés par un brevet ?
  • Les formats d’image que vous utilisez sont-ils libres de droit ou protégés ? Utilisez-vous le format JPEG par exemple ?
  • Les images que vous utilisez sont-elles libre de droit ? La licence vous autorise-t-elle à les utiliser dans une application commerciale ?

Ce ne sont que quelques exemples qui trouveront tous des solutions mais qui auront des conséquences sur votre conception. Si vous n’y prenez garde, vous aurez à revenir parfois de manière importante sur votre conception, ce qui sera coûteux.

Parfois les problèmes de licence peuvent trouver une solution simple en laissant l’utilisateur acquérir et installer le composant manquant. Cela impliquera une diminution du confort d’utilisation de votre application et de sa maintenance pour votre client.

D’une manière générale, l’absence de licence pour un composant que vous utilisez ou pour vos propres composants et applications est très dangereuse. Elle induit une responsabilité totale ou un flou juridique qui pourra être tranché en votre défaveur. Pour éviter les ennuis, si vous souhaitez utiliser un composant qui n’a pas de licence (bibliothèque, image, son, icône, etc), demandez une autorisation écrite au concepteur en précisant les conditions d’utilisation prévues et la durée de cet accord.

N’hésitez pas à demander conseil à votre avocat si les enjeux sont importants, de nombreux cabinets se sont spécialisés dans la propriété intellectuelle et industrielle.

Compilation

Une application ne doit être livrée à ses utilisateurs que sous la forme d’un binaire compilé en mode « Release », et ce pour plusieurs raisons :

  • un binaire en mode « Debug » est beaucoup plus gros et plus difficile à transférer.
  • Il est beaucoup plus lent car il n’utilise aucune optimisation du processeur et qu’il embarque beaucoup de mécanisme liés au déboguage.
  • Il est lié aux bibliothèques système ou SDK en mode « Debug » et il est interdit de publier celles-ci. Par exemple les redistribuables Visual C++ ne peuvent être utilisées qu’en mode « Release ».

Pour le dire simplement, les exécutables liés avec des bibliothèques en mode « Debug » ne peuvent être utilisées que sur des ordinateurs de développement et pour le développement.

Ainsi, il vous faut prévoir une procédure de tests internes avec une version compilée en mode « Debug », et une procédure de tests externes (souvent appelée « beta ») avec des exécutables en mode « Release ». Ces exécutables sont cependant différents de ceux livrés dans la version packagée car vous aurez activé un mode de déboguage qui alimentera des journaux que vous pourrez récupérer en cas de problème.

Ainsi se pose la question de la transmission des rapports d’erreur et journaux. Cette question trouvera techniquement des réponses dans un futur chapitre. En revanche, ce que vous devez prendre en considération dès l’étape de compilation en mode « Release » (tests publics beta ou publication) c’est le versionnement des sources et des fichiers de symboles.

Un exécutable compilé en mode « Release » comporte des optimisations et est allégé des symboles des fonctions qu’il contient. Ainsi, si une erreur se produit à l’exécution, surtout si elle conduit à un plantage de l’application, vous ne saurez pas quel est le nom de la fonction dans laquelle l’erreur s’est produite. Vous n’aurez qu’une adresse mémoire. Pareillement pour la pile d’exécution principale et celles des différents threads.

C’est là qu’intervient le fichier des symboles qui accompagne votre exécutable. Sous MSVC le fichier porte l’extension .pdb et il permet d’établir, grâce à un débogueur, d’établir un lien entre une adresse mémoire et le code source.

C’est pourquoi, à chaque fois que vous publiez une version de votre application, celle-ci doit avoir un numéro de version unique du type major.minor.release.build. Par exemple 2.3.2.1432 indique que l’exécutable est dans sa version 2.3, ce qui correspond à un certain niveau de fonctionnalités, qu’il s’agit de la deuxième série de corrections de bogues et de la 1432è compilation de l’exécutable.

Lorsque vous packagez une application qui va être transmise à une tierce personne pour test ou utilisation en production, vous devez mettre de côté les sources exacts de cette version (dans un dossier 2.3.2.1432 par exemple, ou grâce à un tag SVN), et conserver les fichiers .pdb (ou autre selon le compilateur).

Si vous recevez un rapport d’erreur, vous ressortez les sources et les fichiers .pdb correspondant à la version indiquée par le rapport d’erreur.

Dans le prochain article je traiterai la question de l’installeur lui-même, quelles sont les solutions pour le réaliser et surtout comment réaliser un installeur universel grâce à Qt.

Partagez cet article !

Abonnez-vous à notre newsletter !

Si vous souhaitez être notifié lorsqu'un nouvel article est publié, abonnez-vous à notre newsletter et vous recevrez un email dès qu'un article sera publié.

Articles similaires

Utiliser la technique du ... Le lazy-loading, ou chargement paresseux en français, est une réponse simple à la question simple “pourquoi charger plus de données que nous ne pouvons en afficher ?”.
Qt : distribuer ses appli... La distribution d’une application est une étape importante de la vie d’une application, elle nécessite d’être pensée très tôt dans la conception. Cette série d’articles présente les
Apprendre à développer ... Une de mes activités est la formation professionnelle à la conception et à la programmation d’applications avec Qt. J’envisage aujourd’hui de créer un MOOC payant pour partager
Qt : comment implanter un... Il existe plusieurs façons d’implanter des threads dans son application Qt.  Voici la méthode que je préconise. Partagez cet article ! Abonnez-vous à notre newsletter ! Si
Adopter les flux tirés d... Nous abordons un des points essentiels de l’architecture réseau et applicative efficace et économe : les flux tirés. Partagez cet article ! Abonnez-vous à notre newsletter !
Qt : l’influence du... Lorsqu’on développe une application mutli-plateformes il est important de se poser la question des performances sur les plateformes ciblées. A machine égale, selon le compilateur utilisé les
Livre Maîtrisez Qt 5 ... La seconde édition du livre de Tristan Israël, Maîtrisez Qt 5 – Développement d’applications professionnelles, est parue. Vous pouvez le découvrir sur le site des éditions ENI.
Qt : pourquoi et quand ut... La gestion des threads dans Qt est simple mais elle mérite quelques explications car elle engendre souvent des problèmes conceptuels chez les développeurs peu expérimentés en Qt.
Qt : Traiter une liste de... Pour qu’une interface graphique reste fluide aux yeux de l’utilisateur, le thread qui la gère ne doit jamais être interrompu plus d’une poignée de millisecondes. Or le

Laisser une réponse

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *