Les news d'Aspectize : Startup

Déménagement à la Défense

Nico — Mon, 06 Sep 2010 08:46:07 GMT

Après une année passée chez Paris Développement, nous quittons l’incubateur pour intégrer la pépinière de l’Essec Ventures.

Nous retenons de cette année:

la logistique: les locaux, le mobilier, les services, c’est bête à dire, mais un fax et une photocopieuse sont toujours utiles.
les animations nombreuses de l’association Paris Développement: ventes, marketing, RH, financement, networking, juridique, propriété industrielle, les sujets présentés sont nombreux et variés. Les interlocuteurs ont tous une expertise sur leur domaine, et sont aussi là pour faire du business. La formule est bonne, puisque certains sont d’ailleurs devenus nos fournisseurs.
L’accompagnement: mené par les chefs de projets, un point mensuel permet de définir l’avancement sur la R&D, le business, le financement, et tout ce qui touche au développement de la société. C’est très enrichissant d’avoir un moment d’échange sur la stratégie, avec des personnes externes de l’entreprise, qui ont un regard différent, une expérience à partager.
le réseau: c’est sans doute là, que la dimension d’incubateur est la plus importante. Intégrer un réseau, avec des connexions multiples; start-up, business angels, mentors, financiers, experts, c’est toute une communauté qui échange, et des mises en relation toujours très intéressantes. Plusieurs de nos prospects sont directement issus de ces mises en relation.

Puisque la période d’incubation est limitée à un an – nous serions bien restés, mais il faut aussi laisser la place aux autres – je ne peux qu’encourager les start-up de tout poil à postuler, vous ne serez pas déçus (à l’exception du café, seul point noir au tableau, la machine en libre service fait du mauvais café, et nous avons investi dans une machine Nespresso dès le premier jour).

Et maintenant, nous changeons d’environnement.

Tout d’abord le quartier; moins de textile, plus de banquiers, nous sommes en plein cœur de la Défense.

Les locaux sont tout neufs, le CNIT a refait peau neuve, et ce n’est pas désagréable de se trouver dans un lieu comme ça:

La proximité de l’ESSEC Business School en fait un environnement incontestablement plus orienté business.

Organisés en Open Space, et non plus en bureau fermé, l’ambiance de travail sera surement différente.

Enfin, le réseau, d’autres partenaires, d’autres relations à découvrir.

Aspectize MSV = MVC + SOA + ORM + ESB

Nico — Thu, 08 Jul 2010 07:32:00 GMT

Lors de notre élaboration de notre marketing stratégique, une question importante se pose sur notre catégorie; dans quelle catégorie voulons nous apparaître ?

La catégorie est essentielle parce qu'elle permet rapidement à nos interlocuteurs de nous positionner, et d'évaluer notre proposition de valeurs relativement aux autres outils de la même catégorie. Et c'est une question difficile, parce que notre approche est suffisamment différente pour que l'appartenance à l'une d'elle ne saute pas forcément aux yeux.

Aujourd'***, il nous est plus facile de dire dans quelle catégorie nous ne sommes pas. Par exemple, nous nous démarquons fortement des principales catégories des outils de développements:

les Frameworks, qui proposent des API et pour lesquels il est nécessaire d'écrire du code pour les utiliser. Nous n'avons pas d'API (hormis le chargement des données qui nécessitent aujourd'*** d'écrire du code), et nous encourageons à écrire le moins possible de code. Nous réduisons significativement les API .Net à connaître pour développer une Application.
les Générateurs de Code, qui proposent des outils de modélisation, mais dont la sortie est un code à intégrer dans une solution, complété par du code métier et compiler pour donner l'application finale. De ce point de vue, nous sommes plutôt un éliminateur de code.
les AGL, qui propose des boites noires souvent fermées de plus haut niveau qui permettent de développer vite, mais qui vieillissent mal et s'intègrent mal avec l'existant. Nous sommes complètement intégrés à l'environnement .Net.

Si l'on se place du point de vue des briques qui constituent une Architecture d'Entreprise, on peut considérer les catégories suivantes, qui représentent à peu près les règles de l'art en la matière:

les ORM, qui s'apparentent à des Framework ou des générateurs de code pour faciliter l'accès au stockage des données.
les ESB, qui sont plutôt des middlewares, qui facilitent la mise en œuvre d'une SOA.
les Framework MVC, qui sont le modèle le plus répandu pour réaliser l'IHM des applications.

Chacune de ces briques adressent bien des fonctionnalités de l'architecture, que nous adressons également, nous sommes donc un peu tout cela à la fois...

Et pourtant, quand on regarde comment Microsoft nous invite à réaliser ces différentes briques, on s'aperçoit qu'elles nécessitent beaucoup de code pour être implémentées. Cela vient principalement de l'approche orientée objet et du typage fort utilisé à tous les niveaux.

Notre vraie différence est d'avoir choisi une autre approche, ce qui nous permet d'éliminer l'essentiel du code à écrire, avec une séparation bien plus nette entre les différents éléments (vu qu'il n'y a plus de code pour les lier). Nous avons permis d'unifier toutes les briques de l'Architecture et de faire tout-en-un, beaucoup plus facilement.

Notre Modèle relationnel permet de définir les fonctions de mapping avec le stockage, ce qui offre les bénéfices d'un ORM, sans les inconvénients du mismatch entre le monde objet et relationnel. Meilleur mapping (pas de soucis pour les relations N-N par exemple), requêtage beaucoup plus facile (extraction de graphes et lazy loading trivial), support du n-tiers.

Nos Vues sont bindées dynamiquement sur le Modèle, ce qui correspond bien à la logique du MVC. Notre moteur de binding est en quelque sorte le C, le contrôleur universel, qu'il n'est pas nécessaire d'écrire, et avec lequel une logique déclarative suffit. Les vues sont des contrôles purs, il n'y aucun éléments du modèle qui intervient pour définir la vue, la définition du binding est externe à la vue. Cela permet une séparation définitive entre la présentation, au sens ergonomie et design, et le Modèle.

Notons au passage que le Modèle est bien le même que celui qui est utilisé pour le mapping avec le stockage et pour le binding avec les Vues. Et comme le binding est réalisé sur le client, vous disposez d'une Application Ajax native, et vous limitez les allers et retours avec le serveur à des échanges de données uniquement.

Nos Services sont découverts et appelés dynamiquement dans un contexte complètement distribué ce qui correspond bien aux fonctionnalités d'un ESB dans le monde .Net. Vu que l'ensemble du code est dans des Services, qui sont directement drivés par les besoins métiers, l'architecture SOA est naturellement réalisée sans avoir à écrire le moindre code technique.

Finalement, il reste bien un triptyque Modèle/Service/Vue, qui suffit à bénéficier de toutes les fonctionnalités d'une Architecture d'Entreprise: MVC, SOA, ORM et ESB.

Alors, est ce que la catégorie MSV reste à inventer ?

Mentoring Day

Nico — Sat, 03 Jul 2010 17:38:00 GMT

Parmi les nombreux événements organisés par notre incubateur Paris Innovation, avait lieu vendredi dernier une session de Mentoring.

10 entreprises de Paris Innovation Bourse, étaient challengées par une quinzaine de mentors du réseau Paris Mentor. Paris Mentor est un réseau d'entrepreneurs et de managers de très haut niveau, qui consacrent une partie de leur temps à aider les entreprises innovantes, en leur transmettant des retours d'expérience sur des points précis et notamment stratégiques pour l'entreprise. Le mentor peut aussi servir de relais à l'entreprise, et lui ouvrir son réseau. La plupart des mentors ont ou ont eu des postes de hautes responsabilités dans des grandes entreprises, ou sont des entrepreneurs confirmés. Ils sont issus du monde industriel, du monde logiciel ou des médias numériques. Ils sont parfois business angels, avec des participations et/ou une présence dans les board de plusieurs startup. Ils connaissent bien le monde de l'entreprise et aussi des technologies.

Les sessions avaient lieu en 2 parties:

un pitch de 5 minutes de chaque entreprise devant l'ensemble des Mentors
3 sessions de retours et d'échanges de 30 minutes, en petits groupes; nous étions en binôme avec BrightLoop, avec qui il était très intéressant d'échanger sur nos entreprises.

Pour le pitch, nous avons fait le choix de présenter l'essence et les bénéfices de notre approche, avec des slides illustrées, façon zen presentation. Cela sortait clairement du cadre des présentations classiques attendues dans ce genre d'exercice, qui ont un plan souvent destiné à des investisseurs, et relativement standard. Nous avons fait ce choix, parce que nous ne sommes pas en train de lever des fonds ni de nous adresser à des investisseurs et parce que nous espérons susciter enthousiasme et curiosité.

Ensuite, avaient lieux les sessions de retour, durant lesquelles nous avons eu droit à des retours enthousiaste ("ébahis" par notre présentation, cela fait plaisir), neutre ("je n'ai rien compris, car je ne connais pas du tout votre métier") et aussi un très négatif ("complètement à côté de la plaque"). Puis les conseils pratiques, comme quoi il faut être plus précis, sur la terminologie et qu'évidemment notre promesse est éculée, et nous devons être plus convaincant.

Outre les questions et remarques traditionnelles sur le fond, notre trésorerie, notre vision de l'écosystème, notre système de ventes, je crois que ce qui manque, en tout cas pour ceux du métier du logiciel, c'est notre catégorie. Nous avons d'ailleurs eu une discussion très intéressante qui nous a poussé à expliquer que nous étions le contrôleur universel du modèle MVC. Visiblement, cette précision a plu, je ne sais pas si nous l'intégrerons dans notre discours, c'est peut être une idée à creuser.

Plusieurs de nos interlocuteurs nous renvoient un signal qui témoigne une certaine curiosité, comme si le charme avait quelque peu opéré. Pour ceux qui ont connus une proximité avec de grands projets informatiques, l'histoire que nous racontons leur parle, elle fait écho par rapport à leurs vécus. Ils voient très bien les analogies que nous employons, même s'il manque le côté opérationnel. Comment peut s'intégrer une solution comme la nôtre dans un existant ? A quel niveau impacte-t-on l'organisation en place ? Quelles sont les entrées-sorties de notre logiciel ? Ce sont d'excellentes remarques, sur lesquelles nous devons affirmer notre discours, et surtout être capable de le formuler de façon claire et concise. Quand j'ai argumenté la non-présence de ces informations dans notre présentation (nous avons tout de même des éléments de réponses) par la faible durée du pitch, 5 minutes c'est très court, plusieurs intervenants m'ont répondus fort justement, que ce n'était pas une raison valable.

Si nous avons choisi d'insister sur le Why, sur les raisons qui nous ont poussé à créer Aspectize, c'est parce que ces raisons-là sont déterminante dans notre projet, et qu'il nous parait intéressant de le dire. Le How était très succinctement exposé, peut être sur le caractère que l'on considère le plus différenciant (principe de Hollywood). S'il est extrêmement difficile de résumer le How en quelques minutes, nous sommes passés à côté du caractère différenciant, ce que nous ne sommes pas. Le What, quant à lui, n'a quasiment pas été évoqué, et le Cloud doit être mis en avant beaucoup plus tôt, car c'est la tendance actuelle du marché.

Etre capable de pitcher en 5 minutes, sur le Why/How/What de son entreprise est un exercice que se doit de réussir tout entrepreneur. Avec le feedback des mentors, nous avons des pistes très claires pour améliorer nos présentations, avec l'objectif de cibler les intérêts des décideurs. Petit à petit, nous perfectionnons notre discours, les éléments marketing se mettent en place. Lorsque ce discours sera alimenté par nos références, de véritables retours d'expérience réussie, je crois que nous commencerons à avoir un discours bien construit et qu'il sera le moment de faire beaucoup plus de bruit.

Je remercie en tout cas Paris Mentor et Paris Développement pour cette initiative, qui nous permet de progresser. En nous challengeant avec des décideurs de haut niveau, on ne peut que mieux se préparer au grand bain dans le business.

Soutien Oséo

Nico — Thu, 08 Oct 2009 16:47:00 GMT

OSEO soutient le projet d'innovation d'Aspectize.

Concrètement, nous obtenons un financement substantiel, sous forme d'avance remboursable, qui nous permet d'accélérer notre développement.

Le projet concerne essentiellement l'intégration des technologies suivantes:

Azure
SilverLight
Visual Studio 2010

C'est un projet ambitieux, qui va nous permettre de nous positionner sur des sujets au coeur de l'actualité MS. Et nous avons plein d'idées pour apporter notre valeur ajoutée autour de ces technologies. Nous aurons l'occasion d'y revenir au fur et à mesure de notre avancement.

Ce soutien nous fait du bien; au delà de l'aspect purement financier, c'est un nouveau tiers de confiance, et une nouvelle étape dans notre développement.

Aspectize rejoint Paris Innovation

Nico — Fri, 21 Aug 2009 07:01:00 GMT

Devant faire face à la recherche de locaux, notre hébergeur actuel rejoignant lui-même sa maison-mère prochainement, nous avons postulé chez l'incubateur de la ville de Paris, Paris Innovation.

Après la diffusion du Business Plan et un entretien avec les responsables, nous avons passé l'oral final devant une commission qui comprenait un panel de personnes diverses (dans le désordre, OSEO, Paris Innovation, Scientipole Initiative, et Seeft Venture)

Et nous avons eu la bonne nouvelle que notre candidature était acceptée.

Au-delà des locaux, nous intégrons une véritable structure d'incubation qui va nous apporter une aide précieuse dans des domaines comme la protection juridique, le marketing, ou le financement. C'est également un réseau que nous intégrons, relais de confiance extrêmement important pour nous.

Contrairement à d'autres incubateurs, comme Agoranov par exemple, qui se concentrent plus sur la recherche et la conception d'un produit, Paris Innovation incube les sociétés dont les concepts sont déjà démontrés, et qui sont en phase d'aborder le marché. Exactement, le point où nous en sommes, puisque nous commençons à contractualiser nos premiers clients.

Notre déménagement est prévu le 31 aout prochain et nous nous réjouissons d'intégrer cette nouvelle structure. Accessoirement, nous ne serons pas dépaysés, en allant de la rue Gaillon à la rue d'Uzes.

Valeur d'Usage de notre solution

Nico — Wed, 22 Jul 2009 09:08:00 GMT

Les réflexions sur le Business Model conduisent naturellement à s'interroger sur la question de la valeur apportée par notre solution.

Pour bien comprendre cette notion, il est essentiel de considérer :

que cette valeur est toujours relative à une solution concurrente: notre solution de développement adresse un marché mature, où il existe pléthores de solutions concurrentes et où du développement spécifique est toujours possible. Il est donc important de bien savoir avec quelles solutions concurrentes la comparaison de valeurs est réalisée.
que cette valeur doit s'estimer du point de vue du client: elle s'exprime par les bénéfices moins les sacrifices perçus par l'usage de la solution. Ces sacrifices ne sont jamais nuls, il est important de les intégrer dans la comparaison.
que cette valeur est une valeur d'usage, qui doit intégrer un usage sur le long terme. Nous adressons des Systèmes d'Informations qui sont prévus pour durer, la valeur d'usage doit être projetée sur un axe temps. La mise en situation est essentielle pour permettre cette projection qui n'est pas évidente. Le vieillissement d'un SI est toujours très difficile à anticiper. 2 questions peuvent aider pour faciliter la projection dans le futur:

Comment pourrais-je faire évoluer mon SI face à n'importe quel changement demandé par les utilisateurs ?
Que vais-je pouvoir réutiliser dans des applications futures et Quels sont les éléments sur lesquels je vais pouvoir capitaliser ?

que cette valeur se mesure essentiellement en comparant et en chiffrant:

le coût du développement, qui se mesure essentiellement avec du temps passé, mais pas seulement; d'autres éléments interviennent, car notre approche a aussi des impacts sur l'organisation et la réduction des spécifications notamment.
la qualité du développement réalisé car une ligne de code écrite est toujours source potentielle de bug, et ce point est important lorsque l'on compare avec du développement spécifique.
le coût de la maintenance, car le code écrit ou généré est toujours plus difficile à faire évoluer que quand il n'y a pas de code du tout. Ce coût est évidemment plus important pour du développement interne que par rapport à l'achat de produit, qui sera mutualisé par plusieurs clients.

Depuis le début de notre développement, notre ambition et objectif se résume assez simplement à écrire le code "bête" une fois pour toute et à laisser le code "intelligent" à écrire pour l'application. Par code "bête", on désigne le code "technique", qui est connu d'avance, quasiment toujours la même chose, qui évoluera peu avec le temps, et par code "intelligent", on désigne le code "métier", qui est flou et peu connu d'avance, et qui évoluera fortement avec le temps. Notre valeur d'usage s'évalue donc par la quantité de code éliminé par notre solution, ce qui n'est pas immédiat, parce que notre approche est nouvelle, et on a souvent l'impression, à tort, que le code est la solution alors qu'il est souvent le problème.

Les solutions de références sont très diverses, il peut s'agir de développements spécifiques ou de produits, qui seront principalement des Frameworks ou des générateurs de code. Beaucoup de nos fonctionnalités n'ont pas d'équivalent dans des produits packagés et la solution de référence sera du développement spécifique. La plupart - on pourrait presque dire la totalité - des solutions de références ont pour paradigme une approche OO, ce qui est notre principal facteur différenciant et ce qui nous permet d'atteindre une séparation beaucoup plus nette entre code "technique" et code "métier". Nous pouvons aller beaucoup plus loin dans l'élimination du code technique, et évitons des taches fastidieuse et répétitives de développement. En ce sens, nous apportons de la valeur, puisque nous éliminons une charge de travail couteuse, et source de risques pour la qualité du projet.

Les différents compartiments de l'Application sur lesquels nous avons une proposition de valeur, sont logiquement découpés en fonction des différentes briques de notre solution. Nous aurons l'occasion d'y revenir en détail, les fonctionnalités à estimer peuvent être listées comme suivant. Bien entendu, chaque fonctionnalité doit être pondérée en fonction de la valeur qu'elle a pour le projet, et chiffrer pour chacune des solutions envisagées:

Accès aux données (ou couche DAL)

Designer de Schema Logique
Import/Export vers le Schéma physique
Données Multiples et Temporelles
Expressions simples et complexes
Champs non persistants
Validateurs simples et complexes
Lecture de données; détailler les différents types de requêtes (profondeur, lazy loading, filtre, tri), appels typés ou non typés.
Ecriture des données (lock optimiste ou pessimiste, triggers)
Gestion du TrackChanges
API Manipulation des données (création, modification, suppression)
Gestion de MétaDonnées (Qui, Quoi, Quand)

Serveur d'Applications

Appels de services typés ou non typés
Sérialisation
Scalabilité
Sécurité
Gestion du Profile utilisateur
Gestion d'Exceptions
Bouchons
Services transverses (Log, trace, cache, ...)
LoadBalancing
FailOver

DataBinding Relationnel & CommandBinding dans les IHM

DataBinding bidirectionnel vers les données
ControlBinding bidirectionnel entre les contrôles
Contrôles supportés
Gestion du Layout
Validateurs
Navigation Parent/Child
CommandBinding (synchrone et asynchrone)
UIService (création, suppression, association)

Nous pouvons ajouter également les sujets transverses suivants:

Organisation: notre approche permet un découpage plus facile du projet. En rendant les pièces indépendantes, il est plus facile de découper le projet en autant de sous-projets que nécessaire. On diminue ainsi l'entropie du Système; même si cela est très difficile à chiffrer, il est important de le prendre en considération.
Cycle de développement: notre approche permet d'atteindre une agilité réelle qui permet d'avoir des cycles de développement extrêmement courts, de l'ordre de quelques heures. Nous favorisons ainsi l'adoption d'une approche agile sans les contraintes imposées par les méthodes agiles actuellement en vogue.
Architecture: notre solution est une architecture "out-of-the-box" qui propose une architecture prête à l'emploi dès le premier jour. Elle permet de s'affranchir de nombreux points à mettre en oeuvre pour mettre en place une Architecture multi-tiers. Peu de solution de références offre cette fonctionnalité, la mise en place d'une Architecture est souvent une tâche dédiée sur un projet, qui est rarement capitalisée d'un projet à l'autre avec des composants prêts à l'emploi, et plus souvent issue de l'expérience des participants du projet.
Evolutivité: la réduction de code technique et la non-adhérence à des choix techniques permet d'envisager une évolution future vers d'autres environnement. Ainsi, une application WinForm pourra être portée facilement en WPF, une application Web pourra être portée plus facilement en SilverLight; par "facilement" nous signifions que la logique de l'Application n'est pas remise en cause, car la logique a été complètement isolée de la technique et donc de la technologie utilisée dans l'IHM. Ce point n'est pas souvent pris en considération car peu de personnes envisagent que cette évolution est possible.
Intégration: la cohabitation d'une Application avec le reste du SI peut être un point clé du choix des solutions, et il est nécessaire de vérifier que l'intégration avec des applications tierces est possible dans les deux sens. En ce qui nous concerne, nos applications sont nativement .Net, elles peuvent intégrer du code spécifique à tout endroit de l'application (la récupération des contrôles, données et traitements se fait facilement), et l'appel de n'importe quel traitement client ou serveur, est toujours possible.

Parmi les sacrifices identifiés, on distingue principalement les coûts de transferts vers une nouvelle approche et une nouvelle solution, qui peuvent se détailler ainsi:

L'apprentissage, qui sera capitalisé sur le long terme
L'abandon de ce que l'on possède déjà, qui est souvent survalorisé par ce que ce qui est possédé est la résultante d'une décision passée, et qui se traduit par une impression de perte de contrôle. Cette impression doit être temporaire et vite comblée par l'apprentissage rapide de la solution.
Les changements dans l'organisation et la méthode de développement; même s'ils sont bénéfiques à terme, un changement est souvent perçu comme un sacrifice, on préfère continuer à maîtriser ses échecs que de prendre le risque de réussir.
Le risque perçu par le choix d'une Start-up: "Personne ne s'est fait virer en choisissant IBM ou Oracle !", à nous d'identifier les Early Adopter qui sont prêts à travailler avec une Start-up.

Plusieurs études montrent que l'on se focalise plus volontiers sur les sacrifices que sur les gains. Ceci est légitime, car le risque de ce que l'on ne connait pas est naturellement une source d'inquiétude toujours plus forte. Il y a une asymétrie de l'information, entre ce que l'on connait et ce que l'on ne connait pas, et donc un déficit presque naturel des sacrifices perçus. Combler cette asymétrie d'information et se mettre dans une position de connaissance équivalente des différentes solutions demandent un effort, lui-même assimilé à un sacrifice. C'est à nous de combler ce déficit et d'accompagner nos prospects pour leur permettre d'évaluer la valeur apportée par notre solution avec le maximum d'informations. Ne perdons pas de vue non plus tous les problèmes actuels de dépassement que connaissent la grande majorité des projets de développement. Les "Pain Point" que nous adressons sont bien des surcoûts que nous éliminons.

Finalement, la décision d'acquérir une solution innovante de développement se mesure par une mise en situation et la réalisation d'un projet pilote, qui permettront la mesure des différents gains et sacrifices des différentes solutions pour calculer la Valeur d'Usage de notre solution, et montrer qu'elle est supérieure aux solutions concurrentes.

Startup Academy

Nico — Mon, 18 May 2009 08:13:00 GMT

Aspectize est inscrit à la Startup Academy.

Cela fait partie des opportunités saisies pour "sortir du bois".

Le descriptif de notre candidature est ici, la liste de tous les participants est là.