That being said, GL 3.x has Transform Feedback, which significantly reduces the need for rendering to an image like this. You can much more easily restructure your processing to go to feedback parameters, which are written directly into buffers. And of course, GL 4.x allows you to write to pretty much whatever you want, so you can again avoid writing to an image.

I'm looking for a way to bind a texture as a VBO, so texture data can be processed as vertex.

I know it is possible to copy data from a texture to a PBO and then bind this PBO as a VBO, but is there any way to do that without involving a copy ?

You can just bind it as a texture and have the vertex shader read from the texture with texelFetch(). There may be a performance penalty relative to having the data already in a VBO, but I don't know whether it will be more or less than the copy (although if the data changes rarely, the one-off penalty for a copy is bound to be cheaper than a repeated penalty on access).

The main reason you need to perform a pack/unpack step when transferring data between a texture and a PBO is that textures are optimised for 2D access rather than sequential access. AIUI, textures tend to be stored in something like "quadtree" layout rather than the row-major layout used for uploading and retrieving data.

I can't use transform feedback because I really need a texture as output (to display it), and I've already implemented the algorithm from the paper last year, using textel fetch in the vertex shader.

Now I would like to optimize it, and avoid the textel fetch. My idea was the following(even if it seems there is no way to do that) :

1/ render the scene as I actually do, in a texture using a FBO
2/ get the pointer to texture data = pData
3/ set pData as VBO, so vertex shader directly get the texel
4/ by playing on stride / offset of the VBO, it would be easy to process 1 of 4 pixel for example

With proper configuration of bins/channels count, the original algorithm using texel fetch in vertex shader can be really efficient, but I believe an optimisation on data access is still possible.