Excédé par les pratiques d'Apple, Micro.blog bazarde les technologies natives pour son app iOS
En voulant protéger à tout prix sa commission de 30 % attachée à son système de paiement, Apple ne renvoie pas la meilleure image possible auprès des développeurs. Des développeurs qui doivent également composer avec les caprices de l'App Store, qu'il s'agisse du refus d'une mise à jour ou carrément d'un rejet d'une application pour toutes sortes de raisons plus ou moins ésotériques.
À l'heure actuelle, Apple peut se permettre de jouer les gros bras : l'App Store est le gagne-pain de millions de développeurs, qui ont reçu 260 milliards de dollars depuis l'ouverture de la boutique en 2008. Et de toutes façons, il n'existe pas d'autre moyen pour distribuer largement des applications sur un iPhone ou un iPad, à moins de le jailbreaker.
On n'observe donc aucune fuite des développeurs vers de plus verts pâturages, mais Micro.blog pourrait être une de ces étincelles qui allumera le feu. La petite équipe, qui développe l'app du même nom permettant de créer des microblogs, va continuer à livrer des apps iOS sur l'App Store (pas le choix), mais elle a décidé de bazarder les technologies d'Apple.
La version iOS Micro.blog va donc reposer à l'avenir sur React Native, le framework JavaScript conçu par Facebook pour ses propres apps mobiles. L'éditeur travaille sur la mouture Android de son application avec React Native, qui partagera son code avec son homologue pour iPhone. En abandonnant UIKit, Micro.blog va dégager du temps pour améliorer la version Mac de son logiciel, conçue avec le framework natif de la plateforme, AppKit.
Manton Reece, le créateur de Micro.blog est visiblement excédé par les pratiques d'Apple qui a « perdu la confiance des développeurs ». « C'est une opinion désormais répandue, ce ne sont pas simplement quelques développeurs à la marge qui se plaignent », poursuit-il en pointant du doigt les manœuvres du constructeur aux Pays-Bas.
App Store : Apple réduit sa commission à 27% sur les paiements alternatifs aux Pays-Bas
Micro.blog déplore aussi la fragmentation des plateformes de développement d'Apple, éclatée entre UIKit, AppKit, Catalyst (pour adapter rapidement des apps iPadOS sur macOS) et SwiftUI (interface commune à tous les systèmes d'exploitation d'Apple). « Nous sommes une petite équipe, et maintenir autant de versions différentes de nos applications est difficile », précise le billet. « Et en plus, pourquoi investir tant de temps dans des frameworks uniquement Apple quand Apple peut bouleverser notre activité avec une nouvelle taxe App Store ou d'autres perturbations ? »
Par ailleurs, l'expérience sur les versions mobiles iOS et Android sont similaires, ce qui n'est pas le cas sur Mac. « J'aime le Mac et je ne veux pas compromettre l'interface sur macOS avec un framework multiplateforme », ajoute Manton Reece (et pan sur le bec de 1Password qui est passé avec armes et bagages sur Electron). « macOS reste la seule plateforme ouverte d'Apple, il est donc judicieux d'y investir ».
Ce changement de braquet concerne les apps Micro.blog et Epilogue. Les autres applications de l'éditeur, comme Sunlit et Wavelength, restent développées avec UIKit.
Retour en arrière dans 2 ans. Classique.
@FloMo
C’est devenu une vraie catastrophe, ces applications qui passe d’une application mobile native à une application à base de React Native ou de Webview.
J’ai refait plusieurs applications mobiles en passant d’un code Cordova avec Sencha ExtJS en version native avec Swift. Résultat : beaucoup plus rapide, gain de mémoire et moins de plantage (le tout sur des iPad 3).
Pareil pour une autre application qui avait été commencé avec Titanium. En passant par des appels natifs, c’était beaucoup plus rapide.
Il faut juste cela pour soit disant le budget ou plus de vélocité pour les nouvelles fonctionnalités. Mais infine, c’est faux car il y a aura quand même des appels systèmes à faire en natif.
Même Facebook, qui a écrit React Native, ne semble pas l’utiliser partout dans ces applications.
Le seul que je n’ai pas testé est Flutter. Pour moi, Flutter a déjà quand même un avantage est qu’il cible à la fois le mobile et le desktop. Et il semble être de plus en plus utilisé, notamment pour Ubuntu par Canonical et Google, je pense que le Nest Home avec écran l’utilise aussi, si mes souvenirs sont bons.
@valcapri
Flutter : même combat. La SNCF n’a dupé personne par exemple.
@FloMo
La SNCF a juste fait de la merde et ce n’est pas dû au fait d’abandonner les technologies native d’iOS…
@redchou
C'est EVIDEMMENT le fait de choisir Flutter plutôt que du natif
c'est pas la "technologie" qui serait maudite. C'est l'INTENTION
L'intention des développeurs et de l'éditeur était de choisir la solution de facilité (un énième framework de merde multi-bug-de-tout-le-monde, multi-j'ai-l'interface-pourrie-de-tout-le-monde)
A partir du moment où on part sur la facilité, pourquoi ne pas bacler tout le reste ?
pourquoi ne pas aller pour la solution de la facilité encore + d'avantage en FOUTANT TOUT ET UN OURS dans UNE SEULE APP !
Admettez le : le seul fait d'avoir commencé une app "multiplatedéformée" était que l'un des signes que le tout serait fait pour bacler et ne plus se prendre la tête
donc du naze.
-
l'app de la sncf aura besoin de plusieurs moins pour rattraper son retard
puis tel un Apple et son misérable "applications Musique" devra reprendre 6 mois pour réécrire les pans absolument trop lents
puis ça sera un recommencement dans 5 ans quand il faudra à nouveau être "séduisant" pour plaire aux clients sur un nouveau bidule.
puis on recommencera à bacler l'app, à économiser partout.
c'est un cycle éternel.
@oomu
Bref, rien à voir avec la technologie, le problème, c’est juste les incompétents au manette.
@oomu
../.. erreur de position dans le fil 😎
@FloMo
"Flutter : même combat. La SNCF n’a dupé personne par exemple."
C’est aller très vite en besogne que de considérer que le pb c’est Flutter.
Tu fais un plaidoyer prodomo en rejetant le non natif, mais pour détestable que soit conceptuellement ces approches, elles sont appelées à prospérer quoi qu’on en pense.
Sur bien des cas d’usage le rapport coût / bénéfice du natif ne plaide plus en sa faveur 😉
@YetOneOtherGit
Je vais être plus précis.
Tout utilisateur de iOS en sensible aux animations et au timing de l’OS. De manière consciente ou non. Il est essentiel que l’utilisateur puisse anticiper le comportement exact de son UI.
Deuxième point : la performance. Ce qui est tolérable dans une app web ne l’est pas dans une app native où l’utilisateur s’attend à une réponse immédiate dans un timing précis.
Ces 2 contraintes sont amplifiées dans un contexte d’usage ponctuel et dans une situation plus ou moins stressante.
On sait que la performance n’est pas historiquement le fort des services web SNCF. Comme bien des structures ayant un passif important.
Il faut donc que le reste soit irréprochable.
Les animations de transition de Flutter ne sont pas synchronisées sur celles de iOS. Rien que ça, ça provoque une friction inconsciente.
Si on ajoute une intégration qui dénote du reste de l’expérience utilisateur de l’appareil, c’est l’échec garanti.
Et on ne parle même pas de l’appauvrissement en termes d’intégration à l’OS dû à l’abandon des plugins open-sources par leurs concepteurs. Comment les maintenir soi-même si on n’a pas la compétence native ? On bricole et on obtient un résultat bancal. Sans même s’en rendre compte.
Je connais par cœur ce schéma.
@FloMo
« On sait que la performance n’est pas historiquement le fort des services web SNCF. Comme bien des structures ayant un passif important.
Il faut donc que le reste soit irréprochable. »
Unifier les outils informatiques d’une boîte comme la sncf est très certainement une vrai gageure, alors en effet si l’UI et l’accès au service client étaient réussis ce serait déjà bien… ou l’inverse parce que du moche mais très efficace c’est pas si mal mais si ça attire la moquerie.
@FloMo
"Je connais par cœur ce schéma."
Tu mets en avant des limites techniques bien connues mais tu oublies sciemment les raisons qui font le succès des approches de ce type : les enjeux économiques et le rapport goût / bénéfice.
Pour le reste le ministère de la défense n’a pas eu besoin de Fluter pour faire Louvois.
Tu te focalises sur des enjeux de technologie en oubliant tout ce qui peut faire l’échec d’une production qui est de l’ordre de la conduite de projet.
Je suis loin d’être certain que l’application de la SNCF eu connu moins de pb si elle avait été natif 😉
@YetOneOtherGit
> Tu mets en avant des limites techniques bien connues mais tu oublies sciemment les raisons qui font le succès des approches de ce type : les enjeux économiques et le rapport goût / bénéfice.
Cette économie est illusoire.
Betclic en a fait les frais avec Xamarin et a du tout réécrire en natif face à l’échec auprès des utilisateurs.
Si on veut parler de RN, prenons en exemple un de ses principaux promoteurs : AirBNB. Ils ont dû revenir à du natif.
Et SNCF pourrait bien suivre le même chemin.
Ceci étant, la réécriture d’app hybride en natif en un vrai business.
@FloMo
Surtout que les grosses machines que vous citez ont tout de même des équipes fournies et des moyens.
Je comprends l’intérêt du multiplateformes pour lancer une idée ou pour une petite équipe qui opère dans un marché de niche mais pour des trucs aussi gros que la SNCF je trouve ça ridicule et au final ça ne fonctionne pas.
Betclic… c’est bien une des boîtes maltaises où les p’tits jeunes roulent en Lambo. 🤣 on peut pas tout faire en même temps voyons :-)
@MGA
"Surtout que les grosses machines que vous citez ont tout de même des équipes fournies et des moyens. "
La taille et les moyens ne sont en rien une garantie de bonne fin sur un projet, loin s’en faut. C’est même souvent un handicap 😉
@YetOneOtherGit
Je reformule : Si les gens de Micro blog considèrent qu’ils n’ont plus les moyens d’affecter les ressources nécessaires, la SNCF n’est pas dans ce cas.
Sinon en règle générale plus c’est gros moins c’est efficace en effet.
@FloMo
"Tout utilisateur de iOS en sensible"
Certes.
Pour les performances, le prochain téléphone sera plus rapide. Problème transitoire sans importance.
Pour l’UX, sans importance à moyen terme. L’utilisateur s’habituera à la dégradation des interfaces et leur universalisation, comme il s’est déjà adapté sur macOS sans cesser de prétendre que macOS est mieux. iOS restera mieux dans leur imaginaire même avec des applications multiplateformes médiocres.
Les promesses tout ça, aucune importance. Ce ne sont que des outils qui vont et qui viennent. Le web s’est imposé comme la plateforme universelle malgré tout.
C’est triste. Oui. Horrible même.
Mais c’est pragmatique.
@fte
> Pour les performances, le prochain téléphone sera plus rapide. Problème transitoire sans importance.
Ce n’est pas la réalité. Depuis 13 ans, on a toujours des UI qui rament. Même avec des iPhone surpuissants.
@FloMo
"Ce n’est pas la réalité. Depuis 13 ans, on a toujours des UI qui rament. Même avec des iPhone surpuissants."
Ce n’est pas grave. On peut prétendre. Ça suffit.
@fte
"C’est triste. Oui. Horrible même.
Mais c’est pragmatique."
Histoire de s’amuser, je ne sais pas si tu connais:
https://www.destroyallsoftware.com/talks/the-birth-and-death-of-javascript
@FloMo
"Flutter : même combat."
Vision un brin tunnel. Tu restes dans ton archétype d’eldorado iOS natif, c’est dans ta ligne habituelle sans surprise. Mais la très large tendance de l’industrie va dans une autre direction, c’est indéniable.
@fte
"Tu restes dans ton archétype d’eldorado iOS natif, c’est dans ta ligne habituelle sans surprise."
Et je suis vraiment étonné de constater que tant de Dev ne veulent pas voir le profond changement de paradigme par rapport à un age d’or révolu 🤔
@fte
Depuis 13 ans, ça va dans toutes les directions, en suivant le vent des nouvelles technologies hybrides. On a eu droit à une succession de promesses jamais tenues.
Les seuls qui ont réussi à conserver une constance dans leur trajectoire font soit des apps web, soit des apps natives.
Et ça leur permet d’optimiser leurs flux d’industrialisation sans s’inquiéter d’une quelconque dépendance technologique dispensable.
@valcapri
flutter est naze
comme toutes les solutions multiplateformes depuis la nuit des temps (années 70s)
parce que fondamentalement une solution multiplateforme est:
- le plus grand dénominateur commun, et ce qui est commun est horrible (le commun de l'interface de windows, mac, android, ios = Horreur)
- ce n'est JAMAIS adapté à la plateforme
- on perd la force de CHAQUE interface pour en garder que le PIRE !
- c'est choisi par le développeur pour des raisons d'économiques, de gain de temps, de faire moins de travail. Autrement dit, c'est un choix bas de gamme. Une fois qu'on a commencé ainsi, pourquoi ne pas le faire aussi sur le reste ? (bacler l'éventuel service en ligne qui sous tend l'app ? bacler le support ,etc)
toutes, absolument TOUTES les applications multi-plateformes sont haïes, au moins pour leur interface, par leurs utilisateurs (et oui je pense à toi Zbrush)
Admettez le.
Pleurez en sous la lune
et faites en votre deuil.
@oomu
"comme toutes les solutions multiplateformes depuis la nuit des temps (années 70s)"
J’adhère quasiment à l’ensemble de tes propos mais tu oublies un pan import : l’économie.
Les approches basées sur les technologies web sont appelées à continuer leur avancée, c’est inévitable même si ça donne la gerbe 😉
@ YetOneOtherGit
> oublies un pan import : l’économie
Moi je parle d'économies de bouts de chandelle.
Sur le long terme, ça se paye en général plus que ce qu'on a cru économiser au départ.
@marc_os
"Moi je parle d'économies de bouts de chandelle."
Crois-tu ? C’est justement sur le cycle de vie que la nette différence se fait.
Toujours un enjeu de rapport coût/bénéfice et sur bien des usage le natif n’apporte rien de consistant au regard de ses coûts. 😎
@oomu
"Pleurez en sous la lune
et faites en votre deuil."
L’informatique n’est pas l’amie des utilisateurs.
L’informatique n’a pas besoin qu’on l’aime.
L’informatique est une industrie, pas un canapé cozy.
@valcapri
"Le seul que je n’ai pas testé est Flutter."
Il est très bon et s’améliore vite. Tu devrais essayer.
@fte
"Il est très bon et s’améliore vite. Tu devrais essayer."
Tu vas te faire des amis 😄😄😄
Comme souvent en ces lieux les “détestations” sont radicales et les visions manichéennes.
Et effectivement Fluter ne cesse de s’améliorer et est une réelle solution pour toute une typologie de produits qui n’a pas grand chose à gagner des approches natives 😉
@FloMo
Tout à fait. Un classique
@FloMo
" en arrière dans 2 ans. Classique."
Je ne parierai pas. La migration vers les technologies web n’est pas un phénomène nouveau, il y a beaucoup d’excellentes raisons de le faire, et l’attitude de certains acteurs une motivation grandissante pour migrer avec des doigts dressés.
Ajoutons que Apple l’a même conseillé à diverses occasions.
Et le marché natif macOS est moribond depuis longtemps.
Aujourd’hui la question de quelle technologie adopter pour tout développement doit être posée, et le natif est très souvent la dernière option. C’est devenu une bonne pratique de l’industrie.
@fte
"Et le marché natif macOS est moribond depuis longtemps."
La dynamique du marché des applications sur ordinateur personnel est atone depuis longtemps toute plateforme confondues.
C’est un marché fortement consolidé autour de quelques acteurs historiques où les positions sont figées et où les nouvelles offres ont bien du mal à exister.
Et l’écrasante part des nouveautés se résume finalement à des clients de solutions Internet/Web/Cloud qui se prêtent fort bien à des approches reposant sur des technologies Web.
Strictement rien de spécifique au Mac sur ce constat 😉
@fte
Encore une fois, les 2 seules technologies qui ont tenu leurs promesses sont le natif et le web.
AirBNB a fait la promotion de RN à tout va : retour au natif au bout de 2 ans.
Betclic a même fait des vidéos avec Microsoft pour faire la promotion de Xamarin : ça n’a pas tenu 6 mois.
Mieux vaut maîtriser (et encore, le mot est excessif par nature) la couche technologique et y ajouter ses propres procédés d’industrialisation.
@FloMo
"Encore une fois, les 2 seules technologies qui ont tenu leurs promesses sont le natif et le web."
Quelle promesses ?
Les promesses techniques ou les promesses business?
Tu as conscience des volumes financiers et des success-story reposant dès aujourd’hui sur du non natif?
La pierre de touche au final ça reste le résultat financier pas l’élégance technologique 🤑
@YetOneOtherGit
> Tu as conscience des volumes financiers et des success-story reposant dès aujourd’hui sur du non natif?
Pour avoir travaillé avec des boites qui font des millions de revenu annuel via l’App Store, aucune n’est sur de l’hybride. Ils ont besoin d’une constance. Les projets sont planifiés un an à l’avance : pas le temps de vérifier qu’un plugin existe pour répondre à un besoin. Si ça fonctionne chez le concurrent, ça doit fonctionner chez nous. Point.
@FloMo
"Pour avoir travaillé avec des boites qui font des millions de revenu annuel via l’App Store, aucune n’est sur de l’hybride"
Et tu imagines que tu peux tirer des conclusions de portée générale de ça? 😳
Je suis surpris de cette obstination à ne pas vouloir voir une vérité qui te dérange 😉🖖
@YetOneOtherGit
Quand ça fonctionne, j’en conclus que c’est la bonne méthode.
Et quand ça ne fonctionne pas, j’en conclus l’inverse.
Et quand je vois les plus grands promoteurs des technologies hybrides, soutenus par ceux qui les conçoivent, faire un virage à 180°… je me dis qu’il y a un schéma. En effet.
Après, à vrai dire, ça m’importe peu : réécrire des apps hybrides en natif est un business lucratif car la dimension d’urgence entre en ligne de compte. Et ça fait augmenter les tarifs.
Mais c’est du gâchis : je préfère contribuer à des améliorations. Typiquement, optimiser l’industrialisation pour diminuer les coûts et augmenter la capacité d’innovation : ça c’est intéressant. On part d’une base solide qu’on améliore. Et ça fonctionne très bien.
@FloMo
Encore et toujours: ta vision personnelle ne couvre qu’un petit pan des réalités de l’industrie et tes raisonnement sont biaisé en toute bonne foi 😉🖖
@YetOneOtherGit
Ma vision s’appuie sur les témoignages externes (AirBnB, Betclic, et autres) et sur la réalité du terrain. Ça fait 13 ans et des dizaines d’entreprises de toute taille que je côtoie.
C’est pas comme si j’avais fait ma carrière toujours au même endroit.
Je n’ai pas eu que des success stories, mais les recettes de l’échec récurrentes sont souvent les mêmes :
- peu de budget
- beaucoup d’ambition (iOS + Android sur 25 generations pour capter le milliard d’utilisateurs, avec le max de fonctionnalités)
- et il en résulte des appuis multiples mais très faibles.
Et bien sûr, beaucoup s’appuient sur l’hybride. C’est la majorité du marché. Et la majorité des échecs.
@FloMo
"C’est pas comme si j’avais fait ma carrière toujours au même endroit."
Tu as visiblement fait ta carrière toujours sur les mêmes enjeux de production et de technologies 😉
Avec un immense respect et beaucoup de sympathie, comme bien des dev tu as une vision partiale et biaisée de ce qu’est le business.
Tu es dans un classique biais de confirmation permettant un plaidoyer pro-domo.
Ce n’est pas bien grave et comme tu sembles ne pas être dans une démarche entrepreneuriale de création d’offres ce n’est pas bien gênant. 😉
Prenons RDV à un horizon de cinq ans pour voir quel sera la répartition des offres entre natif et non-natif 😉🖖
@FloMo
"Et bien sûr, beaucoup s’appuient sur l’hybride. C’est la majorité du marché. Et la majorité des échecs."
Dans l’océan des échecs informatiques, qu’ils soient natifs ou non, tu ne penses pas que ce soit attendu que la majorité des échecs se retrouvent dans la majorité des développements ?
Et tu tires une conclusion sur cette base ?
Le web n’est pas une plateforme magique qui empêche tout échec. Mais c’est la plateforme qui fonctionne partout.
@fte
“Dans l’océan des échecs informatiques, qu’ils soient natifs ou non, tu ne penses pas que ce soit attendu que la majorité des échecs se retrouvent dans la majorité des développements ?”
Il est d’ailleurs intéressant de noter que l’écrasante majorité des échecs informatiques ne sont pas le fruit de choix de technologies, de langage, de Framework …
@FloMo
"Quand ça fonctionne, j’en conclus que c’est la bonne méthode.
Et quand ça ne fonctionne pas, j’en conclus l’inverse."
C’est une méthode. Une extrêmement mauvaise méthode, mais ça reste une méthode. C’est aussi valable que de lever un doigt mouillé.
Ce ne sont que des cas isolés dans une vaste industrie, examinés avec un seul paramètre binaire môrche - marche pô.
Comprenons-nous bien : si ça te réussi, j’en suis très heureux.
Mais ça ne représente pas l’industrie et ses tendances larges.
@YetOneOtherGit
"Je suis surpris de cette obstination à ne pas vouloir voir une vérité qui te dérange 😉🖖"
Surpris ? Le message est pourtant constant depuis longtemps.
@fte
"Surpris ? Le message est pourtant constant depuis longtemps."
C’est mon côté naïf: le faisceau de faits est tellement inévitable que je suis toujours dubitatif face aux dénis ☹️
Et c’est d’autant plus gênant que pour préparer l’avenir un entrepreneur doit absolument accepter de se confronter aux réalités.
Je vois toute une communauté fort sympathique aller dans le mur faute d’accepter de s’adapter aux changements de paradigme et même d’accepter de le voir.
Cela m’attriste 🥺
Au passage bravo pour avoir toi été capable de faire le pivot sur ton activité sans inutile dogmatisme 👏👏👏👏
@YetOneOtherGit
"Au passage bravo pour avoir toi été capable de faire le pivot sur ton activité sans inutile dogmatisme 👏👏👏👏"
Je suis un fanboy. Mais je ne suis pas fanboy d’une marque ou d’une entreprise. Je suis un fanboy généraliste, un fanboy de toute technologie excitante. Je suis un fanboy pragmatique.
Si j’ai commencé ma carrière d’indépendant puis d’entrepreneur dans la sphère Apple, c’était pour des raisons de design de plateforme et d’attention au détail et d’orientation vers l’utilisateur certes, mais aussi et surtout peut-être - parlant de business - parce que je n’avais que très très peu de concurrents dans mon secteur de choix. J’ai pu m’y créer une place et une réputation sans avoir à batailler agressivement, au contraire même, dans un esprit de collaboration avec les quelques prestataires de ma région.
L’iPhone j’y suis allé parce qu’il y avait de la clientèle en pagaille et très peu de prestataires au début, mais sans excitation particulière. Je n’ai il faut bien le reconnaître jamais aimé iOS.
J’ai toujours mes idéalismes. Je ne prends pas mes décisions business sur cette seule base. Je les considère si mes autres critères m’en laissent la possibilité.
J’ai quelques big no no cependant : pas d’industrie du tabac, ou d’armement, ou du pétrole, pour des idéalismes différents.
@fte
“J’ai toujours mes idéalismes. Je ne prends pas mes décisions business sur cette seule base. Je les considère si mes autres critères m’en laissent la possibilité.”
👏👏👏Nous sommes assez proche sur cette posture.
C’est d’ailleurs ce qui fait que pas mal de monde ici à du mal à comprendre mes positions: entre celle de l’entrepreneur pragmatique acceptant les règles du jeu et mes convictions personnelles.
@FloMo
"Point."
🤣
Dans des niches, il peut y avoir des "Point.". Pendant un temps. Mais dans l’immense industrie, il n’y en a aucun. Il y a juste des $.
@fte
"Dans des niches, il peut y avoir des "Point.". Pendant un temps. Mais dans l’immense industrie, il n’y en a aucun. Il y a juste des $."
Notre camarade FloMo et assez représentatif de ces dev qui ne veulent surtout pas penser business et voir en face les réalités du business, il est archétypal et symptomatique. 😉
@YetOneOtherGit
"Notre camarade FloMo et assez représentatif de ces dev qui ne veulent surtout pas penser business et voir en face les réalités du business, il est archétypal et symptomatique. 😉"
Soyons pragmatiques. Développeur et businesspeople sont deux jobs très différents et de compétences très différentes. C’est difficile de porter deux casquettes si différentes avec compétence et de les faire cohabiter. Peu de gens y arrivent. Il faut la plupart du temps savoir s’entourer pour pallier à ses propres manques, ce qui est une autre casquette très particulière et exigeante.
Pages