1. Hypothèse 1
    1. Hypothèse 1 - Présentation du proof of concept
    2. Hypothèse 1 - Critères 1 : Pendant le développement
      1. Hypothèse 1 - Critère 1.1 : Le temps de développement
      2. Hypothèse 1 - Critère 1.2 : Les limitations des technologies
        1. Hypothèse 1 - Critère 1.2.1 : L’accès aux fonctionnalités
        2. Hypothèse 1 - Critère 1.2.2 : Les limitations esthétiques
    3. Hypothèse 1 - Critères 2 : Après le développement
      1. Hypothèse 1 - Critères 2.1 : Le déploiement
      2. Hypothèse 1 - Critères 2.2 : La maintenance
      3. Hypothèse 1 - Critères 2.3 : La réutilisation
    4. Hypothèse 1 - Critères 3 : Le résultat
      1. Hypothèse 1 - Critères 3.1 : Utilisation du processeur et de la mémoire
        1. Hypothèse 1 - Critère 3.1.1 : Utilisation du processeur
        2. Hypothèse 1 - Critère 3.1.2 : Utilisation de la mémoire
      2. Hypothèse 1 - Critères 3.2 : Temps de réponse moyen
      3. Hypothèse 1 - Critère 3.3 : Le poids de l’exécutable
    5. Hypothèse 1 - Synthèse des critères
    6. Hypothèse 1 - Conclusion
  2. Hypothèse 2
    1. Hypothèse 2 - Présentation du proof of concept
    2. Hypothèse 2 - Critères 1 : Pendant le développement
      1. Hypothèse 2 - Critère 1.1 : Le temps de développement
      2. Hypothèse 2 - Critère 1.2 : Les limitations des technologies
        1. Hypothèse 2 - Critère 1.2.1 : L’accès aux fonctionnalités
        2. Hypothèse 2 - Critère 1.2.2 : Les limitations esthétiques
    3. Hypothèse 2 - Critères 2 : Après le développement
      1. Hypothèse 2 - Critères 2.1 : Le déploiement
      2. Hypothèse 2 - Critères 2.2 : La maintenance
      3. Hypothèse 2 - Critères 2.3 : La réutilisation
    4. Hypothèse 2 - Critères 3 : Le résultat
      1. Hypothèse 2 - Critères 3.1 : Utilisation du processeur et de la mémoire
        1. Hypothèse 2 - Critère 3.1.1 : Utilisation du processeur
        2. Hypothèse 2 - Critère 3.1.2 : Utilisation de la mémoire
      2. Hypothèse 2 - Critères 3.2 : Temps de réponse moyen
      3. Hypothèse 2 - Critère 3.3 : Le poids de l’exécutable
    5. Hypothèse 2 - Synthèse des critères
    6. Hypothèse 2 - Comparatif
    7. Hypothèse 2 - Conclusion
  3. Hypothèse 3
    1. Hypothèse 3 - Présentation du proof of concept
    2. Hypothèse 3 - Critères 1 : Pendant le développement
      1. Hypothèse 3 - Critère 1.1 : Le temps de développement
      2. Hypothèse 3 - Critère 1.2 : Les limitations des technologies
        1. Hypothèse 3 - Critère 1.2.1 : L’accès aux fonctionnalités
        2. Hypothèse 3 - Critère 1.2.2 : Les limitations esthétiques
    3. Hypothèse 3 - Critères 2 : Après le développement
      1. Hypothèse 3 - Critères 2.1 : Le déploiement
      2. Hypothèse 3 - Critères 2.2 : La maintenance
      3. Hypothèse 3 - Critères 2.3 : La réutilisation
    4. Hypothèse 3 - Critères 3 : Le résultat
      1. Hypothèse 3 - Critères 3.1 : Utilisation du processeur et de la mémoire
        1. Hypothèse 3 - Critère 3.1.1 : Utilisation de du processeur
        2. Hypothèse 3 - Critère 3.1.2 : Utilisation de la mémoire
      2. Hypothèse 3 - Critères 3.2 : Temps de réponse moyen
      3. Hypothèse 3 - Critère 3.3 : Le poids de l’exécutable
    5. Hypothèse 3 - Synthèse des critères
    6. Hypothèse 3 - Comparatif
    7. Hypothèse 3 - Conclusion
  4. Hypothèse 4
    1. Hypothèse 4 - Présentation du proof of concept
    2. Hypothèse 4 - Critères 1 : Pendant le développement
      1. Hypothèse 4 - Critère 1.1 : Le temps de développement
      2. Hypothèse 4 - Critère 1.2 : Les limitations des technologies
        1. Hypothèse 4 - Critère 1.2.1 : L’accès aux fonctionnalités
        2. Hypothèse 4 - Critère 1.2.2 : Les limitations esthétiques
    3. Hypothèse 4 - Critères 2 : Après le développement
      1. Hypothèse 4 - Critères 2.1 : Le déploiement
      2. Hypothèse 4 - Critères 2.2 : La maintenance
      3. Hypothèse 4 - Critères 2.3 : La réutilisation
    4. Hypothèse 4 - Critères 3 : Le résultat
      1. Hypothèse 4 - Critères 3.1 : Utilisation du processeur et de la mémoire
        1. Hypothèse 4 - Critère 3.1.1 : Utilisation du processeur
        2. Hypothèse 4 - Critère 3.1.2 : Utilisation de la mémoire
      2. Hypothèse 4 - Critères 3.2 : Temps de réponse moyen
      3. Hypothèse 4 - Critère 3.3 : Le poids de l’exécutable
    5. Hypothèse 4 - Synthèse des critères
    6. Hypothèse 4 - Comparatif
    7. Hypothèse 4 - Conclusion
  5. Hypothèse 5
    1. Hypothèse 5 - Présentation du proof of concept
    2. Hypothèse 5 - Critères 1 : Pendant le développement
      1. Hypothèse 5 - Critère 1.1 : Le temps de développement
      2. Hypothèse 5 - Critère 1.2 : Les limitations des technologies
        1. Hypothèse 5 - Critère 1.2.1 : L’accès aux fonctionnalités
        2. Hypothèse 5 - Critère 1.2.2 : Les limitations esthétiques
    3. Hypothèse 5 - Critères 2 : Après le développement
      1. Hypothèse 5 - Critères 2.1 : Le déploiement
      2. Hypothèse 5 - Critères 2.2 : La maintenance
      3. Hypothèse 5 - Critères 2.3 : La réutilisation
    4. Hypothèse 5 - Critères 3 : Le résultat
      1. Hypothèse 5 - Critères 3.1 : Utilisation du processeur et de la mémoire
        1. Hypothèse 5 - Critère 3.1.1 : Utilisation du processeur
        2. Hypothèse 5 - Critère 3.1.2 : Utilisation de la mémoire
      2. Hypothèse 5 - Critères 3.2 : Temps de réponse moyen
      3. Hypothèse 5 - Critère 3.3 : Le poids de l’exécutable
    5. Hypothèse 5 - Synthèse des critères
    6. Hypothèse 5 - Comparatif
    7. Hypothèse 5 - Conclusion

Hypothèse 1

Une application native pour chaque appareil cible.

Hypothèse 1 - Présentation du proof of concept

Cette hypothèse consiste à penser que développer une application native pour chaque appareil cible est une solution efficace d’architecture applicative.

Pour tenter de le démontrer, nous allons réaliser une application dans chaque langage natif de nos cibles, à savoir :

Note : Les langages séparés par une barre oblique représentent à gauche le langage utilisé pour le proof of concept et à droite le langage équivalent ou transpilé. Quand un langage est suivi de “avec X”, on désigne le framework utilisé.

Hypothèse 1 - Critères 1 : Pendant le développement

Hypothèse 1 - Critère 1.1 : Le temps de développement

Pour ces cinq applications différentes dont le code ne peut être partagé (même entre Mac et iOS qui partagent le même langage, car les spécificités sont trop grandes pour que la réutilisation du code puisse avoir un véritable impact) les temps de développement sont relativement similaires.

Système d’exploitation Langage Nature Nombre estimé d’heures
Linux Rust Natif 41
Windows C# Natif 37
macOS Swift Natif 33
Android Kotlin Natif 29
iOS Swift Natif 32
Moyenne - - 34
Total - - 172

Là où la moyenne est fournie à but indicatif, c’est dans le total que nous sommes intéressés. En effet, développer cinq fois une application similaire a un impact très important sur le temps total d’un projet.

Hypothèse 1 - Critère 1.2 : Les limitations des technologies

Hypothèse 1 - Critère 1.2.1 : L’accès aux fonctionnalités

Ces cinq applications ont donc comme principe d’être chacune native et donc par définition d’avoir un accès à toutes les fonctionnalités offertes par le système d’exploitation cible, et cela sans charge supplémentaire de travail.
Certains systèmes d’exploitation ajoutent d’ailleurs à cela une couche de sécurité supplémentaire comme Android qui demande la permission à l’utilisateur avant d’accéder à des fonctionnalités natives.

Parmi ces fonctionnalités, on retrouve fréquemment :

  • Le stockage de fichiers
  • L’accès à Internet
  • L’accès aux informations de l’appareil (Marque, numéro de téléphone, composants etc.)
  • L’accès aux périphériques de l’appareil (caméra, microphone, GPS etc.)

Afin de juger des libertés d’accès de tous ces logiciels, nous leur donnerons une note arbitraire qui s’étend de 0 (aucun accès aux fonctionnalités natives) à 5 (libre accès à toutes les fonctionnalités).

Système d’exploitation Langage Nature Note sur 5
Linux Rust Natif 5.0
Windows C# Natif 5.0
macOS Swift Natif 5.0
Android Kotlin Natif 4.5
iOS Swift Natif 4.5
Moyenne     4.8

Sans surprise, chaque application reçoit une note proche de maximale étant donné le degré de liberté offert par les applications natives.
Il est à noter que si Android et iOS ont tous deux des notes légèrement plus basses, c’est en raison de la requête faite à l’utilisateur d’accéder aux fonctionnalités. Quand bien même cette notion est très bénéfique d’un point de vue de la sécurité informatique, nous jugeons ici le degré de liberté d’accès exclusivement.

Hypothèse 1 - Critère 1.2.2 : Les limitations esthétiques

Jugeons maintenant de la liberté offerte par ces applications natives de créer une interface esthétique, unique et intuitive.

Système d’exploitation Langage Nature Note sur 5
Linux Rust Natif 3.0
Windows C# Natif 3.0
macOS Swift Natif 2.5
Android Kotlin Natif 2.5
iOS Swift Natif 2.5
Moyenne     2.7

Linux et Windows proposent tous deux un bon contrôle sur les fenêtres d’application mais leur apparence est limitée en possibilité. Même s’il est possible d’arriver à des résultats convenables, il est difficile de différencier une application d’une autre uniquement par l’aspect esthétique.

Pour les systèmes d’exploitation d’Apple (macOS et iOS) ainsi qu’Android, quand bien même leur proposition d’affichage est d’un naturel très esthétique, le contrôle permis est très restreint et chaque application native aura tendance à se ressembler sans un effort conséquent apporté par les concepteurs de l’application.

Hypothèse 1 - Critères 2 : Après le développement

Hypothèse 1 - Critères 2.1 : Le déploiement

Nous allons réitérer la méthode de la notation afin de juger la facilité et la rapidité d’un déploiement sur ces différents systèmes d’exploitation.

Système d’exploitation Note sur 5
Linux 5.0
Windows 4.0
macOS 5.0
Android 5.0
iOS 2.0
Moyenne 4.2

Dans le cas de Linux, macOS, Windows et Android, il est possible de créer des fichiers uniques qui servent de “containers” à l’application et qui, une fois exécutés, installent directement le logiciel.

Linux offre une grande flexibilité ainsi que de nombreux outils pour faciliter le déploiement (Ansible, Rudder etc.). macOS et Android, tournant tous deux sous un noyau Linux, profitent d’une flexibilité similaire.

Dans le cas de Windows, la présence d’un installeur obligatoire et les verrous mis sur les procédures d’installation peuvent parfois rendre la tâche légèrement plus compliquée.

Enfin, sur iOS, afin de déployer une application, il est impératif de passer par un store (marché d’application), même privé, afin de rendre disponible le résultat. Chaque applicatif passant sur le store sera aussi testé par des employés d’Apple, ajoutant une charge temporelle supplémentaire non négligeable.

Hypothèse 1 - Critères 2.2 : La maintenance

La maintenance peut être perçue comme un second déploiement. Nous devons juger de la vitesse et de la facilité de l’intervention en cas de mise à jour.

Système d’exploitation Note sur 5
Linux 4.5
Windows 4.5
macOS 4.5
Android 5.0
iOS 3.5
Moyenne 4.4

Chaque système d’exploitation est très réceptif quant à la mise à jour des applications natives. Android et iOS proposent des systèmes intégrés dans leurs stores là où les mises à jour sur les systèmes d’exploitation bureau doivent être implémentées manuellement.

Cependant, iOS souffre des mêmes problématiques de phase de test, bridant de ce fait la réactivité d’un déploiement de correctif.

Au delà ce cela, chaque logiciel doit faire l’objet d’une maintenance particulière et possède son potentiel lot de problème à corriger. Cette multiplication des sources de problèmes est délicate et rend la maintenance complexe.

Hypothèse 1 - Critères 2.3 : La réutilisation

Voyons maintenant à quel point le code source utilisé dans ce projet pourrait être utilisé à nouveau dans un autre projet.
Voici un aperçu de la manière dont le code pourrait être réutilisé au maximum:

graph LR subgraph Projet Actuel L1[Linux] W1[Windows] M1[macOS] A1[Android] I1[iOS] end subgraph Prochain Projet L2[Linux] W2[Windows] M2[macOS] I2[iOS] A2[Android] end Rust((Rust)) C#((C#)) SwiftB((Swift Bureau)) SwiftM((Swift Mobile)) Kotlin((Kotlin)) L1 --- Rust --> L2 W1 --- C# --> W2 M1 --- SwiftB --> M2 M1 -.- SwiftB .-> I2 A1 --- Kotlin --> A2 I1 --- SwiftM --> I2 I1 -.- SwiftM .-> M2

Comme exprimé précédemment, même si les applications macOS et iOS sont développées dans les mêmes langages, tout le code ne peut pas être transposé de l’un à l’autre, seules quelques fonctionnalités très communes et qui ne touchent pas à l’affichage des données le peuvent.

Nous pouvons voir dans ce cas que si l’on quantifie les liens qu’il est possible de faire entre les applications (une flèche vaut 1 point, et 0.5 point pour les flèches partielles), nous obtenons ce tableau :

Système d’exploitation Langage Partageable sur X projets
Linux Rust 1.0
Windows C# 1.0
macOS Swift 1.5
Android Kotlin 1.0
iOS Swift 1.5
Moyenne   1.2

Attention, dans ce cas précis, les valeurs ne sont pas des notes sur 5 mais bien des ratios que nous pourront comparer plus tard. Actuellement, la moyenne de 1.2 représente un taux de partage de code assez faible puisque le code d’un logiciel n’est réutilisable que pour un logiciel d’un langage identique.

Afin de donner un pourcentage de réutilisation du code, nous pouvons diviser la moyenne obtenue par le nombre de projets. Ce faisant nous obtenons un indice de 24% de code réutilisable.

Hypothèse 1 - Critères 3 : Le résultat

Hypothèse 1 - Critères 3.1 : Utilisation du processeur et de la mémoire

Nous allons mesurer les utilisations du processeur et de la mémoire dans ces cinq applications natives, à différents instants du cycle de l’utilisation du proof of concept.
Ces instants sont, rappelons-le :

  • A : Ouverture de l’application et arrivé sur la liste des articles
  • B : Tri des articles
  • C : Ouverture de la page d’un utilisateur
  • D : Connexion à l’application
  • E : Publication d’un article
  • F : Suppression d’un article
Hypothèse 1 - Critère 3.1.1 : Utilisation du processeur
  Linux Windows macOS Android iOS Moyenne
A 6.32 7.15 7.19 6.47 7.26 6.99
B 6.18 8.03 8.15 7.66 8.76 7.76
C 6.42 6.90 6.95 6.45 7.12 6.77
D 5.67 5.88 6.21 5.81 6.27 5.97
E 5.69 6.08 6.09 5.86 6.74 6.09
F 4.77 5.34 5.47 5.26 5.77 5.32
Moyenne 5.84 6.56 6.68 6.25 6.99 6.48

Nous pouvons voir qu’en général, aucune des applications n’atteint les huit pourcents de l’utilisation du processeur ce qui est signe d’une consommation assez basse.
Nous pouvons aussi remarquer que l’action la plus coûteuse est la recherche parmi la liste intégrale des articles, ce qui semble tout à fait cohérent.

En moyenne, pour ces logiciels, nous nous situons aux alentours de 6.48% d’utilisation du processeur.

Hypothèse 1 - Critère 3.1.2 : Utilisation de la mémoire

Sur les mêmes six actions, regardons l’utilisation de la mémoire vive (en MB).

  Linux Windows macOS Android iOS Moyenne
A 15.95 18.18 18.49 17.20 20.88 18.14
B 13.36 14.20 14.81 14.04 15.41 14.36
C 13.67 14.80 14.98 14.29 15.01 14.55
D 13.19 14.62 15.72 13.42 15.15 14.42
E 12.31 13.09 14.09 12.52 14.55 13.31
F 10.51 11.12 11.63 11.09 12.40 11.35
Moyenne 13.17 14.34 14.86 13.76 15.66 14.36

Là encore, l’utilisation de la mémoire est répartie assez naturellement sans anomalies à relever. Notons tout de même que c’est le démarrage qui est le plus coûteux en raison des nombreuses informations importantes à initialiser au qui ne servent plus lors de l’utilisation.

Nous retenons donc la valeur moyenne de 14.36MB d’utilisation de la mémoire.

Hypothèse 1 - Critères 3.2 : Temps de réponse moyen

Comme expliqué dans l’introduction, le temps de réponse d’une application est important et donne à l’utilisateur la sensation d’un logiciel puissant et efficace (ou à l’inverse d’un logiciel lent et désagréable d’utilisation)

En utilisant les mêmes actions que pour le critère précédent, regardons les temps de réponse moyens de celles-ci.
Nous regarderons aussi deux autres données lors de l’affichage premier de la fenêtre :

  • G : First Contentful Paint ou premier affichage de contenu (temps avant que les premières données n’arrivent à l’écran)
  • H : Time to Interactive ou durée avant interaction possible. (temps avant de pouvoir avoir la main sur le logiciel)

Les valeurs sont exprimées en secondes

  Linux Windows macOS Android iOS Moyenne
A 1.86 2.05 2.95 2.02 2.15 2.21
B 0.71 0.80 0.79 0.79 0.80 0.78
C 0.09 0.10 0.10 0.11 0.12 0.10
D 0.12 0.17 0.19 0.15 0.19 0.16
E 0.71 0.77 0.74 0.73 0.78 0.75
F 0.07 0.08 0.09 0.11 0.09 0.09
G 0.71 0.80 0.81 0.74 0.93 0.81
H 0.88 1.02 1.00 0.96 1.10 0.99
Moyenne 0.64 0.72 0.83 0.70 0.77 0.74

Nous observons donc que le temps de réactivité d’une application native se trouve généralement sous la seconde, en moyenne à 0.74s pour être précis.

Hypothèse 1 - Critère 3.3 : Le poids de l’exécutable

Pour estimer l’impact du poids de l’exécutable final nous allons juger du poids moyen.

Système d’exploitation Langage Nature Poids (en MB)
Linux Rust Natif 6.24
Windows C# Natif 7.59
macOS Swift Natif 7.95
Android Kotlin Natif 10.75
iOS Swift Natif 11.20
Moyenne - - 8.75
Total - - 43.73

Chaque logiciel a un poids assez similaire aux autres, ont détecte cependant des poids plus élevés pour les applications mobiles, qui ont un poids souvent supérieur aux logiciels de bureau. On estime en 2017 le poids moyen d’une application à 15MB sur Android et 38MB sur iOS1

Hypothèse 1 - Synthèse des critères

  • Critères 1 (Avant le développement)
    • Critère 1.1 (Temps de développement) : 172h
    • Critère 1.2.1 (Limitations Techniques) : 4.8 pts
    • Critère 1.2.2 (Limitations Esthétiques) : 2.7 pts
  • Critères 2 (Après le développement)
    • Critère 2.1 (Déploiement) : 4.2 pts
    • Critère 2.2 (Maintenance) : 4.4 pts
    • Critère 2.3 (Réutilisation) : 24%
  • Critères 3 (Résultat)
    • Critère 3.1.1 (Benchmark processeur) : 6.48%
    • Critère 3.1.2 (Benchmark mémoire) : 14.36MB
    • Critère 3.2 (Temps de réponse) : 0.74s
    • Critère 3.3 (Poids total) : 8.75MB

Graphique Hypothèse 1

Hypothèse 1 - Conclusion

En observant les résultats de notre analyse, il est aisé d’observer que cette hypothèse possède de nombreuses qualités, notamment en ce qui concerne les performances.
Néanmoins, nous pouvons aussi remarquer deux critères très coûteux qui sont négligés tels que le temps de développement et la capacité de réutilisation du code source.

Cette hypothèse, part du principe qu’une application native développée avec un système d’exploitation précis en tête est forcément plus performante. Et même si cette affirmation s’avère être vraie, cela représente tout de même une très grande quantité de logiciels à développer, chacun avec son propre langage.
Malgré les avantages qu’offrent les applications natives, il est difficilement envisageable de les utiliser dans un cas où l’on souhaite viser un grand nombre de cibles différentes.

D’autre part, étant donné que ces applications n’ont pas de langages en commun (exception faite de macOS et iOS avec Swift), il est très difficile de partager du code et donc d’accélérer le développement des applications futures.
Là encore le problème s’axe de manière identique car il n’est pas important si l’on souhaite viser un petit nombre d’appareils cible.

Nous allons essayer de mitiger ces problèmes avec la prochaine hypothèse.

Hypothèse 2

Séparer les cibles en deux grands groupes, à savoir “Logiciels Bureaux” et “Applications Mobiles” et faire deux applications natives différentes pour ces groupes.

Hypothèse 2 - Présentation du proof of concept

Cette hypothèse reprend en partie le principe de l’hypothèse précédente qui décrivait les applications natives comme étant les alternatives les plus puissantes disponibles. Cependant, pour pallier le nombre conséquent d’applications à développer, ce nombre est réduit au plus faible possible en cherchant des technologies capables de créer des logiciels pour les interfaces bureau et d’autres pour les interfaces mobiles.

Conserver les avantages des applications natives en limitant grandement le nombre de logiciels semble être une approche prometteuse et pour le démontrer nous réaliserons une application pour chaque groupe d’appareils cibles :

Hypothèse 2 - Critères 1 : Pendant le développement

Hypothèse 2 - Critère 1.1 : Le temps de développement

Pour ces deux applications voici les temps de développement :

Groupe de cibles Langage Nature Nombre estimé d’heures
Logiciel Bureau Kotlin Natif 23
Logiciel Mobile Dart Natif 35
Moyenne - - 29
Total - - 58

Le temps de développement total de ce projet s’élève donc à 58 heures. C’est naturellement bien moins élevé que l’hypothèse précédente et c’est un critère non négligeable.

Hypothèse 2 - Critère 1.2 : Les limitations des technologies

Hypothèse 2 - Critère 1.2.1 : L’accès aux fonctionnalités

Comme pour l’hypothèse précédente, nous allons juger les deux applications sur la liberté qu’elles offrent aux développeurs d’accéder aux fonctionnalités du système d’exploitation cible.

Groupe de cibles Langage Nature Note sur 5
Logiciel Bureau Kotlin Natif 5.0
Logiciel Mobile Dart Natif 4.5
Moyenne     4.8

Comme nous pouvons le constater, de la même manière que l’hypothèse précédente, les applications natives n’ont que très peu de limitations quand aux fonctionnalités auxquelles elles ont accès.
Seul l’application mobile possède un léger inconvénient encore une fois, celui de devoir demander la permission à l’utilisateur pour accéder à certains mécanismes.

Hypothèse 2 - Critère 1.2.2 : Les limitations esthétiques

En ce qui concerne les limitations des possibilités esthétiques, nous pouvons nous attendre à des résultats similaires à l’hypothèse précédente.

Groupe de cibles Langage Nature Note sur 5
Logiciel Bureau Kotlin Natif 2.0
Logiciel Mobile Dart Natif 2.5
Moyenne     2.3

Nous retrouvons en effet la même note en ce qui concerne la partie mobile mais une note légèrement plus basse pour la partie bureau.
Cela s’explique par la différence de l’approche de l’interface des logiciels bureau multiplateforme là où l’approche des logiciels mobiles sont très similaires.

Android et iOS possèdent tous deux une charte graphique différente mais comparable, ce qui fait que proposer des composants graphiques (Boutons, champs de textes, tableaux) dans deux apparences différentes est possible sans trop de problèmes.

À l’inverse, il n’existe aucune charte graphique liant Linux, Windows et macOS. C’est cette absence de lien qui rend l’affichage d’une interface graphique assez limité en possibilité.

Hypothèse 2 - Critères 2 : Après le développement

Hypothèse 2 - Critères 2.1 : Le déploiement

Du point de vue de la facilité de déploiement, on peut s’attendre à des résultats similaires. Ici nous noteront chaque système d’exploitation à part car, contrairement au langage de développement qui est le même pour chaque cible d’un groupe, le déploiement doit se faire indépendamment.

Système d’exploitation Note sur 5
Linux 4.5
Windows 4.5
macOS 4.5
Android 5.0
iOS 2.0
Moyenne 4.1

Ici pour les cibles mobiles, le résultat est le même que pour l’hypothèse précédente car la méthode de déploiement est exactement la même.
Pour les cibles bureau, la seule contrainte notable est la présence obligatoire de Java sur les machines. Java est un logiciel qui est déjà présent sur un grand nombre d’appareils d’utilisateurs et dans le cas échéant, l’installation de celui-ci est à la fois simple et rapide.

Hypothèse 2 - Critères 2.2 : La maintenance

La maintenance de ces deux applications est similaire à ce qui a été mesuré précédemment.

Système d’exploitation Note sur 5
Linux 4.5
Windows 4.5
macOS 4.5
Android 5.0
iOS 3.5
Moyenne 4.4

Ici, c’est encore les cibles mobiles qui ont l’ascendant sur les cibles fixes en raison de la présence d’un store capable de mettre automatiquement les applications à jour sur la machine des utilisateurs.

Hypothèse 2 - Critères 2.3 : La réutilisation

Observons maintenant la capacité du code source à être réutilisé pour un projet aux technologies similaires.

graph LR subgraph Projet Actuel subgraph LB1[Logiciel Bureau] L1[Linux] W1[Windows] M1[macOS] end subgraph LM1[Logiciel Mobile] A1[Android] I1[iOS] end end subgraph Projet Actuel subgraph LB2[Logiciel Bureau] L2[Linux] W2[Windows] M2[macOS] end subgraph LM2[Logiciel Mobile] A2[Android] I2[iOS] end end Kotlin((Kotlin)) Dart((Dart)) L1 & W1 & M1 --- Kotlin --> L2 & W2 & M2 A1 & I1 --- Dart --> A2 & I2

Nous allons maintenant estimer pour chaque cible, le nombre de projets où son code source pourra être réutilisé (combien de flèches partent d’une cible à gauche pour arriver à droite)

Système d’exploitation Langage Partageable sur X projets
Linux Kotlin 3.0
Windows Kotlin 3.0
macOS Kotlin 3.0
Android Dart 2.0
iOS Dart 2.0
Moyenne   2.6

Le ratio obtenu au final montre que le code peut être partagé en moyenne sur plus de la moitié des projets. Rappelons que le moins bon ratio possible est lorsqu’un projet ne peut-être partagé uniquement vers un projet du même type, donnant ainsi une moyenne de 1 projet. Là ou le meilleur ratio possible serait une solution où chacun des cinq projet peut-être partagé avec les cinq autres, la moyenne serait donc 5.

En divisant ce ratio par la quantité totale des projets nous obtenu un indice de partage de code de 52% soit plus du double de l’hypothèse précédente.

Hypothèse 2 - Critères 3 : Le résultat

Hypothèse 2 - Critères 3.1 : Utilisation du processeur et de la mémoire

Observons maintenant les mesures de l’utilisation des ressources pour cette hypothèse.
Étant donnée que les technologies sont similaires à celles de l’hypothèse précédente, nous pouvons nous attendre à des résultats semblables.

Rappelons les instants de mesures :

  • A : Ouverture de l’application et arrivé sur la liste des articles
  • B : Tri des articles
  • C : Ouverture de la page d’un utilisateur
  • D : Connexion à l’application
  • E : Publication d’un article
  • F : Suppression d’un article
Hypothèse 2 - Critère 3.1.1 : Utilisation du processeur
  Application bureau Application mobile Moyenne
A 7.63 9.29 8.46
B 6.75 8.11 7.43
C 5.91 6.73 6.32
D 6.96 6.49 6.73
E 6.02 7.48 6.75
F 4.65 5.51 5.08
Moyenne 6.32 7.27 6.80

Comme anticipée, l’utilisation du processeur est très similaire étant donné que cette hypothèse mesure des applications natives elle aussi.
Nous pouvons remarquer une légère hausse mais il est impossible de déterminer si elle est due à la technologie employée ou à une coïncidence.

Nous situons en moyenne l’utilisation du processeur aux alentours de 6.80% pour cette hypothèse.

Hypothèse 2 - Critère 3.1.2 : Utilisation de la mémoire

Sur les mêmes six actions, regardons l’utilisation de la mémoire vive (en MB).

  Application bureau Application mobile Moyenne
A 16.86 17.90 17.38
B 14.23 15.78 15.01
C 16.61 13.92 15.27
D 15.71 13.87 14.79
E 14.55 15.81 15.18
F 11.75 13.61 12.68
Moyenne 14.95 15.15 15.05

Même chose ici, les résultats sont similaires à l’hypothèse précédente tel que nous aurions pu l’imaginer. En moyenne, l’utilisation de la mémoire est de 15.05MB pour cette hypothèse.

Hypothèse 2 - Critères 3.2 : Temps de réponse moyen

Rappelons les deux instants de mesures supplémentaires :

  • G : First Contentful Paint ou premier affichage de contenu (temps avant que les premières données n’arrivent à l’écran)
  • H : Time to Interactive ou durée avant interaction possible. (temps avant de pouvoir avoir la main sur le logiciel)

Les valeurs sont exprimées en secondes.

  Application bureau Application mobile Moyenne
A 1.93 2.13 2.03
B 0.75 0.79 0.77
C 0.16 0.13 0.14
D 0.15 0.18 0.17
E 0.77 0.79 0.78
F 0.07 0.08 0.08
G 0.74 0.89 0.82
H 0.81 1.01 0.91
Moyenne 0.67 0.75 0.71

Sans surprise nous pouvons donc observer que le temps de réactivité de cette hypothèse est fortement similaire à celui de l’hypothèse précédente, en moyenne à 0.71s.

Hypothèse 2 - Critère 3.3 : Le poids de l’exécutable

Dans cette hypothèse, le code source des cibles bureau permet de créer un unique exécutable capable de fonctionner sur toutes les machines fixes.
En revanche, le code source des cibles mobiles doit être compilé deux fois fin de produire un exécutable par cible.

Groupe de cibles Langage Nature Poids (en MB)
Logiciels Bureau Kotlin Natif 8.12
Android Dart Natif 11.77
iOS Dart Natif 13.40
Moyenne - - 11.10
Total - - 33.29

Comme pour l’hypothèse précédente, les poids des applications mobiles sont légèrement plus élevés que celui des logiciels bureau. D’autant plus que les applications créées avec Flutter (ou d’autres outils similaires) ont une charge supplémentaire de poids comparé aux applications standard2.

Hypothèse 2 - Synthèse des critères

  • Critères 1 (Avant le développement)
    • Critère 1.1 (Temps de développement) : 58h
    • Critère 1.2.1 (Limitations techniques) : 4.8 pts
    • Critère 1.2.2 (Limitations esthétiques) : 2.3 pts
  • Critères 2 (Après le développement)
    • Critère 2.1 (Déploiement) : 4.1 pts
    • Critère 2.2 (Maintenance) : 4.4 pts
    • Critère 2.3 (Réutilisation) : 52%
  • Critères 3 (Résultat)
    • Critère 3.1.1 (Benchmark processeur) : 6.80%
    • Critère 3.1.2 (Benchmark mémoire) : 15.05MB
    • Critère 3.2 (Temps de réponse) : 0.71s
    • Critère 3.3 (Poids total) : 11.10MB

Graphique Hypothèse 2

Hypothèse 2 - Comparatif

Comme répété plusieurs fois au long de cette hypothèse, la plupart des mesures sont bien entendu très similaires étant donnée que les technologies le sont aussi.

Néanmoins cette hypothèse permet de résoudre deux des problèmes les plus importants de l’hypothèse 1, à savoir le temps de développement et la réutilisation du code.

En effet, il va de soi que développer seulement deux applications est bien plus rapide que d’en développer cinq. Cela dit, cette facilité vient avec une limitation sur le choix de la technologie car tous les langages ne sont pas multiplateformes. Et même au sein de ces langages, tous les outils ne permettent pas de créer des logiciels fonctionnant sur plusieurs systèmes d’exploitation.

Aussi, limiter le nombre d’applications et donc de langages permet aussi de limiter le nombre de codes sources différents et donc d’accroître la quantité relative de code qui peut être employée à nouveau sur des projets à l’architecture applicative similaire.
Là encore, c’est sous réserve d’une limitation quant au choix des langages et des outils.

Enfin, malgré tous ces changements, le problème de liberté quant à l’affichage de l’interface utilisateur reste entier.

Hypothèse 2 - Conclusion

Cette hypothèse démontre l’importance de bien choisir la structure de l’application lors de la réalisation d’un projet aux technologies natives.
Nous avons pu remarquer que se limiter en choix de langage et d’outil est un compromis capable de pallier les plus importantes limitations des applications natives, à savoir leur faible portée par rapport aux cibles.

Cette hypothèse confirme à nouveau que si l’on maîtrise totalement les cibles d’un projet de développement de logiciel, les applications natives apportent performance et liberté.

Hypothèse 3

Une seule application web et une interface responsive pour tout les appareils cibles.

Hypothèse 3 - Présentation du proof of concept

Cette hypothèse part du principe qu’étant donné que toutes les cibles sont munies d’un navigateur internet, il est possible de faire tourner la même application web sur toutes celles-ci avec un seul code source et une seule interface qui s’adapterait à l’écran quelle que soit sa taille ou sa forme.

Voici l’unique projet donc, qui sera réalisé pour ce proof of concept :

Typescript/Javascript avec Angular

Hypothèse 3 - Critères 1 : Pendant le développement

Hypothèse 3 - Critère 1.1 : Le temps de développement

Cette application web est l’unique logiciel de l’hypothèse et son temps de développement est estimée à 20h.
Cette valeur reste en accord avec celles estimées jusqu’à présent mais naturellement, l’écart est toujours plus grand avec les hypothèses précédentes qui nécessitaient de multiplier ce temps par le nombre d’appareils cible.

Hypothèse 3 - Critère 1.2 : Les limitations des technologies

Hypothèse 3 - Critère 1.2.1 : L’accès aux fonctionnalités

Pour notre première hypothèse utilisant une technologie du web, voyons quelles sont les limitations de celles-ci.

À l’inverse des applications natives, les applications web ne possèdent pas un accès direct au fonctionnalités du système d’exploitation. Les seules choses qui leur sont permises sont les capacités du navigateur dans lequel elles tournent (Accéder à la caméra, la localisation, au microphone par exemple).

Impossible par exemple pour un applicatif web de stocker des fichiers à volonté sur le système de l’utilisateur, même avec sa permission (et là encore, il faudrait que l’utilisateur accepte chaque stockage de fichier indépendamment).
Impossible aussi de fonctionner sans une connexion internet décente et régulière ou de s’exécuter en arrière-plan.

Les applications web sont donc très limitées dans ce qu’elles sont capables de faire même si elles possèdent tout de même les qualités requises pour en faire de véritables utilitaires (Affichage et traitement de données).

Pour ce critère, nous évaluons sa note quinaire à 2.5.

Hypothèse 3 - Critère 1.2.2 : Les limitations esthétiques

Pour afficher une interface graphique, les applications web ont recours à une technologie appelée CSS (Cascading StyleSheets soit feuilles de style en cascade). Cette technologie, vieille de près de 24 ans a connu de nombreuses révisions et est aujourd’hui une technologie très puissante capable d’afficher des interfaces complexes et originales.

Pour donner un exemple de comparatif, j’invite le lecteur à comparer les différences graphiques entre ses logiciels de bureau et les différences entre chaque site web qu’il a déjà visité.

Pour ce critère, nous évaluons donc sa note quinaire à 5.0.

Hypothèse 3 - Critères 2 : Après le développement

Hypothèse 3 - Critères 2.1 : Le déploiement

Déployer une application web consiste à mettre son code “compilé” sur un serveur en ligne afin que les utilisateurs puissent le télécharger et l’exécuter directement dans leurs navigateurs Internet en indiquant l’adresse URL correcte.

Sans action nécessaire de la part de l’utilisateur autre que de cliquer sur le bon lien, on estime le déploiement d’un applicatif web est très simple et rapide.

Il est également bon de noter que cette méthode de déploiement est la même pour toutes les technologies du web.

Pour ce critère, nous évaluons sa note quinaire à 5.0.

Hypothèse 3 - Critères 2.2 : La maintenance

La maintenance d’une application web est à la fois simple et délicate.

En effet, même si la maintenance consiste à mettre à jour les fichiers de l’application sur le serveur afin que les utilisateurs puissent récupérer la nouvelle version sans même le savoir, il existe quelques problématiques inhérentes aux limitations techniques des technologies du web.

Puisqu’il n’est pas possible de faire fonctionner un logiciel web sans connexion Internet, il n’est donc pas possible de rendre le serveur indisponible le temps de la mise à jour sans mettre en place un système complexe d’équilibreur de charge (load balancer, exemple : NGINX).

Pour ce critère, nous évaluons sa note quinaire à 3.0.

Hypothèse 3 - Critères 2.3 : La réutilisation

Du point de vue de la réutilisation du code, étant donné que ce projet se base sur une seule et unique technologie par rapport aux précédentes hypothèses, nous pouvons d’ors et déjà fixer l’indice de réutilisation à 100%.

Hypothèse 3 - Critères 3 : Le résultat

Hypothèse 3 - Critères 3.1 : Utilisation du processeur et de la mémoire

Hypothèse 3 - Critère 3.1.1 : Utilisation de du processeur
  • Ouverture de l’application et arrivé sur la liste des articles : 39.4%
  • Tri des articles : 28%
  • Ouverture de la page d’un utilisateur : 15%
  • Connexion à l’application : 17%
  • Publication d’un article : 35.2%
  • Suppression d’un article : 11%

En moyenne l’utilisation du processeur pour l’onglet de la page est donc de 24.3% soit presque le quadruple des hypothèses précédentes.

Hypothèse 3 - Critère 3.1.2 : Utilisation de la mémoire
  • Ouverture de l’application et arrivé sur la liste des articles : 66.73MB
  • Tri des articles : 55.06MB
  • Ouverture de la page d’un utilisateur : 54.40MB
  • Connexion à l’application : 56.82MB
  • Publication d’un article : 66.60MB
  • Suppression d’un article : 65.05MB

En moyenne l’utilisation de la mémoire pour l’onglet de la page est donc de 60.78MB, le même ordre de grandeur que le critère précédent.

Hypothèse 3 - Critères 3.2 : Temps de réponse moyen

  • Ouverture de l’application et arrivé sur la liste des articles : 1.84s
  • Tri des articles : 0.77s
  • Ouverture de la page d’un utilisateur : 0.53s
  • Connexion à l’application : 1.01s
  • Publication d’un article : 2.31s
  • Suppression d’un article : 1.04s
  • First Contentful Paint ou premier affichage de contenu : 0.7s
  • Time to Interactive ou durée avant interaction possible : 2.4s

Le temps de réponse moyen de cette application est donc de 1.33s soit un peu plus d’une demie seconde supplémentaire par rapport aux hypothèses natives.

Hypothèse 3 - Critère 3.3 : Le poids de l’exécutable

Une application web peut être exécutée de deux manières différentes et son poids change en fonction de la méthode employée.

Tout d’abord, pour un développeur travaillant actuellement sur le projet, il est crucial de pouvoir compiler le code très rapidement afin de très vite pouvoir tester et opérer des changements et des corrections. Le poids de l’application n’est pas important est peut être sacrifié au profit de la vitesse de compilation.
Dans le cas du déploiement de l’application pour des utilisateurs, le compromis est tout à fait inverse : il est acceptable de laisser la machine prendre plus de temps à la compilation afin que le résultat soit aussi léger que possible.

Afin de gérer ces deux cas de figure, les développeurs travaillent avec ce que l’on appelle deux profils. Le premier, le profil “développement” indique à la machine qu’elle doit s’efforcer d’accélérer la compilation au profit de l’espace de stockage requis et le second, le profil “production” qui lui indique plutôt de prendre le temps de limiter le gaspillage d’espace.

Le profil “développement” étant uniquement à but temporaire, c’est le profil “production” que nous allons mesurer. Sa valeur est donc de 883 KB.

Si cette valeur semble si peu grande en comparaison aux autres hypothèses c’est que l’affichage des applications web se fait par le biais du navigateur et que la mesure de celui-ci n’est pas prise en compte dans les hypothèses.

Hypothèse 3 - Synthèse des critères

  • Critères 1 (Avant le développement)
    • Critère 1.1 (Temps de développement) : 20h
    • Critère 1.2.1 (Limitations techniques) : 2.5 pts
    • Critère 1.2.2 (Limitations esthétiques) : 5.0 pts
  • Critères 2 (Après le développement)
    • Critère 2.1 (Déploiement) : 5.0 pts
    • Critère 2.2 (Maintenance) : 3.0 pts
    • Critère 2.3 (Réutilisation) : 100%
  • Critères 3 (Résultat)
    • Critère 3.1.1 (Benchmark processeur) : 24.3%
    • Critère 3.1.2 (Benchmark mémoire) : 60.78MB
    • Critère 3.2 (Temps de réponse) : 1.33s
    • Critère 3.3 (Poids total) : 0.88MB

Graphique Hypothèse 3

Hypothèse 3 - Comparatif

Comme nous avons pu le remarquer, cette application web est très peu similaire aux applications natives des hypothèses précédentes.

Tout d’abord, du point de vue des performances, cette application web est bien plus consommatrice de ressources que ses contreparties natives, d’une magnitude de presque quatre.
Les applications web présentent aussi de nombreuses lacunes quant aux accès aux fonctionnalités natives de l’appareil.

Le gain en revanche se situe au niveau du temps de développement, de déploiement et aussi sur le poids final de l’application et sa capacité à pouvoir partager du code.
Chacun de ces critères a une note quasi parfaite dans cette hypothèse.

C’est aussi le cas de l’aspect esthétique qui propose une liberté de mise en page virtuellement infinie grâce au CSS.

Hypothèse 3 - Conclusion

Nous avons donc pu voir que le principe d’une application web n’est pas du tout le même qu’une application native, ces deux méthodes ne cherchent en aucun cas à atteindre le même but.

Là où les applications natives brillent par leurs performances brutes, c’est dans la vitesse de création et de déploiement que se démarquent les applications web, mais aussi dans l’apparence qui peut facilement être très alléchante pour les utilisateurs.

Dans le cas d’une application à but extrêmement multiplateforme, c’est une méthode de choix qui permet de rapidement créer et fournir une belle application finie, surtout si cette dernière se base sur le code d’une application précédente, ce qui est fort probable et fort adapté.

Hypothèse 4

Une application web pour les cibles bureau et une application native dans le même langage pour le cibles mobiles

Hypothèse 4 - Présentation du proof of concept

Cette hypothèse s’aligne sur la vision de la deuxième en affirmant que deux applications différentes pour les deux types de cibles permettent de limiter les temps de développement.
À l’inverse de cette dernière cependant, l’hypothèse 4 est basée sur un langage unique dont les blocs qui la composent peuvent être réemployé.

Voici les deux projets qui composent cette hypothèse :

Ils se reposent tous deux sur le même langage (Typescript) et le même outil de conception (Angular). L’application mobile utilise en plus l’outil NativeScript qui permet de transformer un projet web utilisant Angular en application mobile native pour Android et iOS.

Hypothèse 4 - Critères 1 : Pendant le développement

Hypothèse 4 - Critère 1.1 : Le temps de développement

Groupe de cibles Langage Nature Nombre estimé d’heures
Logiciel Bureau Typescript Web 20
Logiciel Mobile Typescript Natif 23
Moyenne - - 22
Total - - 43

Le code source du logiciel bureau étant principalement le même que l’hypothèse d’avant, le nombre estimé ne fluctue pas. On constate aussi que la technologie utilisée étant très similaire, les deux applicatifs ont des estimations très proches.

Hypothèse 4 - Critère 1.2 : Les limitations des technologies

Hypothèse 4 - Critère 1.2.1 : L’accès aux fonctionnalités

Dans le cas d’une application web et une autre native, nous pouvons nous attendre à des différences assez importantes après les observations que nous avons pu effectuer lors de l’analyse des hypothèses précédentes.

Groupe de cibles Langage Nature Note sur 5
Logiciel Bureau Typescript Web 2.5
Logiciel Mobile Typescript Natif 4.5
Moyenne     3.5

En effet, tel que dans l’hypothèse précédente, les applications web n’ont que très peu de libertés quant aux fonctionnalités auxquelles elles ont accès là où, tel que dans les hypothèses 1 et 2, ce n’est pas un problème que rencontrent les logiciels natifs.

Hypothèse 4 - Critère 1.2.2 : Les limitations esthétiques

Concernant les libertés de conception d’interface, on s’attend à obtenir un résultat tout à fait inverse.

Groupe de cibles Langage Nature Note sur 5
Logiciel Bureau Typescript Web 5.0
Logiciel Mobile Typescript Natif 2.0
Moyenne     3.5

La note parfaite du logiciel bureau s’explique encore par la présence du CSS.
Si le logiciel mobile a une note plus faible que dans les hypothèses précédentes, c’est dû à la technologie employée par l’outil NativeScript.

En effet, NativeScript propose un ersatz de CSS afin que le développeur web retrouve une technologie qui lui est familière. Cette méthode est cependant loin d’être aussi puissante que le réel CSS.

Bridé par la nature native de l’application, il n’est pas possible d’utiliser du véritable CSS avec cet outil. L’algorithme de conversion de ce “CSS” vers la mise en page native n’est pas sans erreur du à la marge importante de liberté entre ces deux technologies.

Hypothèse 4 - Critères 2 : Après le développement

Hypothèse 4 - Critères 2.1 : Le déploiement

Même chose dans le cas du déploiement, nous pouvons nous attendre à des notes similaires que celles des hypothèses web et natives.

Système d’exploitation Note sur 5
Linux 5.0
Windows 5.0
macOS 5.0
Android 4.5
iOS 2.0
Moyenne 4.3

Le déploiement de l’application web reste aussi simple que dans l’hypothèse précédente, et nous rencontrons les mêmes problématiques pour le déploiement sur les mobiles iOS que sur les autres hypothèses.

Hypothèse 4 - Critères 2.2 : La maintenance

Idem pour la maintenance.

Système d’exploitation Note sur 5
Linux 3.0
Windows 3.0
macOS 3.0
Android 5.0
iOS 3.5
Moyenne 3.5

Ici encore, seul Android et son store qui permet les mises à jour automatiques parvient à se démarquer des applications web et leur maintenance coûteuse ou de iOS et de sa phase de test obligatoire bridant la réactivité des déploiements.

Hypothèse 4 - Critères 2.3 : La réutilisation

Jugeons de la capacité du code à pouvoir servir à nouveau lors du développement d’un projet usant de technologies semblables.

graph LR subgraph Projet Actuel subgraph LB1[Logiciel Bureau] L1[Linux] W1[Windows] M1[macOS] end subgraph LM1[Logiciel Mobile] A1[Android] I1[iOS] end end subgraph Projet Actuel subgraph LB2[Logiciel Bureau] L2[Linux] W2[Windows] M2[macOS] end subgraph LM2[Logiciel Mobile] A2[Android] I2[iOS] end end TS((Typescript)) L1 & W1 & M1 & A1 & I1 --- TS --> L2 & W2 & M2 & A2 & I2

Ici, pour simplifier le schéma nous ne voyons que les liens directs qui se font. Voyons plus en détails les liens effectifs :

Système d’exploitation Langage Nature Partageable sur X projets
Linux Typescript Web 4
Windows Typescript Web 4
macOS Typescript Web 4
Android Typescript Natif 3.5
iOS Typescript Natif 3.5
Moyenne     3.8

On considère que le code du web peut être partagé sur les trois systèmes d’exploitation bureau (soit 3) et que seule la moitié du code est réutilisable sur les cibles mobiles (soit 0.52 = 1).
De même, ce calcul inversé pour les cibles mobiles nous indique qu’il peut être partagé sur les deux systèmes d’exploitation mobiles (soit 2) et uniquement partiellement sur les cibles bureau (soit 0.53 = 1.5).

En divisant le ratio moyen par la quantité totale des projets nous obtenons un indice de partage de code de 76%. Cela reste moins que pour l’hypothèse 3 exclusivement web et mono-projet mais bien au-delà des résultats obtenus pour les applications natives.

Hypothèse 4 - Critères 3 : Le résultat

Hypothèse 4 - Critères 3.1 : Utilisation du processeur et de la mémoire

En ce qui concerne l’utilisation des ressources pour cette hypothèse, nous pouvons nous attendre à des résultats mêlant la partie bureau de l’hypothèse 3 et la partie mobile de l’hypothèse 2 car nous mélangeons une application web et une application native.

Rappelons les instants de mesures :

  • A : Ouverture de l’application et arrivé sur la liste des articles
  • B : Tri des articles
  • C : Ouverture de la page d’un utilisateur
  • D : Connexion à l’application
  • E : Publication d’un article
  • F : Suppression d’un article
Hypothèse 4 - Critère 3.1.1 : Utilisation du processeur
  Application bureau Application mobile Moyenne
A 38.10 9.27 23.70
B 29.00 8.42 18.60
C 15.80 6.83 11.30
D 17.70 6.90 12.10
E 33.50 7.85 20.50
F 13.00 5.49 9.26
Moyenne 24.00 7.38 15.60

Nous pouvons constater l’écart entre les applications web et mobiles côte à côte dans ce tableau. Les valeurs sont donc similaires à ce qui a pu être observé précédemment.

Nous situons en moyenne l’utilisation du processeur aux alentours de 15.60% pour cette hypothèse.

Hypothèse 4 - Critère 3.1.2 : Utilisation de la mémoire

Sur les mêmes six actions, regardons l’utilisation de la mémoire vive (en MB).

  Application bureau Application mobile Moyenne
A 64.40 22.61 43.51
B 50.20 18.87 34.54
C 55.30 16.92 36.11
D 58.10 9.14 33.62
E 71.20 18.73 44.97
F 67.90 11.96 39.93
Moyenne 61.20 16.35 38.77

Les résultats sont ici encore conformes à nos attentes. En moyenne, l’utilisation de la mémoire est de 38.77MB pour cette hypothèse.

Hypothèse 4 - Critères 3.2 : Temps de réponse moyen

Rappelons les deux instants de mesures supplémentaires :

  • G : First Contentful Paint ou premier affichage de contenu (temps avant que les premières données n’arrivent à l’écran)
  • H : Time to Interactive ou durée avant interaction possible. (temps avant de pouvoir avoir la main sur le logiciel)

Les valeurs sont exprimées en secondes.

  Application bureau Application mobile Moyenne
A 1.83 2.19 2.01
B 0.81 0.73 0.77
C 0.46 0.21 0.34
D 0.92 0.19 0.56
E 1.36 0.81 1.09
F 1.01 0.56 0.79
G 0.69 0.81 0.75
H 2.11 1.26 1.69
Moyenne 1.15 0.85 1.00

Nous obtenons donc une moyenne de temps de réactivité de 1.00s.

Hypothèse 4 - Critère 3.3 : Le poids de l’exécutable

Comparons le poids des exécutables obtenus avec le développement de cette hypothèse.

Groupe de cibles Langage Nature Poids (en MB)
Logiciels Bureau Typescript Web 0.88
Android Typescript Natif 12.23
iOS Typescript Natif 13.51
Moyenne - - 8.87
Total - - 26.62

Comme pour l’hypothèse précédente, le poids de l’application web est très faible comparé aux applications mobiles car son affichage se fait dans le navigateur.
Du point de vue des logiciels mobiles, nous retrouvons un poids assez similaire à celui des applications mobiles natives que nous avons déjà observés.

Hypothèse 4 - Synthèse des critères

  • Critères 1 (Avant le développement)
    • Critère 1.1 (Temps de développement) : 43h
    • Critère 1.2.1 (Limitations techniques) : 3.5 pts
    • Critère 1.2.2 (Limitations esthétiques) : 3.5 pts
  • Critères 2 (Après le développement)
    • Critère 2.1 (Déploiement) : 4.3 pts
    • Critère 2.2 (Maintenance) : 3.5 pts
    • Critère 2.3 (Réutilisation) : 76%
  • Critères 3 (Résultat)
    • Critère 3.1.1 (Benchmark processeur) : 15.60%
    • Critère 3.1.2 (Benchmark mémoire) : 38.77MB
    • Critère 3.2 (Temps de réponse) : 1.00s
    • Critère 3.3 (Poids total) : 8.87MB

Graphique Hypothèse 4

Hypothèse 4 - Comparatif

Cette hypothèse mélange deux approches différentes de la création d’application dans le but de mitiger les inconvénients que chaque méthode possède.

Malgré les deux applications à développer, le temps de développement final reste inférieur à celui de l’hypothèse 2, car le code peut être partagé dès la phase de production, sans attendre un hypothétique futur projet basé sur la même architecture applicative.

Pour le reste des critères, nous retrouvons sans surprise une moyenne des applications web et natives.

Hypothèse 4 - Conclusion

Comme nous pouvons le constater avec le diagramme en toile, cette hypothèse est très équilibré en comparaison avec les autres précédentes. C’est une architecture qui permet de gagner beaucoup de temps de développement sur le moment et d’en gagner dans le futur grâce à un partage de code efficace.\

Cette hypothèse fait le sacrifice des performances sur les plates-formes puissantes (avec l’application web bureau), mais y prête une attention particulière sur les plates-formes qui le sont moins (avec l’application native mobile).
En faisant cela, elle profite des avantages octroyés par les applications web sans mettre de coté le confort de l’utilisateur final.

Cela démontre encore une fois que le choix d’une architecture applicative n’est pas une question de choisir une méthode et de s’y tenir coûte que coûte, mais plutôt de savoir ce que l’on recherche pour pouvoir mélanger les points forts et les points faibles de chaque solution dans le but d’avoir une optimisation équilibrée.

Hypothèse 5

Une application web hybride pour les cibles bureau et une application hybride pour les cibles mobiles

Hypothèse 5 - Présentation du proof of concept

Cette hypothèse reprend en quelque sorte le format de l’hypothèse 2 et les technologies de l’hypothèse 3, à savoir réaliser deux applicatifs différents dans des technologies du web. Il ajoute en plus le fait de profiter de cette différence pour en faire des applications hybrides.
Cette hypothèse cherche à palier le manque d’accès aux fonctionnalités du système d’exploitation en encapsulant l’application web dans un logiciel natif (ayant ces accès) et de faire communiquer les deux.

Les technologies utilisées dans cette hypothèse sont les mêmes que celles de l’hypothèse précédente, à cela près que les applications seront modifiées afin d’utiliser des technologies de création d’application hybride.

Ces technologies capables de faire d’une application web, une application hybrides sont :

Hypothèse 5 - Critères 1 : Pendant le développement

Hypothèse 5 - Critère 1.1 : Le temps de développement

Les technologies utilisées pour la création de ce proof of concept étant les mêmes que pour l’hypothèse précédente, nous retrouvons les mêmes valeurs à ceci près que le temps d’intégrer les outils pour l’hybride est à prendre en compte.

Groupe de cibles Langage Nature Nombre estimé d’heures
Logiciel Bureau Typescript Hybride 24
Logiciel Mobile Typescript Hybride 25
Moyenne - - 25
Total - - 49

Hypothèse 5 - Critère 1.2 : Les limitations des technologies

Hypothèse 5 - Critère 1.2.1 : L’accès aux fonctionnalités

Tout l’intérêt de cette hypothèse repose sur le principe de développer avec des technologies web et de profiter des conteneurs natifs pour pouvoir accéder aux fonctionnalités des systèmes d’exploitation des appareils cibles.

Groupe de cibles Langage Nature Note sur 5
Logiciel Bureau Typescript Hybride 4.5
Logiciel Mobile Typescript Hybride 4.0
Moyenne     4.3

L’accès aux fonctionnalités natives se fait dans ces technologies hybrides, par la mise en place de plugins, permettant l’accès à chacune des fonctionnalités une par une. C’est un coût de temps de développement certes très léger, mais présent par rapport à une application native.

Par ailleurs, les applications mobiles “souffrent” toujours de la demande de confirmation à l’utilisateur lors de l’accès aux fonctionnalités.

Hypothèse 5 - Critère 1.2.2 : Les limitations esthétiques

Bien entendu, le CSS reste tout à fait possible d’utilisation sur les applications hybrides.

Groupe de cibles Langage Nature Note sur 5
Logiciel Bureau Typescript Hybride 5.0
Logiciel Mobile Typescript Hybride 5.0
Moyenne     5.0

Il est donc naturel que la note soit la même que pour celle de l’hypothèse 3.

Hypothèse 5 - Critères 2 : Après le développement

Hypothèse 5 - Critères 2.1 : Le déploiement

Le déploiement de ces deux applicatifs est similaire à celui des applications natives puisque les systèmes d’exploitation ne sont pas capables de faire la différence entre un logiciel hybride et natif.

Système d’exploitation Note sur 5
Linux 4.5
Windows 4.5
macOS 4.5
Android 5.0
iOS 2.0
Moyenne 4.1

Les résultats sont donc les même que pour l’hypothèse 2.

Hypothèse 5 - Critères 2.2 : La maintenance

Idem pour la maintenance.

Système d’exploitation Note sur 5
Linux 4.5
Windows 4.5
macOS 4.5
Android 5.0
iOS 3.5
Moyenne 4.4

Hypothèse 5 - Critères 2.3 : La réutilisation

Cependant, contrairement à l’hypothèse 2, l’utilisation de la technologie web est là pour optimiser grandement la réutilisation possible du code source. Mise à part l’interface qui peut être différente, l’intégralité de ce code peut être réutilisé à volonté dans des projets ultérieurs.

Les applications hybrides bénéficient donc d’un indice de réutilisation du code de 100% comme les applications web (cf. hypothèse 3).

Hypothèse 5 - Critères 3 : Le résultat

Hypothèse 5 - Critères 3.1 : Utilisation du processeur et de la mémoire

Les applications hybrides étant des applications web incorporées dans des conteneurs natifs, leurs performances devraient être similaires à celles des logiciels web classiques.

Rappelons les instants de mesures :

  • A : Ouverture de l’application et arrivé sur la liste des articles
  • B : Tri des articles
  • C : Ouverture de la page d’un utilisateur
  • D : Connexion à l’application
  • E : Publication d’un article
  • F : Suppression d’un article
Hypothèse 5 - Critère 3.1.1 : Utilisation du processeur
  Application bureau Application mobile Moyenne
A 38.28 36.46 37.37
B 25.45 29.23 27.34
C 13.00 15.84 14.42
D 19.95 19.80 19.88
E 32.39 35.48 33.94
F 9.32 9.87 9.60
Moyenne 23.07 24.45 23.76

Les deux applications ont donc des résultats comparables à ceux de l’hypothèse 3, comme nous pouvions nous y attendre

L’utilisation du processeur peut être située aux alentours de 23.76% pour cette hypothèse.

Hypothèse 5 - Critère 3.1.2 : Utilisation de la mémoire

Sur les mêmes six actions, regardons l’utilisation de la mémoire vive (en MB).

  Application bureau Application mobile Moyenne
A 73.07 76.67 74.87
B 63.63 58.69 61.16
C 60.96 58.82 59.89
D 60.87 59.87 60.37
E 71.40 68.76 70.08
F 69.98 68.21 69.10
Moyenne 66.65 65.17 65.91

Nous observons une utilisation de la mémoire de 65.91MB pour cette hypothèse.

Hypothèse 5 - Critères 3.2 : Temps de réponse moyen

Rappelons les deux instants de mesures supplémentaires :

  • G : First Contentful Paint ou premier affichage de contenu (temps avant que les premières données n’arrivent à l’écran)
  • H : Time to Interactive ou durée avant interaction possible. (temps avant de pouvoir avoir la main sur le logiciel)

Les valeurs sont exprimées en secondes

  Application bureau Application mobile Moyenne
A 1.80 1.78 1.79
B 0.65 1.03 0.84
C 0.51 0.35 0.43
D 0.87 0.83 0.85
E 2.15 2.31 2.23
F 0.71 1.21 0.96
G 0.66 0.44 0.55
H 2.39 1.96 2.18
Moyenne 1.22 1.24 1.23

Nous obtenons donc une moyenne de temps de réactivité de 1.23s, un résultat légèrement inférieur à l’hypothèse 3 s’expliquant en partie par le fait que les données sont stockées localement avec les applications hybrides, plutôt que sur un serveur distant comme pour les applications web.

Hypothèse 5 - Critère 3.3 : Le poids de l’exécutable

Nous avons déjà pu observer le poids d’une application native (par extension hybride) mobile dans l’hypothèse 4. Voyons le poids d’un logiciel hybride bureau.

Groupe de cibles Langage Nature Poids (en MB)
Linux Typescript Hybride 57.32
Windows Typescript Hybride 66.25
macOS Typescript Hybride 117.30
Android Typescript Hybride 12.34
iOS Typescript Hybride 13.84
Moyenne - - 53.41
Total - - 267.05

Comme nous pouvons le constater, le poids d’une application hybride bureau utilisant Electron est assez conséquent. Electron fonctionne en embarquant un navigateur allégé basé sur Chrome (Chromium) mais cette nuance est très importante. C’est l’un des plus gros points faibles de cet outil encore actuellement.

Hypothèse 5 - Synthèse des critères

  • Critères 1 (Avant le développement)
    • Critère 1.1 (Temps de développement) : 49h
    • Critère 1.2.1 (Limitations techniques) : 4.3 pts
    • Critère 1.2.2 (Limitations esthétiques) : 5.0 pts
  • Critères 2 (Après le développement)
    • Critère 2.1 (Déploiement) : 4.1 pts
    • Critère 2.2 (Maintenance) : 4.4 pts
    • Critère 2.3 (Réutilisation) : 100%
  • Critères 3 (Résultat)
    • Critère 3.1.1 (Benchmark processeur) : 23.76%
    • Critère 3.1.2 (Benchmark mémoire) : 65.91MB
    • Critère 3.2 (Temps de réponse) : 1.23s
    • Critère 3.3 (Poids total) : 53.41MB

Graphique Hypothèse 5

Hypothèse 5 - Comparatif

Nous pouvons remarquer que cette solution présente des avantages par rapport à une application web, bien que le langage de développement reste le même.

Cette hypothèse possède la plupart des avantages d’une application web (Excellent potentiel de réutilisation, temps de développement courts et interface utilisateur très poussée) et souffre des mêmes inconvénients (Performances en deçà des logiciels natifs).
Cependant, elle apporte un avantage conséquent dans sa capacité à pouvoir profiter des pleines fonctionnalités du système d’exploitation sur lequel elle tourne.

Son inconvénient principal est son poids particulièrement élevé, dû à l’intégration du navigateur.

Hypothèse 5 - Conclusion

Bien qu’elle ne permette de résoudre que l’un des deux principaux problèmes des applications web (à savoir les limitations des fonctionnalités), l’approche hybride est une bonne façon de produire des logiciels à l’apparence “solide”, apportant à l’utilisateur tout ce qu’il attend d’une application native.

Quand bien même les performances ne sont pas aussi bonnes, et le poids particulièrement élevé, ce sont deux critères qui, aujourd’hui, ont moins d’importance étant donné les performances de nos postes de travail.

Les applications hybrides sont donc un bon compromis entre l’approche native et web, et restent compatibles avec presque 100% des technologies du web.

Il est très intéressant de noter que pour pallier le problème du poids, de récentes technologies de logiciels hybrides tentent d’utiliser des navigateurs très allégés, voire directement celui intégré au système d’exploitation. (Notons Tauri, Neutralinojs et Lorca)

  1. Average App File Size (Sweet Pricing) ↩

  2. Comparing APK sizes (AndroidPub) ↩