Qui n’essaie pas de grignoter des parts de marche à Microsoft Office? Les initiatives viennent de toutes part aussi de startups avec des alertnatives logiciels (open office) ou des solutions en ligne (Zoho par exemple ou Zimbra) mais aussi de Google (Google docs). Sans oublier la long liste de OS en ligne qui disposent également de fonctions pour traiter des documents bureautiques (dont Jooce). Une nouvelle alternative est disponible bien que je n’arrive pas à déterminer sa date exacte de lancement: Officity
Né du travail d’une société belge du nom de Nectil, Officity propose un environnement bureautique 100% en ligne qui intégre les principales fonctions d’une suite bureautique. On y trouve l’équivalent d’outlook ainsi que d’autres outils et accessoires en revanche on n’y trouve pas encore d’équivalent à Word, Excel et Powerpoint pour la création de documents. Ceci dit l’ensemble est bien conçu et peut se configurer simplement. L’interface est rapide ce qui est souvent un reproche fait aux Web OS. Le client email n’accepte pas la possibilité de comptes IMAP et je n’ai pas vu d’option pour accéder à ses fichier hors lignes (un équivalent de Google Gears).
Le service est payant (5 à 8 euros par mois selon la formule) et il existe également une version serveur pour les entreprises désireuses d’héberger chez elles leurs applications. Le service est disponible en anglais et en français. Officity est construit sur la plateforme Sushee un autre produit de Nectil. Vous pouvez l’essayer avec 30 jours gratuits.
“en revanche on n’y trouve pas encore d’équivalent à Word, Excel et Powerpoint ”
Ces 3 softs constituent l’épine dorsal des suites bureautiques,
Pourquoi ce passer de Microsoft Office qui est la référence planètaire ??
Re,
Franchement, je me voit mal lacher Office 2007 pour une solution alternative, ça n’a aucuns sens !!
Office est une excellente solution mais a deux inconvenients
- il est payant
- il n est pas concu pour la collaboration
Don’t you know http://zoho.com/
A new site who seem to concurrence Google Online “Office Box”
Hello,
Quelques petites précisions sur ce billet:
> bien que je n’arrive pas à déterminer
> sa date exacte de lancement
La solution à été commercialisée début 2005 sous la forme d’une solution expert (Framework gestion de contenu + plate-forme e-Marketing) et sous le nom de Nectil.
Nous avons finalisé la version Bureau Virtuel en 2007 sous le nouveau nom d’Officity, et ce n’est qu’après une période de test chez nos utilisateurs que nous avons lancé ce produit sous sa nouvelle forme en ce beau mois de mai 2008.
L’environnement est donc éprouvé depuis plus de 3 ans maintenant et propose un OS robuste loin des aspects gadget de certains bureaux virtuels (je dis bien certains, pas tous!).
Sinon, nous ne nous positionnons pas versus le trio doc-xls-ppt mais bien comme une suite collaborative (donc plutôt Outlook/Exchange/Messenger) et de gestion d’activité grâce à Sushee, un Office Management Framework, XML et open source. Sushee permet de créer tout type d’applicatifs web qui utilisent les mêmes données que Officity (et vice versa).
Sinon, nous avons en développement une application “Documents” qui permet de gérer les documents écrits factuels (lettres, fax, etc.).
Il faut bien se placer dans le contexte des besoins de tout un chacun: l’avantage d’un bureau virtuel comme celui n’a de sens que par la centralisation naturelle des données, l’architecture des données (il n’y a pas d’architecure logique des données dans Office…), l’indépendance par rapport à du hardware et/ou un lieu, etc.
Un indépendant qui travaille chez lui et qui ne se déplace qu’une fois par mois n’en aura sans doute aucune utilité contrairement à un freelance qui travaille dans plusieurs agences, ou une TPE et PME qui à des commerciaux sur la route ou qui pratique le télé-travail.
A propos de déplacement, Officity Mobile pour iPhone est en Beta et accessible dans chaque Officity (même la version d’essai)
@François:
pourriez-vous SVP nous donner qq stats sur de vos utilisateurs, notamment sur leurs systèmes d’exploitation, et sur les taux d’utilisation des différents “sous-services”?
Le problème du “collaboratif” c’est qu’il n’existe pas de killer-app’, qui permette d’englober la totalité du marché. Et qu’il ne peut en exister, à moins que plus aucune nouveauté ne sorte…
Le développement de standards (XMPP, etc.) n’en sont encore qu’au bablbutiements.. et rien ne dit que tous els éditeurs produiront du XML “standard”..
Donc la segmentation ne peut se faire que par usage, comme vous le décrivez très bien.
@Guillaume
Nos utilisateurs sont pour 90% sur Windows, 9% sur Mac, et 1(mini)% sur Linux.
L’utilisation des différents applicatifs intégré n’est encore représentatif que de la version expert dont la solution est issue, à savoir pour 75% le quatuor Shaper (gestion de contenu) - Files (gestion des fichiers) - Spray (e-marketing) - Contacts.
Les nouvelles applications de bureau virtuel récemment lancées ont été adoptées rapidement par les petites structures pour les mails et l’agenda, mais je ne pense pas que nos autres clients plus important y passeront pour autant: leur besoin d’origine était des applications taylor-made, pas du bureau virtuel.
Je suis d’accord qu’il n’existe pas de killer-app’. Je dirais même plus qu’il ne peut en exister: à chaque métier ses besoins! C’est bien pourquoi nous avons articulé Officity avec Sushee, pour avoir cette ouverture qui permet de créer les applications par besoin (bon, cela demande une intervention d’un développeur bien sûr, mais comme Sushee est en GPL (http://sourceforge.net/projects/sushee/), nous espérons que des applicatifs puissent être mis à disposition de la communauté). Pour info, il y a déjà des agences qui développent leur propre appli sur base de Sushee sans passer par Officity, donc en restant à 100% dans le modèle opensource.
Sinon, pour ce qui est des standards, cela ne nous inqiuète vraiment pas… l’xml est en soit un standard suffisemment universel et complètement inter-opérable grâce à l’xsl. Nous avons inclus l’xliff (standard oasis pour traducteur) car c’est très proche de la problématique de gestion de contenu, mais pour le reste, des feuilles de styles xsl de convertion sont amplement suffisantes pour réconcilier les formats (merci Mic…oft de nous avoir imposé un deuxième format xml de bureautique… cela aurait été trop simple avec un seul dont toutes la communauté informatique était déjà satisfaite
).
@François:
“A chaque métier son besoin”: les métiers interagissant les uns avec les autres, on se retouve vite avec une multitude d’appli, plus ou moins redondantes, plus ou moins compatibles, plus ou moins connues, etc.. Bref: le “brol” (comme dirait certaine Liégeoise…
C’est ce qui commence à caractériser la situation actuelle.
Par ailleurs, tous ces standards portent sur la structuration des données en vues de leur échange… mais de nombreuses données n’ont pas forcément besoin d’être échangées.
Ils suffit parfois juste d’arriver à les “faire voir”. Par exemple un plan de chantier d’un architecte, lequel communiquerait à distance avec son client: un simple outil de déport d’écran est bien suffisant, pas besoinq ue le client possède la même appli que l’architecte, ni même la visionneuse associée à l’appli…
C’est la grande promesse des outils de desktop sharing.
Mais ils ne sont pas suffisants en eux-mêmes: il leur manque la dimension “groupware” (comme celle que vous offrez) et celle de la gestion “asynchrone”.
Alors quoi: aggréger tout cela dans une seule et même appli? Auquel cas al chance est aux solutions “mono-fonction” qui se laissent intégrer facilement?
Le problème me semble essentiellement humain, lié à l’usage, plus que techno. Votre point de vue d’éditeur m’intéresserait diablement sur ce point précis..
@Guillaume
Oufti (comme dirait une autre liégoise;) ) On lance un sacré débat là!
Je ne pense pas que l’humain cantonné dans son rôle d’utilisateur soit plus déterminant que le processus général dans lequel il se place (qui est aussi un autre rôle) ou l’activité qu’il génère.
Un exemple classique: Photoshop. Pour certain un monstre de complexité inaccessible, pour d’autres un bête marteau avec lequel ils font strictement se qu’ils veulent. Le besoin créé la fonction mais aussi l’utilisation: l’interface la plus simple du monde n’est pas un objectif en soi, mais produire la plus belle image à placer dans une affiche oui.
A l’opposé, les cours d’informatique les plus prisés ne sont pas sur la programmation orienté objet ou sur le design pattern, mais bien sur comment utiliser Outlook!
Et l’entre-deux, la masse la plus importante, fonctionne comme tout un chacun: par habitude. Et c’est normal et naturel, il ne faut pas aller contre cela. Et c’est un leurre de dire que les applications les plus utilisées sont les plus utilisables: j’ai testé des Facebook, Blogger, etc autres, et je devait chercher 5 minutes pour trouver chaque actions que je voulais réaliser…
Et c’est un soucis réel pour nous éditeurs: quelque chose n’est pas clair? ne fonctionne carrément pas? c’est normal, on fait avec (merci “fenêtres”…). Très peu d’utilisateurs nous contactent pour nous soumettre des choses peut claires, des bugs, etc.
A nos yeux, la compréhension du contexte est plus importante que l’application elle-même. Même si l’humain peut s’habituer à tout et n’importe quoi, sans compréhension il ne pourra pas dompter son environnement, il s’adaptera à lui. Et comme il y a des milliers de manière de faire les même choses, autant comprendre le fond, pour la forme, ça coulera!
Les standards sont là pour faciliter les choses et permettent enfin de pouvoir au mieux s’adapter aux besoins: une grosse application agrégative? plusieurs applications spécialisées? Une seule application développée sur mesure? Toutes ces options se valent, tout dépend du contexte. Et il est bien sûr possible d’arriver à du brol ! C’est pour cela que nous conseillons de préférence de développer sur base d’un Framework, et si cela ne se justifie pas d’un point de vue économique ou pratique d’agréger des applications spécialisées comme si il s’agissait de processeurs (entrée-sortie).
@François:
ça a le mérite d’être clair… et cela demande réflexion.
Merçi d’avoir pris la peine d’expliquer cela !
@François:
si je comprends bien, le point de vue de l’éditeur est de “saupoudrer” l’appli de différentes fonctions, afin de couvrir le spectre des usages et des différents niveaux de capacité de ses utilisateurs.
Le marketer (mercaticien.. arf) trouvera dans tout cette abondance entre les différents applis une confusion peu propice à la lisibilté des offres.
Qui l’emporte? Ou sinon, comment concilier les deux: multiplicité ET génération de lisibilté pour les prospects?
@Guillaume
C’est plus subtil que saupoudrer… l’architecture des données est l’élément clé. Selon les approches, un “objet” peut aussi être une fonctionnalité, un module, voir une application complète! Tout dépend l’angle d’attaque.
Concrètement, la résolution de cette problématique à précédé pour nous les applicatifs: nous avons passé des mois à conceptualiser le modèle des données avant d’avoir la moindre interface (c’était en… 2003!). Et la gageure était de concillier le (ultra)générique et le spécifique.
La réponse à été la suivante: des objets “verticaux” natifs (le spécifique) et dérivés (le générique) ayant chacun des propriétés intrinsèques, et des macro-propriété horizontale pour lier le tout. La combinaison de ces trois vecteurs offre des possibilités énormes de telle manière qu’il suffi parfois de simplement configurer pour créer la fonctionnalité.
Le Framework Sushee est la résultante de ce travail, et Officity une partie visible de l’Iceberg.
Il ne suffi donc pas de saupoudrer de sucre, il faut offrir le cadre du saupoudrage, à savoir une bonne gaufre de liège bien structurée
N’oublions pas ulteo
OpenOffice disponible dans un navigateur.