Apple et SAP : un partenariat pour imposer iOS dans les entreprises
Petite surprise en ce jour férié, Apple vient d’annoncer un partenariat avec SAP pour « révolutionner le travail sur iPhone et iPad ». Il s’agit de combiner les applications iOS avec les solutions de la plateforme HANA de SAP. Un nouveau kit de développement ainsi que des formations sont prévues pour faire en sorte que les développeurs et les entreprises puissent concevoir des apps mobiles natives taillées pour leurs usages.
« Ce partenariat va transformer la manière dont l’iPhone et l’iPad sont utilisés en entreprises », se réjouit Tim Cook, « en associant l’innovation et la sécurité d’iOS à la grande expertise de SAP en matière de logiciels de gestion». Le CEO d’Apple rappelle que 76 % des transactions professionnelles impliquent l’un des systèmes SAP.
Le HANA Cloud Platform SDK va permettre aux quelques 2,5 millions de développeurs exploitant des solutions SAP de bâtir des apps natives pour les terminaux mobiles d’Apple et de leurs caractéristiques — notamment Touch ID, Location Services, et les notifications. Fiori, le langage de conception de SAP qui sert à adapter des applications mobiles, va intégrer des éléments iOS. La SAP Academy va livrer des outils pour tirer profit de ce kit de développement. Tout cela sera mis en place avant la fin de l’année, tandis que SAP va mettre le pied à l’étrier en développant des applications métier en utilisant Swift.
Les applications et services de SAP sont utilisés par 310 000 clients des secteurs public et privé partout dans le monde. Cette nouvelle offensive vers le monde de l’entreprise renforce les positions d’Apple qui, avec son partenariat avec IBM, y a déjà un pied solide.
Ha cool. Moi qui bosse tout les jours sur sap
Un peu d'apps native dans ce monde plein de clouds et de SaaS, ça fait tjrs plaisir.
@reborn :
D'ailleurs samsung n'a pas aussi un partenariat avec SAP ?
Deux contrats SAP achetés
Un iPad Pro offert :-)
Même si je ne suis pas concerné je trouve que c'est une très bonne décision. Ca évite les bidouillages internes !
Je trouve ça assez curieux. SAP proposant des solutions assez lourdes, puissantes et coûteuses, elles se destine surtout à des groupes assez important. On s'éloigne un peu de l'image des petites PME, auto-entreprise, et start-up (en vidéo, image et design) dont Apple est souvent associé :-)
@romainB84 :
Surtout là on parle SAP HANA, pas R/3. La plateforme SAP HANA permet déjà de faire des webapps, là l'idée est de proposer une application native. SAP HANA est une super plateforme pour faire du BI, même décorrélée d'un SAP transactionnel. Faire des applications natives liées à SAP HANA pourrait être une raison de choisir des iPad dans une entreprise plutôt que qu'une autre tablette.
oui ! d'où, du coup, l'intérêt de cette association pour Apple : pénétrer des marchés qui lui sont fermés.
romainB84
Il propose du cloud computing, notamment sur le big data et l'interface de gestion ne nécessite rien de plus que ce que peut faire un iPad...
Ça me fait rire
Parce qu'en interne on n'utilisait rien vraiment développé pour iOS ou OSX
Apple a un CRM dérivé de SAP mais en web app, donc utilisable depuis n'importe ordi
RomainB84
SAP a aussi des solutions pour PME et TPE. Les solutions SAP business One existent depuis au moins 5/6 ans
Bon point
La première question à se poser c'est la valeur ajoutée technique d'une app iOS par rapport à une web app.
L'intérêt de faire une app native c'est surtout d'avoir accès aux capteurs de l'appareil comme le GPS, les acceleromètre etc.. Et éventuellement à des api performantes comme pour les jeux.
Mais pour faire un client qui se connecte à un système de gestion, c'est n'importe quoi.
Et en plus, on perd l'aspect compatibilité universelle d'une web app.
Mais bon, dans ce genre de choses les enjeux ne sont pas que techniques.
Je le sais trop bien pour avoir eut des clients dont la seule motivation était d'avoir une app sur l'app store, juste pour se la péter car rien ne justifiait ce choix, ni techniquement ni économiquement.
"L'intérêt de faire une app native c'est surtout d'avoir accès aux capteurs de l'appareil comme le GPS, les acceleromètre etc.. Et éventuellement à des api performantes comme pour les jeux."
Je ne suis pas d'accord. C'est pas "éventuellement", c'est "surtout" pour les APIS performantes pour les jeux, avec l'accès direct au CGU.
Parce que ca fait un bail que la géoloc et les accéléromètres sont dispos sur les apps non natives.
Elles ont aussi, grâce au WRTC, accès aux flux binaires en temps réel et en P2P ( chat vidéo, fichiers, ... ) même Safari Mobile fait un blocage dessus pour favoriser les solutions maisons, mais c'est une autre histoire.
"Je le sais trop bien pour avoir eut des clients dont la seule motivation était d'avoir une app sur l'app store, juste pour se la péter car rien ne justifiait ce choix, ni techniquement ni économiquement"
Pareil ici :)
A mon avis, ce que cherche Apple, c'est un sésame pour accéder aux gros comptes.
Et un ténor du marché qui vient te serrer la main, ca vaut carrément mieux que de juste rajouter le suffixe "pro".
C'est aussi une belle opération de com pour le ténor en question qui ne sait peut être plus quoi inventer pour faire parler de lui.
Ça fait 10 ans que je fais des backoffices.
Les patrons sont des hommes, et les hommes sont des enfants. Ils aiment les jouets.
Des camemberts, des courbes, et des histogrammes qui se mettent à jour en temps réel. Des notifications quand le stock dépasse X et quand il descends sous Y. Et une app sur le store Z et le device Truc.
L'Apple Watch aussi est un jouet. En fait, Apple est un fabriquant de jouet, et pas des révolutionnaires qui changent le monde comme le prétendait Steve Jobs.
Ceux qui changent le monde c'est Google, qui lance DeepMind sur 1.6 millions de patients britanniques, C'est Elon Musk qui crée des voitures électriques autonomes qui ont la patate d'une Ferrari, et qui fait atterrir des fusées. Et qui est en train de planifier une mission sur Mars.
@françois bayrou :
J'ai bien ri en lisant ce message et surtout la fin. C'est l'année des 40 ans d'Apple et l'on trouve de nombreuses rétrospectives des créations et apports majeures de cette société qui contredisent ton avis.
L'apport d'Apple, c'est essentiellemtn la facilité d'utilisation et l'expérience utilisateur.
Je suis d'accord avec FB, ça a beaucoup à voir avec l'univers enfantin et le plaisir de jouer.
@ macinoe : « L'apport d'Apple, c'est essentiellemtn la facilité d'utilisation et l'expérience utilisateur. Je suis d'accord avec FB, ça a beaucoup à voir avec l'univers enfantin et le plaisir de jouer. »
Absolument pas d’accord : la facilité d’utilisation et l’expérience utilisateur, ça a tout autant à voir avec l’univers du travail !
Malheureusement, beaucoup de développeurs et utilisateurs d’applications (et sites web portant le nom d’applications) « sérieuses » sont totalement inconscients de ce fait, voire sont totalement opposés à l’idée qu’une application « sérieuse » puisse être facile à utiliser.
Et c’est comme ça qu’on souffre tous les jours faces à de sombres bouses « sérieuses » (dont on n’ose chiffre le coût en temps perdu et erreurs résultant de leur interface anti-ergonomique).
Les développeurs ne vivant pas d'amour et d'eau fraiche, ils font ce que leurs clients ou employeurs les payent à faire.
Hors, dans beaucoup de cas, le client n'a pas franchement les moyens de payer beaucoup plus que le coût de la partie purement fonctionnelle (et souvent c'est même déjà sous-évaluée), alors quand le client refuse de payer le côut supplémentaire pour penser mieux l'ergonomie, le développeur ne se transforme pas en bénévole par magie pour le faire sur son temps libre...
A l'inverse, il y aussi une tendance à surjouer l'importance de la facilité d'utlisation qui abouti non pas a simplifier l'usage mais à simplifier les fonctions (en réduire le nombre, en particulier). Pas de miracle, y'a que 24h dans une journée, pour le même coût il faut arbitrer entre fonction et ergonomie. Pour avoir plus des 2, cela coûte fatalement à quelqu'un plus...
SI c'était facile et gratuit de faire un soft complexe mais facile d'usage, tous les softs complexe seraient *déjà* facile d'usage.
Rendre responsable les développeurs de la réalité économique dans la conception des logiciels, c'est comme rendre les maçons responsables du prix du m3 de béton.
@ byte_order : « Les développeurs ne vivant pas d'amour et d'eau fraiche, ils font ce que leurs clients ou employeurs les payent à faire. »
Excuse trop facile. Certes, le développeur sera rarement payé pour passer du temps à améliorer l’ergonomie après coup.
Il doit donc, autant que possible, intégrer une ergonomie correcte (voire plus) du premier coup, au cours du développement. Sans avoir la possibilité d’y consacrer un long temps de réflexion avant, ni un temps encore plus long de correction a posteriori.
Et c’est là qu’on distingue ceux qui sont doués dans ce domaine de ceux qui sont mauvais. Tous les développeurs ne sont pas égaux.
Rendre le client / l’employeur seul responsable d’une ergonomie désastreuse, c’est comme rendre le fournisseur de béton responsable d’un mur mal monté. ;-)
> Excuse trop facile.
Bah tiens. C'est pas une excuse, mais l'économie de marché.
> Certes, le développeur sera rarement payé pour passer du temps à
> améliorer l’ergonomie après coup.
> Il doit donc, autant que possible, intégrer une ergonomie correcte (voire plus)
> du premier coup, au cours du développement.
Et évidement, il ne sera pas payé non plus pour ce travail supplémentaire que le client ne veut ou ne peut pas financer.
Et ne parlons pas du cycle de vie du développement qui ne permet pas toujours (et de moins en moins d'ailleurs) d'avoir une vision au départ de l'ensemble des fonctions à la fin, et donc des concepts ergonomiques qu'il faudrait mettre en place dès le départ... en aveugle.
> Et c’est là qu’on distingue ceux qui sont doués dans ce domaine de
>ceux qui sont mauvais. Tous les développeurs ne sont pas égaux.
Non. Y'a les bénévoles qui font donc plus que les autres mais gratuitement et ceux qui doivent vivre de leur travail, et qui font font donc ce que le client a demandé *et* est prêt à payé.
Et, oui, un fournisseur de béton foireux n'aidera clairement pas à monter un mur solide et conforme aux attentes.
Cf les déboires de l'EPR avec ses fournisseurs de béton...
L'ergonomie, cela se paye, d'une manière ou d'une autre. Soit à la conception, soit à l'usage, par son absence. Elle n'est pas gratuite, jamais. Et elle ne peut pas l'être.
Et les développeurs, même les très bons, ne vivent pas d'amour et d'eau fraîche. Leur temps est aussi de l'argent, comme chez n'importe quel autre. Juste plus cher.
Pourtant, force est de constater que beaucoup de clients n'ont pas l'argent pour s'offrir et les fonctions dont ils ont besoins et l'ergonomie pour les utiliser de la meilleure façon possible.
@ byte_order : « Bah tiens. C'est pas une excuse, mais l'économie de marché. »
Je parlais d’utiliser la réalité de l’économie de marché pour justifier des développements foireux. C’est ça, l’excuse trop facile.
« Et évidement, il ne sera pas payé non plus pour ce travail supplémentaire que le client ne veut ou ne peut pas financer. »
Je ne parlais pas de travail supplémentaire. Je parlais de faire du mieux possible le travail qu’on doit de toute façon faire.
« Et ne parlons pas du cycle de vie du développement qui ne permet pas toujours (et de moins en moins d'ailleurs) d'avoir une vision au départ de l'ensemble des fonctions à la fin, et donc des concepts ergonomiques qu'il faudrait mettre en place dès le départ... en aveugle. »
ÇA, c’est un bon argument (le reste, pas du tout).
Mais ce n’est pas toujours le cas, heureusement.
« Y'a les bénévoles qui font donc plus que les autres mais gratuitement et ceux qui doivent vivre de leur travail, et qui font font donc ce que le client a demandé *et* est prêt à payé. »
Et dans cette deuxième catégorie, il y a — comme je l’ai expliqué — ceux qui font mal leur boulot, ceux qui le font bien, et ceux qui le font encore mieux. Le tout dans le même temps, pour la même somme d’argent.
Tous les développeurs ne sont pas égaux.
« Leur temps est aussi de l'argent, comme chez n'importe quel autre. Juste plus cher. »
Pas si cher que ça, hélas. Je le trouve plutôt sous-évalué, le temps-développeur. :-(
« Pourtant, force est de constater que beaucoup de clients n'ont pas l'argent pour s'offrir et les fonctions dont ils ont besoins et l'ergonomie pour les utiliser de la meilleure façon possible. »
En effet. C’est pour ça que je leur souhaite de tomber sur un développeur réellement bon, qui sera capable de ne pas négliger l’ergonomie au cours du développement.
@françois bayrou :
Ah géniaux tes exemples. DeepMind, ce truc scandaleux qui va faire disparaître le secret médical en Angleterre et mettre les données de santé des citoyens à disposition de Google qui pourra les revendre à qui paiera comme des assurances pour faire payer les "personnes à risque", Musk, celui qui s'est enrichi par la vente (PayPal) mais emprunte des millions à l'ETAT qd il est dans la merde (cherchez l'erreur).
@macinoe :
La valeur ajoutée d'une application native par rapport à une web app se trouve peut être aussi dans les aspects de sécurité et de confidentialité.
Ah bon ? Une web app ne peut être ni sûre, ni confidentielle ?
Expliquez-moi ça.
@ Domsware : « La valeur ajoutée d'une application native par rapport à une web app se trouve peut être aussi dans les aspects de sécurité et de confidentialité. »
Dans l’aspect qualité, aussi.
Je ne vois pas en quoi l'aspect "natif" apporterait comme par magie une application de meilleure qualité, de facto.
Y'a des milliers d'applications natives immondes et des milliers de webapp bien foutues.
Mieux intégrées à la plateforme, éventuellement plus performantes, oui.
Mais de meilleure qualité ou de sécurité, franchement, je vois pas par quelle magie.
@ byte_order : « Mieux intégrées à la plateforme, éventuellement plus performantes, oui.
Mais de meilleure qualité ou de sécurité, franchement, je vois pas par quelle magie. »
Ben le fait d’être mieux intégrées à la plateforme et plus performantes, c’est déjà en soi être de meilleure qualité.
Mais au delà de ça, il n’y a pas de magie. Il est juste évident qu’il est plus facile de faire une application de qualité en utilisant des frameworks prévus pour ça, plutôt qu’en détournant le principe des sites web pour tenter de produire quelque chose ressemblant à une application, mais ne fonctionnant pas vraiment de la même façon, tout en ne fonctionnant plus vraiment comme un site web (« oups ! Il ne fallait pas utiliser le bouton "page précédente" du navigateur ? ») bien que restant piégée dans la fenêtre d’un navigateur web.
Et quand une approche permet plus facilement que l’autre d’arriver à une bonne qualité, on a donc une probabilité plus élevée d’atteindre un meilleur niveau de qualité avec la première approche qu’avec la seconde. Le fait qu’on puisse trouver des exemples de trucs foireux développés avec la première et de trucs réussis développés avec la seconde ne change strictement rien à ça et n’est que du vent.
@macinoe :
Vous oubliez 2 autres intérêts d'une app native :
- pouvoir créer une meilleure interface, plus intégrée et utilisant toutes les fonctions matérielles de l'IHM ;
- avoir cette interface en local dans la mémoire de l'appareil, donc ne pas la charger depuis le serveur, réduisant ainsi la charge sur ce dernier, ainsi que sur le réseau — d'autant qu'on parle ici d'appareil mobile connectés en Wifi.
@macinoe :
Ta webapp elle permet de travailler sans connexion réseau ?
Je ne sais pas si c'est un objectif, mais une App native peut te permettre de travailler hors ligne et de sauvegarder / synchroniser tes données sur le serveur plus tard quand tu as du réseau. Par exemple, pour un système de suivi de livraisons pouvoir travailler hors ligne peut être un atout. Imagine le livreur qui ne peut pas faire ses saisies parce qu'il se trouve quelque part où il n'a que du Edge ou même rien. Juste un exemple.
@marc_os :
Exact pour l'utilisation hors connexion. C'est aussi un critère qui peu être déterminant.
Dans une architecture client serveur classique, un client est forcemment connecté, web app ou pas.
Après il existe des solutions comme indexedDB et il y a même maintenant des API de notification.
Les fonctionnalités existent, en tout cas chez google.
Pour Safari iOS tout est plus compliqué car Apple a toujours tout fait pour défavoriser les web app au profit de son système de client lourd iOS, mais ce n'est pas un problème technique, juste une question de choix stratégique.
On comprends qu'Apple a tout intérêt d'empécher la création des web app et de favoriser les app iOS qu'elle peut monétiser.
L'avenir d'Apple passe également par l'entreprise.
SAP (qui est déjà dans nos ministères) étant un poids lourd, il convient de ne pas le négliger.
Le devenir de l'iPad passe également par là.
Si Apple veut réellement percer dans le monde de l'entreprise, qu'elle commence par annoncer officiellement la fin de support de ses produits.
Le HANA Cloud.... ouais ouais... bof... en France on a déjà le Cyril HANOUNA depuis longtemps, c'est une sorte de mix entre Siri et HANA je suppose.
Une news qui m'a fait vomir un peu de l'intérieur. SAP, c'est lourd, c'est corporate au possible, les apps LoB tristes, le non créatif... un peu l'antithèse de l'Apple d'il n'y a pas si longtemps.
" SAP, c'est lourd, c'est corporate au possible, les apps LoB tristes, le non créatif... un peu l'antithèse de l'Apple d'il n'y a pas si longtemps."
Apple à p't-être glissé dans le contrat quelques exigences sur la qualité de l'interface. :-)
Une news qui m'a fait vomir un peu de l'intérieur. SAP, c'est lourd, c'est corporate au possible, les apps LoB tristes, le non créatif... un peu l'antithèse de l'Apple d'il n'y a pas si longtemps.
@ domsware
La sécurité, la confidentialité, oui. En ce moment tout le monde s'essaie à déverrouiller des iPhone, et certains y parviennent sans l'aide d'Apple !
Attention : ici quand on parle de web app, on parle de Windows web app, tant il est impensable d'utiliser un autre navigateur que celui de Microsoft
Pas mal ce partenariat !
Mouais j'suis un peu déçu qu'il ne s'agisse pas d'OS X. Je bosse depuis peu en bureau et utilise au quotidien SAP sur Windows. C'est une usine à gaz, l'exact opposé de ce qu'incarne l'idéologie de l'intuitivité. Bref, une grosse merde. Moi qui pensais lire une extrême infime chance de voir les vieux PC pourri de mon boulot remplacés un jour par de beaux macs tout neuf!
tssss, attention, y'a un mot portemanteau officiel pour ce type de logiciel : on ne dit pas "grosse merde" mais "progiciel".
"Usine à gaz" reste tolérable, toutefois.
;-)